Values for Width and Height attributes

[tlvp]

For img, TABLE, and TD tags, I'm familiar with use of WIDTH attribute, and
for img and TR tags, with HEIGHT attribute as well, each with values of the
form: an integer (representing that many pixels); or a percentage (to
represent the relevant portion of the available space, where applicable).

Should it be possible to use lengths in other units as well, such as the
em, the centimeter (cm), the inch (in), the millimeter (mm), etc? If the
answer depends on the HTML level, please indicate how (weenie that I am,
I'm inclined to favor HTML 4.01 Transitional, myself :-) ).

Googling hasn't brought much insight, so I ask here, sorry. Thanks, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Jukka K. Korpela]

2013-05-01 8:02, tlvp wrote:

> For img, TABLE, and TD tags, I'm familiar with use of WIDTH attribute, and
> for img and TR tags, with HEIGHT attribute as well, each with values of the
> form: an integer (representing that many pixels); or a percentage (to
> represent the relevant portion of the available space, where applicable).

For attributes that specify dimensions, HTML has always (i.e., ever
since such attributes came to life) had their values with pixel as the
implied unit, and from HTML 4.0 onwards (and in browser practice before
that), percentage as the other option.

> Should it be possible to use lengths in other units as well, such as the
> em, the centimeter (cm), the inch (in), the millimeter (mm), etc? If the
> answer depends on the HTML level, please indicate how

No, not in HTML, only in CSS.

If you try to use, say, width="42mm" in HTML, browsers will interpret it
as width="42". That's because they parse the value using a routine that
scans an integer and stops as soon as it gets a character that cannot be
part of an integer. This is why width="42px" works, so to say, which may
have made people try other units, too.

As far as I can remember, there haven't even been any proposals or
browser-specific inventions that would have differed from this, except
the point-size attribute that Netscape invented for <font> and that died
with Netscape.

Oh, wait... one might say that the size attribute in <input> is a
dimension attribute of a kind, and it differs from the pattern. Its
value, specifying the suggested visible width of the input box, is
interpreted as a number of characters. This has never been defined
reasonably, since the widths of characters vary (except for monospace
fonts), usually a lot, and browsers have implemented the attribute in
very varying ways.

This isn't a serious restriction, since you can use CSS instead - even
directly embedded into an HTML tag, e.g. <td style="width: 3em"> or, to
use a nice though still poorly implemented CSS3 unit, <td style="width:
6ch">. (The ch unit intuitively means "average character width", but it
has been defined rigorously to denote the width of the digit "0".)

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

[dorayme]

In article <klq92s$25t$1...@dont-email.me>,

"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:

> If you try to use, say, width="42mm" in HTML, browsers will interpret it
> as width="42". That's because they parse the value using a routine that
> scans an integer and stops as soon as it gets a character that cannot be
> part of an integer. This is why width="42px" works, so to say, which may
> have made people try other units, too.

There is a Richard around these groups who famously used miles and was
rounded upon for it. <g>

--
dorayme

[David Stone]

In article <dorayme-F225FE...@news.albasani.net>,

Not parsecs? ;)

Note to OP: you can use other units in the CSS equivalents, although
there are some restrictions on what the height and width properties
can be applied to. See e.g.
<http://www.w3.org/TR/CSS21/syndata.html#value-def-length>
<http://www.w3.org/TR/CSS21/visudet.html#propdef-height>

More would be a discussion for a different group...

[David E. Ross]

You can choose between fixed and relative sizes, both in HTML and CSS.
However, you should be very, very cautious when using fixed sizes (e.g.,
cm) for width because (1) users have varying monitor dimensions and (2)
many users do not maximize their browser windows within the available
monitor dimensions.

If you ignore this warning about fixed sizes:

For users who have smaller monitors or who do not maximize their browser
windows, they might view your page as requiring annoying horizontal
scrolling. When I find such a page, I often go to a different Web site.

For users who have really large monitors and maximize their browser
windows, your Web page will not result in any advantage from that
configuration. If they chose such a large display because of visual
handicaps, your limiting of the displayed width could be a violation of
the Americans with Disabilities Act.

--
David E. Ross
<http://www.rossde.com/>

Are taxes too high in the U.S.? Check the bar graph
at <http://www.rossde.com/taxes/trickling.html> to see.

[Scott Bryce]

On 5/1/2013 9:34 AM, David E. Ross wrote:
> For users who have smaller monitors or who do not maximize their
> browser windows, they might view your page as requiring annoying
> horizontal scrolling. When I find such a page, I often go to a
> different Web site.
>
> For users who have really large monitors and maximize their browser
> windows, your Web page will not result in any advantage from that
> configuration. If they chose such a large display because of visual
> handicaps, your limiting of the displayed width could be a violation
> of the Americans with Disabilities Act.

In the most popular browsers it is very easy for the reader to resize
the page. I can't imagine this would be an issue any more. Even if you
use fixed widths, the reader ultimately has control over how large your
web page appears to him. Any time I pull up a new web page, without even
thinking about it, I resize the page until the font is a comfortable
size for these 50 yo+ eyes.

[tlvp]

On Wed, 1 May 2013 01:02:36 -0400, tlvp asked:

> For ... WIDTH ... and ... HEIGHT ...
> ... Should it be possible to use lengths in other units as well, such as the
> em, the centimeter (cm), the inch (in), the millimeter (mm), etc? ...

Thanks to Jukka, dorayme, the two Davids, Scott, and Tim, for your replies.
I take it the other units are grammatically OK only in an inline CSS
style="" phrasing, and might be of use to me there when I want to try a
quick and dirty test-printing of a page layout scheme involving text and
graphics modeled in a browser by an HTML page rather than worked up in
something like Word (which we have installed on only two older machines).

Not to worry, I'd never try to force such fixed real-world dimensions on a
public-facing web page -- at worst, I might specify percentage widths for
the cells of a table, and actual pixel counts for the width and height of
an IMG src= graphics file (to prevent that annoying browser 'bounce' once
the picture's done loading).

Cheers, and thanks again, -- tlvp

[richard]

I did?
I have used inches but never miles <snicker>.
But I will try it once and see how bad the browser hiccups.

[richard]

IMO, pixels are ideal images, while inches or mm are more suited to boxes.
And yes, modern browsers do recognize the "mm" or "in" after an integer.
So an image with an attribute of "42in" would be shown as 42 inches wide or
high.

[dorayme]

In article <14nhxu8r9mi1q.5y75ioytl506$.d...@40tude.net>,

and later

> IMO, pixels are ideal images, while inches or mm are more suited to boxes.
> And yes, modern browsers do recognize the "mm" or "in" after an integer.
> So an image with an attribute of "42in" would be shown as 42 inches wide or
> high.

On a screen?

OP was talking HTML attributes, not CSS. According to JK's posted
explanation of what browsers do in this regard, you could add the unit
of "aslongastheaveragelebabanesecucumber" after an integer and the
browser would not blink, nor implement this length but use pixels.

--
dorayme

[tlvp]

On Thu, 2 May 2013 23:23:12 -0400, richard wrote:

> IMO, pixels are ideal images, while inches or mm are more suited to boxes.

Wow. I always thought pixels were the individually addressable RGB units on
a LED display, while points, inches, and mm were linear measures of length,
suitable for measuring on displays, on paper, on boxes, on any real thing
(although far too often points and pixels get treated as synonymous, even
though they're really not, except on displays using 72 pixels per inch).

Thanks for setting me straight. Cheers, -- tlvp

[Jukka K. Korpela]

2013-05-03 9:48, tlvp wrote:

> On Thu, 2 May 2013 23:23:12 -0400, richard wrote:
>
>> IMO, pixels are ideal images, while inches or mm are more suited to boxes.
>
> Wow.

Just ignore "richard". Some of "richard's" messages are not as obviously
clueless as this one, so you might waste some time with them if you try
to take them seriously.

> I always thought pixels were the individually addressable RGB units on
> a LED display, while points, inches, and mm were linear measures of length,
> suitable for measuring on displays, on paper, on boxes, on any real thing

Well, points, inches, mm etc. don't exist as units in HTML, only in CSS.

And in CSS, neither the px nor the other units are really what they
sound like. It's a messy business, but the short version is that px need
not correspond to a screen pixel, and mm need not correspond to the
millimeter as a physical unit (or multiple of a unit); ditto for other
"physical" units. But the only direct implication on HTML is that even
the implied pixel unit in HTML may in reality be different from a screen
pixel, and increasingly often is (especially when a small device runs in
a mode where it simulates a larger screen by automatic scaling).

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

[David Stone]

In article <1fzehljaa33cs$.193rlj8f...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> On Thu, 2 May 2013 23:23:12 -0400, richard wrote:
>
> > IMO, pixels are ideal images, while inches or mm are more suited to boxes.
>
> Wow. I always thought pixels were the individually addressable RGB units on
> a LED display,

They used to be, but once monitors started shipping that could be set to
display at different resolutions, that went out the window so to speak ;)

In terms of image sizes, pixels refers to the discrete RGB data within
the image file; you can obviously redefine the physical size of the
displayed image in a number of different ways...

[richard]

because what it does not understand, it reverts to the default.

[richard]

The nay sayers fail to understand that a video screen is just another form
of paper.
What they fail to realise is, is that a pixel is not truly defined.
A pixel is defined by the screen resolution.
That is, a 1024x768 pixel is not the same as a 1920xwhatever pixel.
An inch, or millimeter, however, is precisely defined!
The problem with that is, the browser relies on DPI to define an inch.
Which means that an inch in 72dpi is not the same as 90dpi.
Which is wrong. DPI should not define fixed lengths.

I also like to point out that "point" is used for text.
As this is how the print on a paper based system is defined.
As a fallback, "em" should be used because that changes in accordance with
the point size.
Contrary to the nay sayers, em is not based on pixels.

[dorayme]

In article <1kwiqpafg8l0y$.ms3fkir...@40tude.net>,

richard <nor...@example.com> wrote:

> >> IMO, pixels are ideal images, while inches or mm are more suited to boxes.
> >> And yes, modern browsers do recognize the "mm" or "in" after an integer.
> >> So an image with an attribute of "42in" would be shown as 42 inches wide or
> >> high.
> >
> > On a screen?
> >
> > OP was talking HTML attributes, not CSS. According to JK's posted
> > explanation of what browsers do in this regard, you could add the unit
> > of "aslongastheaveragelebabanesecucumber" after an integer and the
> > browser would not blink, nor implement this length but use pixels.
>
> because what it does not understand, it reverts to the default.

Try

<table width="600" border="1">
<tr>
<td>Is this 600 pixels<br>
on your monitor?</td>
</tr>
</table>
<table width="600mm" border="1">
<tr>
<td>Is this 600mm<br>
on your monitor?</td>
</tr>
</table>
<table width="600aslongastheaveragelebanesecucumber" border="1">
<tr>
<td>Is this 600 times<br>
as long as the<br>
average lebanese<br>
cucumber on your monitor?</td>
</tr>
</table>

on a browser set to text only zoom and look at the widths. You should
find that generally good browsers make the second table (of
width="600mm") like the first at 600 pixels.

Btw, let me know if you come across a browser that roughly attempts
accuracy in regard to lebanese cucumbers.

--
dorayme

[richard]

http://1littleworld.net/box101.html

[dorayme]

In article <87ttixbe6g0i.12myy0zdehjwx$.d...@40tude.net>,

Not really relevant to HTML attributes. You are, of course, aware of
the distinction between such attributes and CSS and would have seen
the difference between the displayed in my markup above (to do with
attributes) and yours, to do with CSS styling.

Still, there are some interesting things in all of this to do with
CSS. Note how the CSS width in cucumbers and other such things makes
the browser ignore the whole styling. This alone should enable people
to see the difference between the CSS and the analogous HTML
attribute; in the latter the units are not of the allowed types, the
number alone is understood to be pixels, whilst in the former, at
least one of the allowed units is necessary.

By the way, your 12 inches - I am sure you once wanted to use miles -
does not cover 12 real inches on any of my screens. But something
around about is being tried!

--
dorayme

[Scott Bryce]

On 5/3/2013 9:56 PM, dorayme wrote:
> By the way, your 12 inches - I am sure you once wanted to use miles
> - does not cover 12 real inches on any of my screens. But something
> around about is being tried!

12 1/4 on mine. But I'm not surprised. The browser doesn't know how big
a pixel is on my monitor.

[dorayme]

In article <km223j$oib$1...@dont-email.me>,

I recall some software asking you to measure a particular line they
displayed so they could get to know your monitor better. Thought iCab
used to... but see no such facility now in prefs. The browsers can get
that you are on a 1920x1200 monitor etc but would need a bit more info
about the absolute size to do a good job.

--
dorayme

[Jonathan N. Little]

I am not sure what the "dingdong" unit was supposed to prove, except
that an invalid rule is to be ignored, so the div will default to "auto".

<http://www.littleworksstudio.com/temp/usenet/dingdongs.jpg>

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[richard]

I used dingdongs purely to show what happens when an invalid unit is used.
dorayme used html attributes in a table. A table has different rules and
thusly will display the chosen units differently.
In a table, if you set width or height, the default unit is pixels.
There is no need to define otherwise. And I believe, if you did, it
wouldn't be accepted and the table would ignore the error.

[Jonathan N. Little]

Actually the real point is that in HTML attributes use bare integers for
pixels and #% for percentage for the only other option. CSS on the other
hand *requires* units.

[dorayme]

In article <km31kq$ofk$1...@dont-email.me>,
"Jonathan N. Little" <lws...@gmail.com> wrote:

> dorayme wrote:
...

> > I recall some software asking you to measure a particular line they
> > displayed so they could get to know your monitor better. Thought iCab
> > used to... but see no such facility now in prefs. The browsers can get
> > that you are on a 1920x1200 monitor etc but would need a bit more info
> > about the absolute size to do a good job.
> >
>
> I am not sure what the "dingdong" unit was supposed to prove, except
> that an invalid rule is to be ignored, so the div will default to "auto".
>

As I said earlier when noting that CSS width in cucumbers and other

such things makes the browser ignore the whole styling.

FYI, a dingdong (introduced by Richard) is in the same class as
aslongasalebanesecucumber (introduced by me earlier). I don't know
what the general name for the class is, perhaps "bullshit unit"?

--
dorayme

[Jonathan N. Little]

dorayme wrote:

> FYI, a dingdong (introduced by Richard) is in the same class as
> aslongasalebanesecucumber (introduced by me earlier). I don't know
> what the general name for the class is, perhaps "bullshit unit"?

Yes I am aware, just bad quoting on my part.