Re: Kiwiland response to Richard
- From: Richard <riplin@xxxxxxxxxxxx>
- Date: Thu, 25 Sep 2008 22:39:41 -0700 (PDT)
On Sep 26, 4:09 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
A very good response. Thanks.
I have made some calmer comments below :-)
"Richard" <rip...@xxxxxxxxxxxx> wrote in message
news:84785d0b-f94e-4d8b-bce5-36b73d3565fa@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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'.
In the old days, inline frames (iframes) were mainly used for viewing HTML
within an HTML page.
However, that is no longer the case. Nowadays the source to an iframe can be
(almost) anything.
In the very old days when we used framesets and created frames manually it
was necessary to use HTML to define the frame. Now it isn't, apart from the
iframe construct itself.
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.
Yes, that's true. But you were throwing accusations of "bad HTML" around and
my point is that much of the HTML on these pages is generated from ASP.NET
running on the server. In other words, I never got to write the HTML, I
wrote the ASP and the smart stuff was in C#. I was a bit stung by your
accusing me of producing bad code, when in fact, I didn't.
I doubt that I indicated where the blame lay, or indeed how the code
had been produced.
You should note that what I did say was: "This is caused by bad HTML",
and not "You produced bad HTML".
Back in the 70s there was a vouge of doing personal assessments using
multichoice. Actually it still may be done.
I recall one I did at ICL where a choice for one of the sets was
"Takes criticism of work done as a personal affront".
Besides, I'm
pretty sure the problem is with the CSS and NOT the HTML, whether written by
me or generated by ASP.NET.
One of the issues with iframes (AFAIK) is that the default for IE is
black on white while others default to transparent. It may be
necessary to specify both background and foreground colours. Looking
at the CSS and other settings it may be that you specify only one.
Also the height of the iframe is greater than my usual viewing area
which means that I have to use both the page and the frame scroll
bars.
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'.
As in inline frame source doesn't require DOCTYPE I may have missed that.
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.
OK, I'm not going to debate that with you :-). I HAVE downloaded Firefox and
viewed the pages with it. I agree they are a mess. I'll fix them as a matter
of priority.
I then created a simple two column table in Dreamweaver and viewed it with
both Browsers. IE resolved it correctly, Firefox didn't. I don't understand
why it doesn't work but I'll endeavour to get somethng both Browsers can
"agree" on. The CSS I am using may be using some constructs that Firefox
doesn't like; I don't know. Without the CSS (as you pointed out earlier)
things render correctly. But then there are other pages on the site which
Firefox renders correctly and they nuse the same CSS.
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.
It actually requires none and apparently hasn't since it was standardised in
ECMA 4.0.
ECMA ??? ECMA is a manufacturers association that writes up what they
are paid to do. They are not a standards organization. Anyway "ECMA 4"
is a proposal for Javascript not HTML.
W3C are the standards body for HTML and associated markup languages:
"""The IFRAME element allows authors to insert a frame within a block
of text. Inserting an inline frame within a section of text is much
like inserting an object via the OBJECT element: they both allow you
to insert an HTML document in the middle of another, they may both be
aligned with surrounding text, etc. """
Yep, it says "HTML document".
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.
Because the "bad HTML" is generated at the server, dynamically.
By Microsoft software too, whodda thunk that.
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'
I'll rephrase, too...
'This is the code that creates the frame that does not
display the code, ON Opera BASED BROWSERS."
Firefox is not 'Opera based'. Nor is Konqueror or Galeon.
As these represent less than 30% of the market,
(http://marketshare.hitslink.com/report.aspx?qprid=0) I could just let it
go... But I won't.
On some reports the market is split roughly 3 ways with 30% each to
Firefox, IE6 and IE7. 10% to the rest.
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.
That is far more likely.
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.
Yes, it does. The iframe content is rendered on the client using whatever
tools are associated with the iframe content. Most Windows people associate
.txt with Notepad, but occasionally the association gets corrupted or
Notepad isn't working for some reason. The content of this particular iframe
is decided dynamically and can be text or pictures. When I view it using the
Browser it renders text in Notepad and pictures in IExplorer using it's
internal mime type associations.
The iframe is _NOT_ rendered by Notepad either with Firefox or IE. It
may be that if the .txt file is downloaded and 'opened' rather than
saved it may use Notepad.
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.
I believe that is out of date.
One of the reasons that I told Doc that I didn't use the word
'believe' is that it is taken as meaning 'holding something true
_in_spite_ of the evidence'.
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.
The content of the iframe (src=) does not require HTML any more.
It works on IE.
Thank you for that, Richard. I do appreciate you have fully tested this.
I will work to make it non-IE compatible.
Dillo got a 'Bad Request' from the server.
:-) I never heard of dillo, but am reminded of Kipling's armadillo
"dilloing" in its armour...
Was your 'fair and reasonable cross browser checks' both IE6 _and_ IE7
then ?
:-) Fair comment. No, it wasn't. I checked for the following: WCAG priority
1 and 2 and Access Board section 508. It passed OK, with zero warnings or
errors. I just did it again and now it has flagged a couple of
warnings...(both relating ot the iframe). I'll look into this.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Re: Kiwiland response to Richard
- From:
- Re: Kiwiland response to Richard
- From: Pete Dashwood
- Re: Kiwiland response to Richard
- References:
- Kiwiland response to Richard
- From: Pete Dashwood
- Re: Kiwiland response to Richard
- From: Richard
- Re: Kiwiland response to Richard
- From: Pete Dashwood
- Kiwiland response to Richard
- Prev by Date: Re: Here's one problem
- Next by Date: Re: Kiwiland response to Richard
- Previous by thread: Re: Kiwiland response to Richard
- Next by thread: Re: Kiwiland response to Richard
- Index(es):
Relevant Pages
|
