Table cell width
 

Can anyone confirm that for Safari, the CSS width value for table cells
includes content, padding, and border where as for Firefox it relates
just to the content? That appears to be my empirical conculsion.

(this is with a table with fixed layout and cells with overflow hidden
and white-space nowrap)

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Re: Table cell width
 

In article
<timstreater-466EA2.23245331122011@news.individual.net>,
Tim Streater <timstreater@greenbee.net> wrote:

> Can anyone confirm that for Safari, the CSS width value for table cells
> includes content, padding, and border where as for Firefox it relates
> just to the content? That appears to be my empirical conculsion.
>
> (this is with a table with fixed layout and cells with overflow hidden
> and white-space nowrap)

I don't think this is a difference between the two (but which
versions exactly?). Perhaps you might show (text here or url) an
example of an html/css version you used in your empirical testing
where you see a difference. Include a doctype to avoid quirks
mode.

Try

<http://dorayme.netweaver.com.au/timTable.html>

and vary things like dotted (the dotted in above, combined with
turning off nowrap *does* reveal a difference between FF and
Safari, btw, but probably not one relevant to your question),
border-collapse, whatever you like.

--
dorayme

Re: Table cell width
 

In article <dorayme-FF55AF.11480101012012@news.albasani.net>,
dorayme <dorayme@optusnet.com.au> wrote:

> In article
> <timstreater-466EA2.23245331122011@news.individual.net>,
> Tim Streater <timstreater@greenbee.net> wrote:
>
> > Can anyone confirm that for Safari, the CSS width value for table cells
> > includes content, padding, and border where as for Firefox it relates
> > just to the content? That appears to be my empirical conculsion.
> >
> > (this is with a table with fixed layout and cells with overflow hidden
> > and white-space nowrap)
>
> I don't think this is a difference between the two (but which
> versions exactly?). Perhaps you might show (text here or url) an
> example of an html/css version you used in your empirical testing
> where you see a difference. Include a doctype to avoid quirks
> mode.

I think I may change approach here. What I actually want is a row of
buttons - but I don't want them to look like buttons. But I want them
all the same width and to shrink if more are produced (they are created
by JavaScript). The text label gets progressively chopped as they shrink.

I used a table because I needed to attach some state to each button, and
the easiest way was to have several hidden rows and to put the data
there. Normally the user gets to use Safari with my app, as that is the
browser my app's startup script launches. But I like to test the thing
with other browsers also and from time to time this throws up either
browser differences or errors which Safari appears to ignore.

But now I'm thinking it's gonna be a lot easier to use <div>s and use
some HTML5 element.dataset fields to store the data I need. One row of
<divs> which will simplify the JavaScript a bit too.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Re: Table cell width
 

In article
<timstreater-EAE51E.16491601012012@news.individual.net>,
Tim Streater <timstreater@greenbee.net> wrote:

> In article <dorayme-FF55AF.11480101012012@news.albasani.net>,
> dorayme <dorayme@optusnet.com.au> wrote:
>
> > In article
> > <timstreater-466EA2.23245331122011@news.individual.net>,
> > Tim Streater <timstreater@greenbee.net> wrote:
> >
> > > Can anyone confirm that for Safari, the CSS width value for table cells
> > > includes content, padding, and border where as for Firefox it relates
> > > just to the content? That appears to be my empirical conculsion.
> > >
....
> > I don't think this is a difference between the two ...
>
> I think I may change approach here. What I actually want is a row of
> buttons - but I don't want them to look like buttons. But I want them
> all the same width and to shrink if more are produced (they are created
> by JavaScript). The text label gets progressively chopped as they shrink.
>
> I used a table because I needed to attach some state to each button, and
> the easiest way was to have several hidden rows and to put the data
> there. Normally the user gets to use Safari with my app, as that is the
> browser my app's startup script launches. But I like to test the thing
> with other browsers also and from time to time this throws up either
> browser differences or errors which Safari appears to ignore.
>
> But now I'm thinking it's gonna be a lot easier to use <div>s and use
> some HTML5 element.dataset fields to store the data I need. One row of
> <divs> which will simplify the JavaScript a bit too.

OK. You might also consider a more semantic way, for example, a
horizontally styled list, a row of list items in a UL.

--
dorayme

Re: Table cell width
 

In article <dorayme-2BE773.05004202012012@news.albasani.net>,
dorayme <dorayme@optusnet.com.au> wrote:

> In article
> <timstreater-EAE51E.16491601012012@news.individual.net>,
> Tim Streater <timstreater@greenbee.net> wrote:
>
> > In article <dorayme-FF55AF.11480101012012@news.albasani.net>,
> > dorayme <dorayme@optusnet.com.au> wrote:
> >
> > > In article
> > > <timstreater-466EA2.23245331122011@news.individual.net>,
> > > Tim Streater <timstreater@greenbee.net> wrote:
> > >
> > > > Can anyone confirm that for Safari, the CSS width value for table cells
> > > > includes content, padding, and border where as for Firefox it relates
> > > > just to the content? That appears to be my empirical conculsion.

> > > I don't think this is a difference between the two ...
> >
> > I think I may change approach here. What I actually want is a row of
> > buttons - but I don't want them to look like buttons. But I want them
> > all the same width and to shrink if more are produced (they are created
> > by JavaScript). The text label gets progressively chopped as they shrink.
> >
> > I used a table because I needed to attach some state to each button, and
> > the easiest way was to have several hidden rows and to put the data
> > there. Normally the user gets to use Safari with my app, as that is the
> > browser my app's startup script launches. But I like to test the thing
> > with other browsers also and from time to time this throws up either
> > browser differences or errors which Safari appears to ignore.
> >
> > But now I'm thinking it's gonna be a lot easier to use <div>s and use
> > some HTML5 element.dataset fields to store the data I need. One row of
> > <divs> which will simplify the JavaScript a bit too.
>
> OK. You might also consider a more semantic way, for example, a
> horizontally styled list, a row of list items in a UL.

Mmm. They need to be clickable and at present, when clicked, I do a bit
of border style using inset/outset so they look pressed (or not). As
long as I can do that with a list it might even be easier than <div>s,
which when floated tend to have minds of their own.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Re: Table cell width
 

In article
<timstreater-F61DED.18383701012012@news.individual.net>,
Tim Streater <timstreater@greenbee.net> wrote:

>?> dorayme <dorayme@optusnet.com.au> wrote:
>
....
> > > But now I'm thinking it's gonna be a lot easier to use <div>s and use
> > > some HTML5 element.dataset fields to store the data I need. One row of
> > > <divs> which will simplify the JavaScript a bit too.
> >
> > OK. You might also consider a more semantic way, for example, a
> > horizontally styled list, a row of list items in a UL.
>
> Mmm. They need to be clickable and at present, when clicked, I do a bit
> of border style using inset/outset so they look pressed (or not). As
> long as I can do that with a list it might even be easier than <div>s,
> which when floated tend to have minds of their own.

Horizontal lists are not too hard to style and they behave pretty
well. And you can get pressed looks and all sorts of things. Not
sure they are *easier* than floated DIVs but I would be inclined
to use them instead, it is something that is more regularly done
(in navigation bars) and so there would be a lot more examples.

--
dorayme

Re: Table cell width
 

2012-01-01 18:49, Tim Streater wrote:

> What I actually want is a row of
> buttons - but I don't want them to look like buttons.

This would be a lot easier if you described either the desired visual
appearance (as some drawing) or the current page URL or both.

> I used a table because I needed to attach some state to each button, and
> the easiest way was to have several hidden rows and to put the data
> there.

Sounds complicated. If the setup is all JavaScript-driven, it sounds
like it would be easiest to store the data in an array of JavaScript
objects.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Re: Table cell width
 

In article <jdqbtg$hfr$1@dont-email.me>,
"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:

> 2012-01-01 18:49, Tim Streater wrote:
>
> > What I actually want is a row of
> > buttons - but I don't want them to look like buttons.
>
> This would be a lot easier if you described either the desired visual
> appearance (as some drawing) or the current page URL or both.

No URL as no data ever leaves the user's machine. I could put up a jpeg.

> > I used a table because I needed to attach some state to each button, and
> > the easiest way was to have several hidden rows and to put the data
> > there.
>
> Sounds complicated. If the setup is all JavaScript-driven, it sounds
> like it would be easiest to store the data in an array of JavaScript
> objects.

Mmmm, oddly enough I can't think now why I didn't do that originally. My
internal notes for the app give no hint. Perhaps I hadn't heard of
JavaScript objects at that point, odd though that may sound. I think I
might still prefer the HTML5 approach - less housekeeping.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Re: Table cell width
 

In article <dorayme-76060F.06073602012012@news.albasani.net>,
dorayme <dorayme@optusnet.com.au> wrote:

> In article
> <timstreater-F61DED.18383701012012@news.individual.net>,
> Tim Streater <timstreater@greenbee.net> wrote:
>
> >?> dorayme <dorayme@optusnet.com.au> wrote:
> >
> ...
> > > > But now I'm thinking it's gonna be a lot easier to use <div>s and use
> > > > some HTML5 element.dataset fields to store the data I need. One row of
> > > > <divs> which will simplify the JavaScript a bit too.
> > >
> > > OK. You might also consider a more semantic way, for example, a
> > > horizontally styled list, a row of list items in a UL.
> >
> > Mmm. They need to be clickable and at present, when clicked, I do a bit
> > of border style using inset/outset so they look pressed (or not). As
> > long as I can do that with a list it might even be easier than <div>s,
> > which when floated tend to have minds of their own.
>
> Horizontal lists are not too hard to style and they behave pretty
> well. And you can get pressed looks and all sorts of things. Not
> sure they are *easier* than floated DIVs but I would be inclined
> to use them instead, it is something that is more regularly done
> (in navigation bars) and so there would be a lot more examples.

Righto - thanks - more research to do then.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Re: Table cell width
 

In article
<timstreater-1D7329.21264301012012@news.individual.net>,
Tim Streater <timstreater@greenbee.net> wrote:
....

> > >
> > > Mmm. They need to be clickable and at present, when clicked, I do a bit
> > > of border style using inset/outset so they look pressed (or not). As
> > > long as I can do that with a list it might even be easier than <div>s,
> > > which when floated tend to have minds of their own.
> >

> dorayme
>
> > Horizontal lists are not too hard to style and they behave pretty
> > well. And you can get pressed looks and all sorts of things. Not
> > sure they are *easier* than floated DIVs but I would be inclined
> > to use them instead, it is something that is more regularly done
> > (in navigation bars) and so there would be a lot more examples.
>

> Righto - thanks - more research to do then.

When you style the UL and you almost certainly don't want to be
bothered by bullet points or the space allotted to them by
default margins and/or paddings. Zero margin and padding on the
parent element to bypass these defaults.

If you do not specify a width on the LIs (which is perfectly fine
of course), they will have a width that is shrunk auto to just
fit the content and no more. If you do give a fixed width, you
need to watch any children of the LIs to be sure they are of a
size you want, you may want them to fill the full width, an
inline element like an A will not but you can sort this by
telling the A to be 100% wide of its LI parent.

--
dorayme