Html table / cell sizes are defined by the W3C as minimums
- adjusted for cell content if required
- interpreted by the browsers differently (if at all)
When you set a table / cell height (not universally supported by all browsers / platforms)
- all that does is set a minimum size for a non empty cell (browsers collapse empty cells)
If you add content in a cell that exceeds that height (as is the case in your last cell on bottom right)
- In Design view the Layout Table Cell properties are showing you WYSIWYG for IE
- the cell has become larger than 420 or 313 (what ever it is "set" to in code view) because of the content being more than will fit
in that set height, so the Layout tool is actually reporting what it will be when rendered in the browser - that is WYSIWYG
If you change the font size in the content (or reduce the content text) the Layout tool will show you a smaller height (up till the
minimum height you set in code)
Or if you want to reset the code view to match change the rendered size in the Cell Formatting Task pane
(of course that will change in the rendering browser based on the users screen resolution and other table / cell sizes in the page -
say if a use selects View Text Size largest)
PS
the height set in code view (view source from your site) for all your outer cells in the bottom table is 420, not 313
- select the correct cell in the Quick Tag Selector before switching to Code View
| This is the url.
http://www.geocities.com/jamiefraser.geo/tables7.htm
| The top table displays ok in IE,Netscape, Mozillia. Adding text in the right column of the lower table makes is push the footer
away from the table in Netscape and Mozilla but it is ok in IE. The source code for the td's for both tables show the height at 313
but the Front Page Editor is displaying the upper table at 313 and the lower table at 420. In other words, when I click on any of
those cells in the second row of the lower table, Front Page is showing the properties as 420 but when I view the code in Front
Page, it is 313.
| So my question now is, why is Front Page telling me one thing under Layout Table Cell properties and displaying another thing in
the code?
|
| "chris leeds" wrote:
|
| > put up your offending page and we'll take a look. there's _nothing_ that's
| > absolutely wysiwyg, if it was you wouldn't like what you see. ;-) it'd be as
| > restrictive as an iron maiden. (IMHO)
| >
| > --
| > Chris Leeds,
| > Microsoft MVP FrontPage
| >
| > The email address on this posting is a "black hole". I got tired of all the
| > spam.
| > Please feel free to contact me here:
| >
http://nedp.net/contact/
| > --
| >
| >
| > | > > Hi Kevin, I think maybe you need to go back and re-read some of the
| > advertising that MS has done on the FP Editor. They represented this as a
| > truly WYSIWYG editor thus making it "easy for those with little or no
| > knowledge of html coding skills" to create web pages. Now you are telling
| > me that I should not have bought this product because I don't know the
| > technology. Your statement does not make any sense because there are
| > millions of us out here that dont have this technology and would like to put
| > up some kind of web page and have it work resasonably well.
| > > Thats why we bought it.
| > >
| > > "Kevin Spencer" wrote:
| > >
| > > > Just because a carpenter knows all about building houses doesn't mean
| > that
| > > > he doesn't need a table saw. Not knowing anything about a technology is
| > > > about the worst reason I can think of for buying tools to use in that
| > > > technology. If you did know much about the technology, you would realize
| > how
| > > > silly a demand you are making of Microsoft.
| > > >
| > > > --
| > > > HTH,
| > > > Kevin Spencer
| > > > ..Net Developer
| > > > Microsoft MVP
| > > > Big things are made up
| > > > of lots of little things.
| > > >
| > > > | > > > > For some of us senior citizens the learning curve is much greater Dave
| > and
| > > > the ability to get out and take courses is also restricted. All I am
| > asking
| > > > is "why", if MS knows all these things exist, cant they as leaders in
| > the
| > > > field of this technology, make thier editor work in other browsers as
| > well.
| > > > They are the ones that know all about this code and how it works. If I
| > knew
| > > > how it worked, I would not have bought Front Page to create the code for
| > me.
| > > > >
| > > > > "dave" wrote:
| > > > >
| > > > > > For the same reason you cant be bothered to learn properly?
| > > > > >
| > > > > > | > > > > > > Why, in a nutshell, can't miscrosoft take into account the
| > > > irregularities
| > > > > > of the other browsers and design Front Page to produce code that
| > works
| > > > in
| > > > > > all browsers?
| > > > > > >
| > > > > > > "Mark Fitzpatrick" wrote:
| > > > > > >
| > > > > > > > The standards are only recommendations really. Netscape used to
| > be
| > > > the
| > > > > > > > absolute worste browser for standards compliance. Navigator 3.x
| > > > > > supported
| > > > > > > > HTML 3.0. Unfortunately, there never was an HTML 3.0, instead it
| > was
| > > > 3.2
| > > > > > and
| > > > > > > > rather different then what Netscape implemented in Navigator.
| > > > > > > >
| > > > > > > > Basically, there are tricks of getting things to look the same
| > in
| > > > all
| > > > > > > > browsers. For example, to ensure that a table cell is a certain
| > > > width,
| > > > > > place
| > > > > > > > a spacer image (a transparent gif that's 1 pixel wide by 1 pixel
| > > > high)
| > > > > > and
| > > > > > > > set it to the width that you need the cell to be. This stems
| > from
| > > > older
| > > > > > > > drafts of the HTML spec said that table widths are a recommended
| > > > > > minimums,
| > > > > > > > thus the browsers were able to ignore the width if the content
| > > > didn't
| > > > > > equal
| > > > > > > > that number. There are lots of little issues like this, even how
| > the
| > > > > > > > browsers render fonts, especially in things like text boxes.
| > > > > > > >
| > > > > > > > In a nutshell, each browser has it's own engine. Even the
| > Navigator
| > > > > > engine
| > > > > > > > is different then the current Mozilla engine as the current
| > Mozilla
| > > > > > browser
| > > > > > > > is several versions ahead of the Navigator 7 engine. Each design
| > > > team
| > > > > > builds
| > > > > > > > the engines using their interpretation of the standards, trying
| > to
| > > > > > implement
| > > > > > > > what they feel are the best set of items. To truly make
| > universal
| > > > > > designs,
| > > > > > > > you'll have to learn the tricks used for doing things in
| > particular
| > > > > > browsers
| > > > > > > > and trying to design accordingly.
| > > > > > > >
| > > > > > > > Hope this helps,
| > > > > > > > Mark Fitzpatrick
| > > > > > > > Microsoft MVP - FrontPage
| > > > > > > >
| > > > > > > > | > > > > > > > > Whenever you create a web page using Front Page and you view
| > it in
| > > > IE
| > > > > > and
| > > > > > > > every thing seems to work just the way you planned, why is it,
| > this
| > > > same
| > > > > > > > page can and oftren does, display differently in Netscape or
| > > > Mozilla. I
| > > > > > > > have read that Netscape-Mozilla interprets the code correctly
| > and IE
| > > > > > does
| > > > > > > > not. Is this true? If not, what is it that makes them display
| > > > > > differently?
| > > > > > > > >
| > > > > > > >
| > > > > > > >
| > > > > > > >
| > > > > >
| > > > > >
| > > > > >
| > > >
| > > >
| > > >
| >
| >
| >
