Domain: w3.org
Stories and comments across the archive that link to w3.org.
Comments · 6,785
-
Re:Kind of a stretch... (Open Standard)
EULA's being restrictive is nothing new. Though I can't say I'm trhilled with the prospect of them being able to arbitrary "... audit your use of the Software for compliance
..."
Though forgive me if I'm a bit navie, as I do not use Flash much at all, but isn't SVG http://www.w3.org/Graphics/SVG/ a possible option?
Granted its probably not as robust, and it might not do everything that Flash can, but its a start. -
Re:Kind of a stretch...
As a web designer, I don't run HTML here. It's actually quite nice. Since the Flash plug-in is in use by the vast majority of web designers that don't understand HTML or CSS. It makes my life SO much easier. I don't have to be bothered by annoying backseat designers like W3C.
IF someone is stupid enough to remove an important part of the internet's functionality and require people to install proprietary applications so that their websites are usable, then that's their problem. I personally design for people like that.
Uninstalling Flash just reveals websites that either don't work without multimedia or aren't well designed. Flash isn't that important. Slashdot, for example, isn't any the worse for not using it.
-
Re:Sharing documentation incorrectly (should use X
Your assumptions, sir, are the only things wrong around with this thread... Did I mention XHTML 1.0 Strict? I use "XHTML" to refer to the standard as a whole, and specifically the componentisation vision. More specifically, XHTML 2.0. XHTML 1.0 was never meant to be perfect, but a great start towards getting the web to support better standards. XHTML 2.0, however (which is starting to gain marginal support in some browsers as we speak) does indeed remove all formatting tags. HTML 4.01 and XHTML (2.0, which you incorrectly presumed I was reffering to version 1.0) are thus, decidedly, not the same, "thank you, drive through."
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Sharing documentation incorrectly (should use X
Excuse ME? Does your stupid statement mean that you don't even know that there is no such thing as "HTML 4.01 Strict", and that XHTML Strict removes all visual formatting tags? XHTML only contains semantic / structural tags, and is not at all the same thing as HTML. And that is what I am getting at:
Oh god, this is wrong on so many levels...
First of all, let's do a fact check:
- HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
... Strict - XHTML 1.0 comes into three (3) once again different flavours... which are extremely surprisingly also Transitional, Frameset and
... Strict (noticing a pattern or not yet?) - The XHTML 1.0 spec is surprisingly empty when compared to the extensive HTML 4.01 spec (only one page against a few hundreds), which is probably because they are strictly the same (see the words "XHTML is a family of current and future document [...] that reproduce [...] HTML 4"?) but for a few exceptions (such as... XHTML being XML while HTML is SGML, and... oh, that's all, every difference comes from that very single one...)
- Visually formatting tags still exist in XHTML: not only they're all valid in 1.0 Transitional, but since they're not even deprecated, the B, I, TT, BIG and SMALL elements are perfectly valid even in XHTML 1.0 Strict (don't believe me? please, try, be my guest)
Just having information in XML is not enough, as XML is yet another mapping of some structure onto text. What is important, is the vocabulary - one wants to store information in a pure state, containing only the semantics - i.e. what it represents, not what it looks like.
And HTML 4.01 is just as meaningful as XHTML 1.0 strict, exactly my point, thank you, drive through
And lastly, if we consider your XML/SGML statement, and remember that XML is also a subset of SGML (thereby making your statement irrelevant)
Whoopsie... wrong sir, an XML document is not valid as an SGML one but by relying on SGML parsing quirks. For example a strictly conforming SGML parser allows both "/" and ">" to end a tag (you can write either <img> or <img/ for example), the facts that browsers grok the "/>" tag closure is only because of a quirk (which only works when you put a space before said closure, <img
/> will be ok but <img/> will make an SGML parser rip your head off your shoulders), <tag/> does, in fact, render as "<tag>>" in SGML. - HTML 4.01 comes into three (3) différent flavours, namely Transitional, Frameset and
-
Re:Flash Commoditizes Windows
Perhaps we should all learn Flash and start writing applications in it...
Er, no.
Perhaps we should be looking at real standards such as CSS, E4X and SVG. Furthermore, we need to lobby certain people to implement such standards in their browsers.
-
Re:Flash Commoditizes Windows
Perhaps we should all learn Flash and start writing applications in it...
Er, no.
Perhaps we should be looking at real standards such as CSS, E4X and SVG. Furthermore, we need to lobby certain people to implement such standards in their browsers.
-
My take on the low power personal server thread
Ok,
Weighing in with my two cents worth, for what it's worth, I'd like to brain dump what I would consider worth while options for your needs. All of these are solutions I either have used in the past successfully, or am currently using for various purposes. So bear in mind that this is not just the causal musings of a thread cruiser, but actual tried and proven solutions ;-)
First some basic assumptions:
1) You want to run some form of Unix or Unix like system ( i.e. Linux ) - you've noted you currently use your Apple PowerBook laptop, so one has to assume you're running Mac OS X 10.x.x natively ( more power to you ).
2) You want complete control over the system including "root" access 24/7 - this is of course the whole point of having your own system, you can beat it up, break it, rebuild it, and all that jazz.
3) The system should be able to be run remotely, even if just headless on your LAN, or perhaps more ideally remotely from some external 3rd party in a hosted solution so you don't end up having to host it behind your link at home ( also making it easier for you to provide access to other parties should you want to either share it with friends and family or if you just want to make it world visible for whatever reason - i.e. your own mail and web server et al ).
4) You want an "always on" solution, so this should be something that, as you state, should not suck too much juice power wise, is able to be built with a "standard build" style hardened platform, which in the case of power loss would ideally recover nicely, quickly, and be back on line ( I'll touch on this later as standard builds are going to make your life so much simpler and fun ).
5) The performance of the system ideally should be such that it will cope with the key elements you've noted in your post, such as:
a) remote access such as remote sessions via SSH won't kill the system
b) able to run a web server such as:
thttpd: http://www.acme.com/software/thttpd/
Apache: http://www.apache.org/
mathopd: http://mathop.diva.nl/
Roxen: http://www.roxen.com/
Boa: http://www.boa.org/
Jigsaw: http://www.w3.org/Jigsaw/ ( written in Java )
Acme.Serve: http://www.acme.com/java/software/Acme.Serve.Serve .html ( written in Java )
CERN: http://www.w3.org/hypertext/WWW/Daemon/Status.html
NCSA: http://hoohoo.ncsa.uiuc.edu/
Netscape FastTrack: http://home.netscape.com/ ( not sure if it's still available )
Netscape Enterprise: http://home.netscape.com/ ( not sure if it's still available )
Zeus: http://www.zeus.co.uk/
source: http://www.acme.com -
My take on the low power personal server thread
Ok,
Weighing in with my two cents worth, for what it's worth, I'd like to brain dump what I would consider worth while options for your needs. All of these are solutions I either have used in the past successfully, or am currently using for various purposes. So bear in mind that this is not just the causal musings of a thread cruiser, but actual tried and proven solutions ;-)
First some basic assumptions:
1) You want to run some form of Unix or Unix like system ( i.e. Linux ) - you've noted you currently use your Apple PowerBook laptop, so one has to assume you're running Mac OS X 10.x.x natively ( more power to you ).
2) You want complete control over the system including "root" access 24/7 - this is of course the whole point of having your own system, you can beat it up, break it, rebuild it, and all that jazz.
3) The system should be able to be run remotely, even if just headless on your LAN, or perhaps more ideally remotely from some external 3rd party in a hosted solution so you don't end up having to host it behind your link at home ( also making it easier for you to provide access to other parties should you want to either share it with friends and family or if you just want to make it world visible for whatever reason - i.e. your own mail and web server et al ).
4) You want an "always on" solution, so this should be something that, as you state, should not suck too much juice power wise, is able to be built with a "standard build" style hardened platform, which in the case of power loss would ideally recover nicely, quickly, and be back on line ( I'll touch on this later as standard builds are going to make your life so much simpler and fun ).
5) The performance of the system ideally should be such that it will cope with the key elements you've noted in your post, such as:
a) remote access such as remote sessions via SSH won't kill the system
b) able to run a web server such as:
thttpd: http://www.acme.com/software/thttpd/
Apache: http://www.apache.org/
mathopd: http://mathop.diva.nl/
Roxen: http://www.roxen.com/
Boa: http://www.boa.org/
Jigsaw: http://www.w3.org/Jigsaw/ ( written in Java )
Acme.Serve: http://www.acme.com/java/software/Acme.Serve.Serve .html ( written in Java )
CERN: http://www.w3.org/hypertext/WWW/Daemon/Status.html
NCSA: http://hoohoo.ncsa.uiuc.edu/
Netscape FastTrack: http://home.netscape.com/ ( not sure if it's still available )
Netscape Enterprise: http://home.netscape.com/ ( not sure if it's still available )
Zeus: http://www.zeus.co.uk/
source: http://www.acme.com -
Re:Old news is no news. :-(
The problem with blending images and so on is that blind people still cannot see them.
This slide demonstrates the problem beautifully, I think.
With regard to the simple questions, that is indeed what I do, some simple trivia, and some basic maths, and the library is called SimpleQuestions.
"What colour is the sky?" is actually one of the questions, and the maths question do indeed vary in form, from expression to natural language.
The problem with the drawing requirement is that you're now blocking people who cannot draw. -
Re: Disabilities
The W3C proposed in 2003 a number of Solutions for the Inaccessibility of Visually-Oriented Anti-Robot Tests, including logic puzzles, audio captchas, credit card validation, etc. It is interesting that they also show how a federated identity system can help users with disabilities.
-
Commentary on w3's captcha-inaccessibility page
The main article refers to Inaccessibilyt of Visually-Oriented Anti-Robot Tests, which deserves a read and commentary.
Among the claims:
- captchas are inaccessbile to the blind - true
- a horde of human beings can decode the entire library over time - only true if the images are recycled, not if they are created on-demand or for one-time use.
It also discusses some of the side-effects of making access to real humans harder, or harder for a class of users such as the visually impaired. For example, I've seen sites that say "If you cannot read this, call this phone number for access." Too bad for you if you don't have a phone.
As alternatives, it offers
- logic puzzles
- sound output
- credit-card validation
- live operators
- limited-use of unverified accounts, such as throttling for email
- behavior and heuristic analysis
- already-established credentials, such as single-sign-on systems or public-key-based systems
- biometrics
The article briefly discusses the pros and cons of each.
I rate its conclusion
"Visual verification alone is known to create problems with users. It is imperative that site designers take the needs of users with disabilities into account, and it is likewise hoped that one or more of these potential solutions can make that process easier."
as: insightful +5 obvious -1.
The article as a whole gets an "informative +5." -
Re:Other technology
-
Typical MS MO
Look at Microsoft's participation in standards bodies, for a good reason why Microsoft should be allowed near the FOSS community. Take "SVG or iCAL for example. Both standards threaten Microsoft's hedgemony. Yet Microsoft is part of both standardization efforts. Both projects have been plagued by interminable delays. Whether you chalk this up to Microsoft's conciencious meddling, or merely to gross incompetance, the fact remains that Microsoft was no boon to either effort. Where are Microsoft's iCAL products? What is Microsoft doing to promote SVG?
Microsoft is a predator, and will sink to any depth to eliminate competition. Apparently, since Microsoft has ascertained that it's usual tactics don't work when combating the FOSS movement, it has decided to sleep with the enemy. If you can't beat 'em, join em, and then ruin the party. We've lost Daniel Robbins. Now they're gunning for nothing less than Linus' employer. Weasels, snakes and rats. I'm sure they can offer the OSDL all kinds of "benefits", if the ODSL would make just a few small concessions... -
Letter from W3C to the US Copyright OfficeFYI, from the W3C home page:
2005-08-22: W3C has written to the US Copyright Office regarding a notice of proposed rulemaking. The notice asks if persons filing electronic-only preregistration forms will experience difficulties if the Office requires them to use Microsoft's Internet Explorer Web browser. W3C comments to the Copyright Office suggest that requiring a single browser is inappropriate for government services and encourages the Office to pursue standards-based access in accordance with US Federal policy. Read W3C's letter and About W3C. (News archive)
-
Letter from W3C to the US Copyright OfficeFYI, from the W3C home page:
2005-08-22: W3C has written to the US Copyright Office regarding a notice of proposed rulemaking. The notice asks if persons filing electronic-only preregistration forms will experience difficulties if the Office requires them to use Microsoft's Internet Explorer Web browser. W3C comments to the Copyright Office suggest that requiring a single browser is inappropriate for government services and encourages the Office to pursue standards-based access in accordance with US Federal policy. Read W3C's letter and About W3C. (News archive)
-
Letter from W3C to the US Copyright OfficeFYI, from the W3C home page:
2005-08-22: W3C has written to the US Copyright Office regarding a notice of proposed rulemaking. The notice asks if persons filing electronic-only preregistration forms will experience difficulties if the Office requires them to use Microsoft's Internet Explorer Web browser. W3C comments to the Copyright Office suggest that requiring a single browser is inappropriate for government services and encourages the Office to pursue standards-based access in accordance with US Federal policy. Read W3C's letter and About W3C. (News archive)
-
Re:RSS 1 by the W3C
-
RSS 1 by the W3C
RSS 1.0 is also the only syndication format endorsed by the World Wide Web consortium. RSS 0.9 and 2.0 were created at the companies Netscape and Userland.
-
RSS 3.0 will have to be renamed.Seems like this RSS 3.0 will have to be renamed:
RSS 3.0 Cease & Desist NoticeThe style of the notice and a healthy attitude well deserve some time spent reading it.
PS Agree about RSS 1.0.
-
W3C: Inaccessibility of Visual Anti-Robot Tests
I can't really see a good reason to why Google has that new word verification feature off by default
Probably something to do with laws requiring companies to make their products accessible to people whose disabilities prevent them from seeing images. (Read More...) Turning on accessibility (that is, turning off word verification) by default means that liability for inaccessible blogs lies with the blog administrator, not with Google.
-
DOM 3
What i learned with the painful development with javascript, is that standards are good, using the DOM model instead browser specific extensions is a good thing, better compatibility, the API is more stable, for this reason i think that the right thing to do is embrace the Document Object Model (DOM) Level 3 Load and Save Specification standard for asynchronous communication instead XMLHttpRequest.
-
Re:There isn't a single complete SVG viewer anywhe
CSS 2.1 says that there must be a two interoperable implementations for each feature for the specification to become a recommendation. This is so that the specification can be changed if it's a pain to write or to use. Granted, the earlier versions of CSS didn't have these exit criteria, but there are people on the CSS Working Group who are on your wavelength.
-
Re:Radical Thought: tighter code/codecs reduce nee
Are you thinking of the Core CSS Styles?
-
Re:There isn't a single complete SVG viewer anywhe
At this point, it is such a monumental task to implement all the intricacies of the full SVG specs that *nobody* - Not Microsoft,Adobe,Apache, Sun,Apple of anyone in the open source arena is able to do it, or even come close, it seems.
Complete implementation? No. But pretty much every feature has been implemented and tested in some implementation as of the end of last year:
http://www.w3.org/Graphics/SVG/Test/20030813/statu s/matrix.html
Apps like Inkscape are probably the most advanced SVG showcases, but for some reason everybody wants to write their own browser plugin from scratch instead of starting from the authoring tools and extending them to support a 'playback' mode.
Not to knock the great work Inkscape has done, but it's not the most advanced. I would guess Adobe SVG Viewer is better as a viewer. It's definitely been around longer.
Having a reference implementation from the W3C would be great, sure, but it's not essential. Look at CSS. There are plenty of subtle bugs out there, and everybody loves to rail on the most popular browser not supporting important parts of the spec, but nobody would deny that CSS is useful. -
Re:There isn't a single complete SVG viewer anywhe
> It seems to me that any W3C standard needs a complete and free reference implementation before it should be ratified as a W3C standard.
XForms had as exit criteria for becoming a recommendation one complete and two interoperable implementations . One of the complete implementations that served to meet this goal was X-Smiles, a GPL implementation of XForms (and co-indcidentally SVG, XHTML 1.0, CSS of various levels, SMIL, etc.).
The Mozilla XForms project also aims to provide a complete XForms 1.0 implementation under the Mozilla license, and it's quite far along, and is included as an XPI with each nightly build. The last Linux build I looked at was a 141KB, and about 200KB for Windows, and is a single-click install, just like the bugreport tool. -
Re:No CSS on that site.
But the w3c isn't making any new elements
You are wrong. And you mean element type. An element is a specific instance of an element type. Everybody who writes an HTML document makes new elements.
therefore, we have to work with what we've got and what actually works.
What we have is, among other things, an element type that means "this is a section of the document" and an element type that means "this is tabular data". When marking up a section of a document that is not tabular data, the former element type is clearly correct and the latter element type is clearly incorrect. If there's a more specific element type available, that's even better.
1. Rotating tables is wonderful.
Once more, you are misrepresenting what I say. I haven't said that. I said that it was a useful feature.
I actually think that rotating tables is impossible because no one made it possible.
What do you mean by "made it possible"? Wrote the feature into a web browser? Like I already explained, the reason why nobody has done that is because it would destroy table layouts - i.e. it's abuse of the <table> element type that is preventing such a feature from being put into browsers.
I also think it's not practical to let computers auto rotate because, contrary to your theory of autonomous AI-computers formatting pages, people are required to format pages correctly.
There you go with your straw-men arguments again. I'm talking about turning something ninety degrees. You think that requires AI?
If a page author messes up a page, the user should be able to override his style. The user can't do that if everything on the page is inside a DIV or a SPAN.
I'm not quite sure what you are saying. Taken literally, that's completely untrue. If reworded as "everything on the page is a <div> or <span>", then it's true, but has nothing to do with what I am saying.
In actual fact, the "if a page author messes up a page" argument works against you. If a page author messes up a CSS layout, you can simply disable styles and get the default layout. If a page author messes up a table layout, there's no easy way to disable that.
This requires the user to debug a page. There goes accessibility.
What are you talking about? If a page author messes up, there goes accessibility? Well yes, of course, but obviously that applies to table layouts too!
Like it or not, tables can be used for layout
Where have you been? I'm arguing that doing so is harmful. That would be a pretty pointless argument if I thought that it was impossible, wouldn't it?
Maybe there is a new spec that insists we use DIV class=whatever,
Yet another straw man.
but browsers have box model bugs.
Yeah, we should avoid CSS layouts because of a bug Microsoft fixed four years ago and that is trivial to work around anyway.
-
gnome accessibility tools
The GNOME project has some open source accessibility tools that are very easy to set up and use; the major Linux distributions such as Mandriva already include them. See the Gnome Accessibility Project pages for a good overview.
There is an on-screen keyboard; there's also Dasher a predictive text entry system which some people find useful and which can be used via a pointer device.
I'll also mention that there are pointer devices that use a dot on your forehead, so you move your head, which can be useful for people who have tremors in their hands; another option can be foot pedals. The Dasher page mentions use of an eye-tracker.
As others have mentioned, voice-over-IP can be useful, and tools like gnome-meeting and an always-on webcam might be worth considering.
The World Wide Web Consortium also has some resources about accessibility. -
Re:Maybe.I have no problem with putting a 'Designed for Firefox.' button on my sites
I don't think there is such a thing -- unless you create your own. You would do well to consider one of these, from the World Wide Web Consortium (W3C).
-
Re:Keep it simple stupid...
When the n-th child pseudo class (http://www.w3.org/TR/2001/CR-css3-selectors-2001
1 113/#nth-child-pseudo) becomes available, you will be able to text-align a particular column of tds without having to type class="numerical". -
What about the CSS validator?
I scanned the article quickly, and did not find a CSS validator on the list. This is a useful tool for CSS novices such as myself.
-
Re:Sources anyone?
Most countries have accessibility requirements, including the good old EU and US of A:
http://www.w3.org/WAI/Policy/
So, not bollocks at all. -
Re:What about...
-
Re:Standards
For the billionth time, what does <col align="right"> have to do with css? This is defined in the HTML specification and has nothing to do with the CSS spec.
-
It's time for /. to interview the W3C.
Perhaps a Slashdot Interview with Tim Berners-Lee (Director of the W3C) would be in order?
After all, "One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability." Quote came from this page.
To that end, a web designer (especially that of a company) should be encouraged to comply with standards put forth by an organization like the W3C. A compliance program (logo based?) should be initiated which would recognize sites that are accessible and fully functional from any modern platform. A check and balance approach, by way of complaint forms (or something along those lines), would be ideal to keep sites from straying after being awarded the logo. A major campaign to distribute open-source/W3C compliant web design tools would be encouraged. An online workshop could be put forth to help web admins during the transition.
Wishful thinking? Perhaps. But I think interviewing the director of the W3C and having the response widely publicized on the 'net would definitely garner some attention. -
It's time for /. to interview the W3C.
Perhaps a Slashdot Interview with Tim Berners-Lee (Director of the W3C) would be in order?
After all, "One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability." Quote came from this page.
To that end, a web designer (especially that of a company) should be encouraged to comply with standards put forth by an organization like the W3C. A compliance program (logo based?) should be initiated which would recognize sites that are accessible and fully functional from any modern platform. A check and balance approach, by way of complaint forms (or something along those lines), would be ideal to keep sites from straying after being awarded the logo. A major campaign to distribute open-source/W3C compliant web design tools would be encouraged. An online workshop could be put forth to help web admins during the transition.
Wishful thinking? Perhaps. But I think interviewing the director of the W3C and having the response widely publicized on the 'net would definitely garner some attention. -
Re:StandardsYes, standards like the ones Slashcode uses
ROFL. Do you know why this happens? Because the Slashcode "standards" are anything but, and the Slashdork "editors" decided they didn't want to be embarrassed by their circa 1996 crappy markup. The word "standards" and "Slashdot" should generally be avoided as components of the same sentence. Slashdork isn't even HTML3 compliant. Not even.
The only problems I ever have are from sites offering non free crap
Amazon works fine with Firefox and Konq. And they don't offer "non free crap", whatever that means.