I don't use the Table Layout Tool because it only works in px and is too restrictive
- and don't set the height of any cells containing just text content
- the only place a cell height in px makes sense is when you are trying to "trap" images of a fixed px size
| Thanks for the reply Stefan......I don't recall having this problem with the standard tables, only with the layout tables in
FP2003. The standard tables did not specify a height attribute and the layout tables do, so from what I can see, whenever content
exceeds that initial height value, I have to go in and change the code to the size specified in the layout cell formatting pane, is
that correct??
|
| "Stefan B Rusynko" wrote:
|
| > 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
| > --
| >
| > _____________________________________________
| > SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
| > "Warning - Using the F1 Key will not break anything!" (-;
| > To find the best Newsgroup for FrontPage support see:
| >
http://www.net-sites.com/sitebuilder/newsgroups.asp
| > _____________________________________________
| >
| >
| > | 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?
| > | > > > > > > > >
| > | > > > > > > >
| > | > > > > > > >
| > | > > > > > > >
| > | > > > > >
| > | > > > > >
| > | > > > > >
| > | > > >
| > | > > >
| > | > > >
| > | >
| > | >
| > | >
| >
| >
| >
