Re: Kiwiland response to Richard



Pete Dashwood wrote:

Yes there is. When you view the licence or the source code the frame
is left completely blue except for a tiny edge at the top where the
top part of the first line of the code can be seen.

This is caused by bad HTML, or specifically no HTML at all. I can view
the frame source and there are no HTML tags or even a DOCTYPE.

[Pete]

Bad HTML, huh? No HTML at all? So how do you think you are able to see
ANYTHING?

The 'no html' and 'no doctype' referred to the 'frame source', ie the
src= content inside the frame created by the iframe.. That is why I
was specific with 'frame source' rather than 'page source'.

This is an environment you don't understand, Richard, and you would do
better to be less hasty in racing to conclusions.

I have high respect for your overall knowledge, but it is pretty obvious you
have no experience with ASP.NET and C# pre-compilation.

The browser does not know, nor care about, ASP.NET or C# pre-
compilation. It only cares about what has been sent to it.

I can view the page source and there certainly IS a correct HTML framework
and DOCTYPE.

That is why I was specific with 'frame source' rather than 'page
source'.


Looks like pretty standard HTML to me... At least I can SEE it.

I could see the page source too, which is why I could find the iframe
tag.

But then I'm using IE7 and it may be a better Browser :-)

It may be better than IE6 or IE5.x but it is a couple of years behind
the innovators, as MS software usually is.

I honestly don't know how you think the page could render on a client if it
had no HTML, Richard.

The frame source has no HTML.

The way that ASP.NET works is that the ASP and C# code are run at the
server, where they generate the page which is then rendered in the Browser
in the usual way. This is much more secure because the code that is run is
not client JavaScript (although I can do that too if the need arises); it is
precompiled C# code running on the server and subject to the server
security.

I am not sure why you are comparing this with client-side Javascript
which has a completely different function. Server side has been done
with PHP, Perl SSI, JSP, and others for years.

I am not even sure why this is relevant in any way.

If you can't see the generated HTML (shown above) that can only be a good
thing...

Of course I can see it.

This is standard HTML generated dynamically from the C# code. If you can
show how this is non-standard, I'll stand corrected.

I'll rephrase: 'This is the code that creates the frame that does not
display the code'

This is probably NOT it. It is more likely to be the interpretation of the
CSS. Especially as people are seeing blue backgrounds and the only blue on
the site is from Master Page headers and footers, which are governed by my
CSS.

and when we look at cobdata.txt it is just the source, not even a
<code> .. </code>

These tags are NOT required with iframe source. The iframe renders a lot of
stuff besides code...

OK, it is the CSS that is used by the display of the iframe content.

Geez mate, what's "Notepad" ?

[Pete]

Well, I guess that accounts for why YOU can't see it...:-)

Jimmy is running in a Windows XP environment, Richard. My observation is
therefore a fair one.

Does the iframe put the source code into Notepad ? I think not.

I didn't come down in the last shower and I've been writing HTML for 15
years. Now, it may not always be STANDARD, but I can guarantee it renders
correctly in any version of IE above 5.5. I did fair and reasonable cross
browser checks on this code and it passed.

My reading of the 'iframe' tag is that the src= is to be HTML source,
exactly as it is when the 'frameset' is used. Plain text is not HTML
and cobdata.txt is not HTML source.

Non-standard HTML (and I'm not saying this is that) is not necessarily "bad
HTML". It depends on your priorities and design criteria.

Firefox 2.x and 3.0.2 (latest development) show blue covering frame.

Opera 9.51 same.

Galeon same.

Konqueror 3.5.9 asked whether I want to open or save cobdata.txt. Open
showed it in the frame. If I 'save as' then the frame is covered by
the blue. I assume that this happens because the frame now has no
content, the cobdata.txt went to disk and not to the page.

Given this then it seems that Firefox and Opera are also treating the
frame as if it has no content (hence my blaming it on no doctype or
html in the frame source) but this may be because it is 'one line' (no
<p> or <pre> or <br /> tags). Note that html ignores 0x0D0A newlines.

Dillo got a 'Bad Request' from the server.

I don't have Safari.

Was your 'fair and reasonable cross browser checks' both IE6 _and_ IE7
then ?

.

Relevant Pages

  • Re: Kiwiland response to Richard
    ... was necessary to use HTML to define the frame. ... iframe construct itself. ... I'm pleased to report that these pages are now working in Firefox. ...
    (comp.lang.cobol)
  • Re: Multiple IFrame hang
    ... How many concurrent connections are there to the same server ... Our application retrieves a URL and a frame name from a list and then ... > application that does not load in pages that contain framesets, ... The 3rd IFrame displays a straight ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: Frames with Seaside?
    ... As to CSS, I am an extreme newbie when it comes to web programming (NOT ... (but not a "regular" frame - is this true?). ... iframe, and the iframe did not achieve the effect I wanted. ... I am trying to do a "streaming" sort of thing where the server can ...
    (comp.lang.smalltalk)
  • Re: Kiwiland response to Richard
    ... This is caused by bad HTML, or specifically no HTML at all. ... The 'no html' and 'no doctype' referred to the 'frame source', ... Nowadays the source to an iframe can be ... Firefox renders correctly and they nuse the same CSS. ...
    (comp.lang.cobol)
  • Re: What is the difference between window.parent and window?
    ... "In Firefox if an HTML page is not hosted inside a frame or iframe, ...
    (comp.lang.javascript)