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

[Peter Thoenen]

Jeff,

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

--- ".jeff" <jeff at members.evolt.org> wrote:
> peter,
>
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > From: Peter Thoenen
> >
> > We are not here to discuss bugs [...]
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> oh?  surely these bugs hamper the ability to develop
> proper web-based
> applications, no?
>


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


>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > (try in 100% css1 complaint IE 6 using a xhtml1.1
> > doctype <input type="checkbox" style="border: 1px
> solid
> > #000000" name="" value=""/> and tell me what you
> get..
> > 100% css1 complaint huh)
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> which xhtml1.1 doctype?  transitional?  strict?
>
> btw, you forget a name attribute value.
>
> you also forgot to leave a space between the closing
> double-quote of the
> value attribute and the closing slash in your
> <input> tag.
>
> oh, you also forgot to wrap that input in a
> <form></form> block?
>
> what's the full 100% css1 test document look like
> that you're saying i
> should try?

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

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.  XML validates just fine without it and
it perfectly *legal*

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#a_xhtml11_dtd
the spec if you don't believe me.


>
>

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > ... we are talking about how Mozilla hampers web
> > development (with applications).
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> and believe it or not, bugs play a huge role in
> that.
>
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > I can't think of a single web application in my
> life I
> > have developed or even seen that I needed THE
> CLIENT
> > (or end user) to print the source to a form
> submitted
> > to itself.
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> he didn't say print the source.  he said *view* the
> source and *print* the
> page in separate sentences.
>
>    The "view source" will do a 'get' again on the
> URL,
>    resulting in the source you're looking at being
>    different from what the browser rendered.
>
> 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.  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)

> he then goes on to describe that printing exhibits
> the same behavior of
> doing a get for the content to be printed rather
> than printing what's on the
> screen.
>
> so, we've got two instances where the end result is
> the same.  viewing the
> source gives you different source.  printing gives
> you different source
> which results in a document that's rendered
> differently than the document in
> the browser window.
>
> that's huge.
>
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > Now when you get done complaining about specific
> Mozilla
> > bugs that don't effect web development (as in
> > applications) [...]
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> easy sparky.
>
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > ..maybe you can point me to some code that Mozilla
> can't
> > do but is required for your web applications to
> run (or
> > hell..even code that makes you life as a developer
> more
> > difficult).
>
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>
> there's lots.  here's one that i dislike alot that
> makes my life of
> developing web-based applications difficult.
>
> how about mozilla not firing any event when a
> scrollable region is scrolled.
> this makes it impossible to show tabular data in a
> fixed size box where the
> overflow scrolls and have separate header columns
> above the scrollable
> region that move horizontally to match up with
> columns in the scrollable
> region.

I will admit ignorance on this one.  I have yet to run
into this issue.  Will admit I am not perfect.

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

Peter

* Who is not trying to flame but is rather amazed
somebody would accuse Mozilla of not being Web
Application friendly when I see it just as friendly as
ANY http1.0 browser *

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