Comment RTFM (Score 1) 1279
If you are a professional, you "code" to meet documented
standards, design specs, or API. You test your code (or in
this case "web pages") with the target programs (e.g.
browsers). If the code follows the spec., the defect is in
the target program, or the spec. is wrong, so submit a
defect report against the offending part.
If the defect won't be repaired in time for your next
release, then code a workaround, preferably within the
spec. or as an exception to the particular target.
Contrast this with non-professionals: write the code to work
with what you think most everyone else has, and test with a
particular version that you have on your system. If it
works, you're done. Actually the non-professional method
might work, but ONLY if an attempt is made to fix 100% of
all the problems reported back to them.
A core software engineering axiom: high quality is achieved
*by design* not by testing.
This is true because it is impossible to remove all defects
from code with testing alone. If you have a problem
believing this, then this will really fry-your-brain: if
your code (or web page) doesn't work with the target
browser, then you might think that this is a defect with the
browser (e.g. because it used to work with a previous
version). But how can you prove that if there is no spec.?
The vendor will always tell you that this is a feature, and
that the defect is in your code!
Of course this particular topic of incompatible web
browsers has been around for some time:
"Anyone who slaps a 'this page is best viewed with
Browser X' label on a Web page appears to be
yearning for the bad old days, before the Web, when
you had very little chance of reading a document
written on another computer, another word processor,
or another network." --Tim Berners-Lee in
Technology Review, July 1996
See the "Viewable With Any Browser" campaign web site for
more details: http://www.anybrowser.org/campaign/
standards, design specs, or API. You test your code (or in
this case "web pages") with the target programs (e.g.
browsers). If the code follows the spec., the defect is in
the target program, or the spec. is wrong, so submit a
defect report against the offending part.
If the defect won't be repaired in time for your next
release, then code a workaround, preferably within the
spec. or as an exception to the particular target.
Contrast this with non-professionals: write the code to work
with what you think most everyone else has, and test with a
particular version that you have on your system. If it
works, you're done. Actually the non-professional method
might work, but ONLY if an attempt is made to fix 100% of
all the problems reported back to them.
A core software engineering axiom: high quality is achieved
*by design* not by testing.
This is true because it is impossible to remove all defects
from code with testing alone. If you have a problem
believing this, then this will really fry-your-brain: if
your code (or web page) doesn't work with the target
browser, then you might think that this is a defect with the
browser (e.g. because it used to work with a previous
version). But how can you prove that if there is no spec.?
The vendor will always tell you that this is a feature, and
that the defect is in your code!
Of course this particular topic of incompatible web
browsers has been around for some time:
"Anyone who slaps a 'this page is best viewed with
Browser X' label on a Web page appears to be
yearning for the bad old days, before the Web, when
you had very little chance of reading a document
written on another computer, another word processor,
or another network." --Tim Berners-Lee in
Technology Review, July 1996
See the "Viewable With Any Browser" campaign web site for
more details: http://www.anybrowser.org/campaign/
