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

[Peter Thoenen]

Jeff,

--- ".jeff" <jeff at members.evolt.org> wrote:
> 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.
>

http1.1 is the current spec..but like you state later
with xhmtl 1.1..who actual supports it.  From a server
side application prospective .. I don't use any http
1.1 specific code nor can I think of any reason to do
so (though I admit I haven't looked that into it)

> 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.
>

This is an apples and oranges argument.  I don't
*personally* see this as an issue as I dynamically
create .pdf files on the fly for my invoices for all
customer purchases.  I am not saying this is *correct*
as it does have some isseus (lynx for one, requiring
Adobe Acrobat Reader for another)... BUT I WILL ADMIT
I can see where you are coming from.  It would be nice
if we didnt' have to work around this..still not a
show stopper though.  Every situation is different and
each programs unto his own.  I could see this as an
issue.  Now I am not an IE guy (or lynx for that
matter..i am a big moz guy..that is first and foremost
for me in ALL my testing) ... does (I am curious) IE
or lynx display the proper code for a page the POST's
to itself?  If not, this is moot as we originally
started about Mozilla bugs.  If so, while I see BIGGER
blocker bugs than this (for example..the
document.lastmodifed() javascript bug)... I can see
where ppl are coming from

>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 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.
>

I disagree on this.  Regardless of my budget..I
naturally code vendor neutral.  Sure certain items I
(you) can't make perfect in all browsers (for example
I have given up on support NS4.x visually unless
client contract REQUIRES ... I do IE6/Moz1.0/Lynx) due
to client restraints... but I can sure as hell make it
workable in all (most) browsers.  Main reason I
support Lynx is I have a job requirement to support
(as in usable) audio browsers for visually disabled
ppl and i personally believe ppl should quit
discriminating against visually disabled ppl.

>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 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.
>
>

My point actually is kind of broke on this (as of Moz
0.9.9).  IE should render those boxes with the
border..not two seperate boxes.  Mozilla used to do it
as developers interput (per bugzilla) but changed it
with 1.0).  I could be wrong though as the css spec on
<input>'s is unclear.  A better example though of IE
css1 failure is <div style="margin: 0px auto 0px
auto">blah</div>.  AS PER css1 specs this should
center blah on the screen but this fails when you use
a XHTML doctype as IE goes into quirk mode with <?xml
?>.. This is a well known bug and many sites
(including evolt) document a work around to this.
This is really not worth arguing though..we (as in
you/me/everybody) all agree each browser has visual
bugs .. not the point of this discussion as we are
discussing web app issues with Moz.  Only reason I
brought it up was the bug mentioning the view source
on page posted to itself (which I regard as a visual
bug..nothing more).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 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.
>
>

That is personally code for the <input> example, not
real world.  I have learned long ago to use backward
compatible xhtml code and routinely make sure all my
code works (though maybe visually ugly as hell) in
older browsers.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > XML validates just fine without it and it
> perfectly
> > *legal*
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> agreed, but an xml validator isn't displaying the
> page to your end user.
>
>

I see where you are coming from but see earlier
comment...this code is for list example only..not real
world application.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 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.
>

Validate and IE6 point..see earlier comment

XHTML1.1 ... I seriously apply, live by, and use it.
Unless the client (who always has the final word)
specifically dictates a need I can't meet in xhtml
1.1... I very well make sure it is valid.  Also..why
the validator doesn't allow inline overriding (as 1.1
is still a working draft.. ! a recommendation)..it
does check it when the !DOCTYPE is declared.  I see no
reason anyboy would not validate and use 1.1 unless a
client gets in the way.

> 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.
>

No point..just a pseudo valid example.  I see nothing
to this comment other than pointing out little minor
pseudo errors (like my earlier psuedo code).  I also
dont' see a point why I would name="" or value="" and
my checkboxes / radio's do nothing.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > > 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.
>

It is unreasonable when you are doing web application
development.  Most of the code is server side and I
don't explect it to show me my server side only source
in the client.  As for the source on a new
request..right or wrong..i don't ever post a form to
itself..i just post it to another page...dont' see a
reason not to (lets not get into a security argument
on this one...each his own and both ways are equally
unsecure)

>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 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
>

my perspective (though it is not any more or less
valid or right than yours),

Peter

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com