[thelist] RE: [ - Examples of Importing XML into Netscape or Mozilla? - ] - Jeff

.jeff jeff at members.evolt.org
Thu May 23 00:18:01 CDT 2002


peter,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Peter Thoenen
>
> Also let me reiterate while Mozilla has lots of bugs
> that visually hamper Web designers, nobody has yet to
> come up with one that would stop a webappliation front
> end (non-visual).. I want application breaker, not
> visually oddity.  We can all find errors in browsers
> A, B, C, D ... what matters is as long as the do
> HTTP1.0..i don't see them breaking ANY web applications
> as the orginal post implied Mozilla doing.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

first off, http1.0 is not the current spec.  http1.1 is.

michael already mentioned a *very* serious issue with a web application.  if
a visitor is printing a page that shows a purchase receipt based on an
invoice number posted from a form on the previous page, printing the page
will result in no invoice number being posted, no purchase receipt being
displayed, and nothing even similar being printed.

that's not just a visual problem.  that's an application problem.

the upside is there are ways around that in most cases, but the fact remains
that it's a huge flaw.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Not at all.  Visual rendering bugs do NOT break web
> applications.  Your application should work in lynx.
> May not be visually pleasing but works.  Visual don't
> aren't a show stopper.  See my thoughts on http1.0
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i'm going to come back and say it depends on your audience.  it also depends
on your budget.  the client may not have paid for that level of
interoperability.

see my comments about http1.1.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> First off, that was pseudo code.  But to keep
> everybody happy, here you go:
> http://www.nthroot.net/input.html
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i agree it was psuedo-code, but it's hard to discern your intent from
pseudo-code.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Next, space is between the / and the closing attribute
> " is suggested for BACKWARDS compatibility.  We aren't
> discussing this.  It is a preference, not a requirement.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

it's a requirement if you want it to work on older browsers.  make up your
mind.  first you say things should work in any http1.0 browser (which is a
bit of a misnomer since there's more to a browser than which version of the
http spec they support).  now you're saying it doesn't matter if you include
the space, it's just preference.  well, in my world, that space is a
requirement because i want it to be backwards compatible.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> XML validates just fine without it and it perfectly
> *legal*
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

agreed, but an xml validator isn't displaying the page to your end user.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> When you show me a transitional xhtml1.1 !DOCTYPE, I
> might take that comment seriously.  XMTLM1.1 REQUIRES
> (per spec) that it meets XHTML1.0 STRICT and then
> some.  No transitional mentioned in 1.1
>
> http://www.w3.org/TR/xhtml11/xhtml11_dtd.html
> the spec if you don't believe me.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

who here is seriously using xhtml1.1?  what browsers even properly support
it?

heck, it's not even listed as a valid doctype on the w3 validator.  don't
believe me?  here's the list of doctypes the validator let's you choose
from.

(detect automatically)
XHTML 1.0 Strict
XHTML 1.0 Transitional
XHTML 1.0 Frameset
HTML 4.01 Strict
HTML 4.01 Transitional
HTML 4.01 Frameset
HTML 3.2
HTML 2.0

i guess i fail to see the point you're trying to make with your example.
sure, it validates, but how's it failing in ie6?  i'm just not seeing how.

i also don't see the point of having name attributes with no values.  that g
ives you form elements for ui, but doesn't pass anything to the server if
successful.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > from a development view, that's a significant
> > problem?  as a developer, when i view the source i
> > *expect* it will look exactly as the browser got it
> > from the server.
>
> As a developer I don't.  I have access to the code, I
> expect it to work.  If it doesn't, I will run it
> through my handy PHP IDE and track everything.  If you
> soley rely on a browser view source to track bugs for
> your web applications, I am sorry.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that's one way of looking at it.  unfortunately the ideal you talk about
doesn't work for everyone or every situation.

it's not unreasonable to expect the browser to show you the source of the
document you're viewing and not be so broken as to make a new request just
to show you.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> When the browser starts showing SSI or server side
> languages (which you are going to need for an web
> application)..just maybe I might decide a browser
> belong on my web application tool list.  Until then,
> I will continue to use it for what it was meant for,
> display web pages (and to visually troubleshoot my
> web designs..!applications)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i've built many high-end dynamic sites and i've always built them using the
browser to do the development and debugging.  i know all about queries,
includes, entire variable states including local, session, cgi, form, url,
etc. variables, execution times, and any possible error messages generated
all within my web browser.  would be a shame to be stuck where i didn't have
that and had to instead rely on some form of ide to figure it out.

just another perspective,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/





More information about the thelist mailing list