[
Lists Home |
Date Index |
Thread Index
]
It isn't an easy problem to solve now and looking to the
browser to solve it might not be the most effective approach,
but is was an obvious hole that I had not considered
until I fell into it.
I rely on the simpler tools (database output,
ASCII editor, browser validation and verification) and
that doesn't always work because the rules can't
be evenly applied in the mixed browser bag.
len
From: Rick Marshall [mailto:rjm@zenucom.com]
my 2c worth here....
i was sort of hoping by moving to xhtml there would be some consistency.
one of the big problems i face in building browser based apps is the
different tolerance between browsers to errors and following on from
that the different way they then format pages.
microsoft and netscape both took the view that they would try to make
sense of garbage rather than reject it. xhtml forces them to reject it.
with so many badly written pages and badly written html generators out
there why would the world be happy about a rigorous standard and
compiliant programming?
and html+css etc doesn't work properly either - tried printing a page
from ie with css determining the formats?
someone has to find a way through this, but it has to start with all
suppliers comitting to meet the standards. useless otherwise.
rick
Bullard, Claude L (Len) wrote:
>But that means we are still stuck with a mixed bag of
>rules for parsing documents, and even simple cases
>show where that can create problems.
>
>XHTML aside, if one has a namespaced application
>inside an HTML document, it's vendors' choice.
>Yes, we can cope. Should we? I didn't find my
>bug until I tried to add a new feature. Had this
>been after the files had been distributed to
>customers, that wouldn't have been a good day.
>
>What does <?xml warrant?
>
>Warranties from standards without conformance
>tests are the same as a marriage contract: easy
>to extend but impossible to refund. Do all
>preventive maintenance on schedule to prevent
>breakdowns on lonely roads.
|
