f



<body> & <div> Selectors Don't Work

   After much tedious effort (I'm slow at this), I have gotten the page 
code through the w3c Markup Validator: hoping to avoid comment here re: 
"clean up your code", etc.  (I agree that I should submit clean code...)
   Now, I'm encountering a frustrating inconsistency regarding the 
placement and usage of "font" elements, size in particular.  In the 
example linked below, I have tried to establish a base font-size in the 
<body> element: it works in some cases, but is ignored in others.  
Specifically, I am trying to use 1.3em in all elements, except in the 
image "captions".  In my code, the font-size set in the <body> is 
ignored in any and all <table> blocks.  I can achieve my goal if I 
declare a CSS selector (s120) and use it on all <td> elements.  (I don't 
think this is how it's supposed to be...)
   If I use the s120 class in the <div> or any of the <table> elements, 
all kind of nasty (and undesired) things happen.  The class="s120" in 
each <td> element is the only way I get what I want.
   Although Google searches guide my use of the <body> element for this 
sort of effect, it doesn't work for me.  I must be violating some rule I 
don't understand...or I have a syntax error that the Validator isn't 
catching.  Regardless, I need (your) advice.  TIA
  
	http://mrc5305.com/test10.htm


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

0
Mike
9/10/2016 10:34:51 PM
comp.authoring.stylesheets 8158 articles. 0 followers. mdmoura (161) is leader. Post Follow

22 Replies
218 Views

Similar Articles

[PageSpeed] 18

Mike Copeland wrote:

> After much tedious effort (I'm slow at this), ...
>   
> 	http://mrc5305.com/test10.htm

Please do at least fix the white-on-white completely invisible text - and 
the yellow-on-white hardly legible text - and then repost. All I see is a 
few scattered yellow words.

You should also be using the CSS validator:
http://jigsaw.w3.org/css-validator/


> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

Please go to your Avast options and set it to not add that spam in your 
messages, and there is no point to scan your outgoing posts. Thanks.

-- 
   -bts
   -This space for rent, but the price is high
0
Beauregard
9/10/2016 11:43:00 PM
Mike Copeland wrote:

> […] I'm slow […]

You are slower than a three-year old, and that’s an understatement.  Look, 
not everyone is born to be a Web author.  Maybe you should find a hobby that 
better suits you, like landscape gardening.

What I would usually write in *bold*, I will write in ALL-CAPS now, to 
perhaps get the message through to you…

>    Now, I'm encountering a frustrating inconsistency regarding the
> placement and usage of "font" elements, size in particular.  […] I have 
> tried to establish a base font-size in the <body> element: it works in 
> some cases, but is ignored in others.
> Specifically, I am trying to use 1.3em in all elements, except in the
> image "captions".  In my code, the font-size set in the <body> is
> ignored in any and all <table> blocks.
  ^^^^^^^
No, it is NOT.  STOP GUESSING and START LEARNING.  If your guesses were any 
good, you would NOT be here…

> I can achieve my goal if I declare a CSS selector (s120) and use it on all
> <td> elements.  (I don't think this is how it's supposed to be...)

READ about that font-size is INHERITED, and how RELATIVE font-size is 
calculated, in my PREVIOUS follow-up, in the PREVIOUS thread that you 
started.  Use the DEVELOPER TOOLS that I already recommended to you to SEE 
what is going on: “table” elements have a user agent stylesheet that sets 
their “font-size” property to “medium”.

And I have already told you that YOU SHOULD NOT USE A TABLE here in the 
first place.  If you would simply FOLLOW THE ADVICE that you have been given
your problem would VANISH in a puff of logic…

Please STOP starting a new thread for every little problem that you face.  
This is NOT a new problem.  This is NOT a free support forum either, it is a 
place for DISCUSSION: You need to WORK WITH US on the solution of ONE 
problem in ONE thread.

> ---
> This email 

For the last time, it is NOT an e-mail, but a newsgroup message, …

> has been checked for viruses […]

… and so it does NOT need to be checked for viruses as you SHOULD NOT post 
attached files here anyway.  This is a PLAIN-TEXT communications medium.  
And certainly this then-UNNECESSARY process does NOT need to be announced to 
the world.

Unless you display the shadow of a trace of a capacity for learning by 
disabling this spam, or at least display any desire to disable it, this was 
my final follow-up to you.  You have been warned.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
0
Thomas
9/11/2016 12:23:26 AM
On 09/10/2016 07:43 PM, Beauregard T. Shagnasty wrote:
> Mike Copeland wrote:
>
>> After much tedious effort (I'm slow at this), ...
>>
>> 	http://mrc5305.com/test10.htm
>
> Please do at least fix the white-on-white completely invisible text - and
> the yellow-on-white hardly legible text - and then repost. All I see is a
> few scattered yellow words.

I see white and yellow text on a blue background.

My Firefox is configured not to "Override the colors specified by the 
page with my selections above".

Black text on a white background if I override colors "Always".

0
WaltS
9/11/2016 1:31:34 PM
WaltS wrote:

> Beauregard T. Shagnasty wrote:
>> Mike Copeland wrote:
>>
>>> After much tedious effort (I'm slow at this), ...
>>>
>>> 	http://mrc5305.com/test10.htm
>>
>> Please do at least fix the white-on-white completely invisible text -
>> and the yellow-on-white hardly legible text - and then repost. All I
>> see is a few scattered yellow words.
> 
> I see white and yellow text on a blue background.

Further examination reveals that the body background color is not a color, 
but an *image* which for some reason doesn't show up for me, in some 
browsers. There is no background color specified either in the CSS or 
HTML. That's a bad practice in my opinion.

<body background="blue11.jpg">

> My Firefox is configured not to "Override the colors specified by the
> page with my selections above".

I am not seeing any of the images, including "blue11.jpg". Firefox doesn't 
like the pages. I'm looking at it with Fx 47 and with Fx 16, and none of 
the images will display in either - even when starting in Safe Mode. (The 
47 is new and relatively un-customized.)

I do see the images, including the background in, for example, the IceCat 
browser. I do NOT see the images in Opera.

-- 
   -bts
   -This space for rent, but the price is high
0
Beauregard
9/11/2016 4:01:42 PM
Beauregard T. Shagnasty wrote:

> Further examination reveals that the body background color is not a color, 
> but an *image* which for some reason doesn't show up for me, in some 
> browsers. There is no background color specified either in the CSS or 
> HTML. That's a bad practice in my opinion.
> 
> <body background="blue11.jpg">

This part of the original poster's problem
is straightforward.  He needs to change his
style sheet to something like:
     body {
            color: White; background-color: Blue; background-image: 
url("blue11.jpg");
          }

Note that if the image is plain blue then it
becomes redundant.

In Opera I cannot see the image either.  If
I try to view it on its own, I get an error
page "Error 403 - Forbidden: You don't have
permission to access this page or directory
listing on the server."  This may be why
people cannot see it.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/
0
Martin
9/11/2016 5:18:24 PM
WaltS wrote:
^^^^^
Your real name belongs there.

> On 09/10/2016 07:43 PM, Beauregard T. Shagnasty wrote:
>> Mike Copeland wrote:
>>> After much tedious effort (I'm slow at this), ...
>>>
>>> http://mrc5305.com/test10.htm
>>
>> Please do at least fix the white-on-white completely invisible text - and
>> the yellow-on-white hardly legible text - and then repost. All I see is a
>> few scattered yellow words.
> 
> I see white and yellow text on a blue background.
> 
> My Firefox is configured not to "Override the colors specified by the
> page with my selections above".
> 
> Black text on a white background if I override colors "Always".

The background of the text *is* white while the dark-blue, 300×168 pixel, 
1.4 KiB, background image is being downloaded and rendered, or if it is not 
rendered at all.  This is one aspect of a well-known, undesirable effect 
called “flash of unstyled content” (FOUC).

A proper stylesheet has to make sure that the color contrast between 
background and text is also appropriate while background images are loading, 
if they cannot be loaded, or if the user has defined another background.  
(And, of course if the background-image could be loaded and rendered, too.)

In this case, the HTML “background” attribute has been used instead of the 
(already) recommended “background-image” CSS property, and only the “color” 
CSS property has been set, to “white”, on the ”body” element:

  body {
    margin: 0 75px 0 75px;
    font: Verdana;
    font-size: 1.3em;
    color: White;
  }

    [The declared “Verdana” font family is _not_ used here for two reasons:

      1) The “font” property value has to contain at least a font-size and a 
         font-family, unless one of the system values like “caption” is used 
         (the CSS3 Fonts Module Level 3 Candidate Recommendation says so,
         and W3C CSS Validator and the Chrome DevTools “Styles” tab show 
         it);

      2) this *Windows* font is not installed by default on this
         *GNU/Linux* system.

    As a result, the default *serif* font (“Bitstream Vera Serif”) is used   
    instead.  The declaration should be

      body {
        /* … */
        font: 1.3em "Liberation Sans", FreeSans, "Nimbus Sans L",
                    Verdana, Helvetica, Geneva, sans-serif;
        /* … */
      }

    instead, with “sans-serif” being the generic font-family and always
    specified last.  (The free font “Liberation Sans” is used here then,
    otherwise “FreeSans” or “Nimbus Sans L”.  The “Arial” sans-serif font 
    family should not be used as it does not have proper metrics for the
    Web.  Some designers may frown on “Helvetica”, too.)]

This is equivalent to

  body {
    /* … */
    background-image: url(blue11.jpg);
    color: white;
    /* … */
  }

and has to be corrected; i.e., the “background” attribute specification on 
the “body” element has to be removed, and e.g.

  body {
    /* … */
    background: url(blue11.jpg) #036;
    color: white;
    /* … */
  }

has to be declared instead (I have chosen a color similar to the background 
image’s whose value does not depend on the color depth of the display – the 
“Eye Dropper” Chrome extension helped me to find it).

<https://www.w3.org/QA/Tips/color>
<https://www.w3.org/TR/WCAG20/#visual-audio-contrast>


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
0
Thomas
9/11/2016 5:32:47 PM
Thomas 'PointedEars' Lahn wrote:

> The background of the text *is* white while the dark-blue, 300×168 pixel,
> 1.4 KiB, background image is being downloaded and rendered, or if it is
> not rendered at all. […]

To clarify, the CSS default for the “background-color” property is 
“transparent”; if not specified by the Web author, the *effective* 
background color while the background image is loading depends on the user 
agent and the skin.  In *my* user agent, with *my* settings, it is white (as 
the text color default is “black”).

Therefore it is important to declare the background-color, too, if you 
declare the text color:

> <https://www.w3.org/QA/Tips/color>


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>
0
Thomas
9/11/2016 5:41:29 PM
Martin Leese wrote:

> Beauregard T. Shagnasty wrote:
> 
>> Further examination reveals that the body background color is not a
>> color,
>> but an *image* which for some reason doesn't show up for me, in some
>> browsers. There is no background color specified either in the CSS or
>> HTML. That's a bad practice in my opinion.
>> 
>> <body background="blue11.jpg">
> 
> This part of the original poster's problem is straightforward.  He needs
> to change his style sheet to something like:
>      body {
>         color: White; background-color: Blue; background-image:
url("blue11.jpg");
>           }

I would dump the image altogether and just use the color value for his 
particular shade of blue.

body {
   color: White; background-color: #13415b;
   }

...and of course remove the image from the <body> tag.

> In Opera I cannot see the image either.  If I try to view it on its own,
> I get an error page "Error 403 - Forbidden: You don't have permission to
> access this page or directory listing on the server."  This may be why
> people cannot see it.

Some browsers, no; some browsers, yes.  :-)  Best to design for ALL 
browsers.

In Firefox's Page View -> Media tool, none of his images are visible.

-- 
   -bts
   -This space for rent, but the price is high
0
Beauregard
9/11/2016 5:54:36 PM
On 09/10/2016 03:34 PM, Mike Copeland wrote:
> In my code, the font-size set in the <body> is 
> ignored in any and all <table> blocks. 
>
 IIRC the table element does not inherit the font specification. That
can be overridden with
table { font: inherit; }

  Using a table for layout is generally considered poor taste. The
preferred method is to float the image, adjust the margins of the
paragraphs to suit. It also has the advantage of not needing a special
override for font sizing.

-- 
James Moe
jmm-list at sohnen-moe dot com
Think.
0
James
9/11/2016 8:36:19 PM
11.9.2016, 23:36, James Moe wrote:

>  IIRC the table element does not inherit the font specification.

This depends on the browser and especially its mode, which depends, 
among other things, on the doctype declaration. Some old browsers had a 
bug (possibly intentional) that prevented some font properties from 
being inherited by tables. And modern browsers still widely simulate 
such bugs in “quirks mode”.

>   Using a table for layout is generally considered poor taste.

That’s a completely different issue, and largely a matter of taste as 
well as a cargo cult thing. (I’m referring to two different cults, the 
old one that uses tables as a tool for almost everything and the new one 
that curses tables and often favors approaches that are much more 
problematic than simple layout tables can ever be – even using CSS 
formatting instead of <table> for data that is inherently and heavily 
tabular.)

> The
> preferred method is to float the image, adjust the margins of the
> paragraphs to suit.

Preferred by some people in some contexts. There is a wide range of 
approaches to layout. Sometimes floating is adequate, sometimes it 
creates pitfalls and trouble. It also depends on the type of layout; 
floating is a rather special thing, as opposite to e.g. CSS positioning.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
0
Jukka
9/11/2016 8:56:23 PM
Jukka K. Korpela wrote:

> 11.9.2016, 23:36, James Moe wrote:
>>  IIRC the table element does not inherit the font specification.
> 
> This depends on the browser and especially its mode, which depends,
> among other things, on the doctype declaration. Some old browsers had a
> bug (possibly intentional) that prevented some font properties from
> being inherited by tables. And modern browsers still widely simulate
> such bugs in “quirks mode”.

It was not a bug, but a feature; the idea was that content in *data* tables 
is *data*, and, being potentially a lot of data, should not be rendered in 
the same font-size as the rest of the document because that would make the 
presentation too large.  It were the people who started misusing tables 
solely for layout who encountered the fact that this sensible default did 
not play well with their misuse (as we can see here).

And nothing is "simulated" in modern browsers; where the behavior occurs, 
“table” elements have

  font-size: medium;

set in the user agent stylesheet, which is equivalent to

  font-size: 1rem;

in *all* rendering modes.
 
>>   Using a table for layout is generally considered poor taste.
> 
> That’s a completely different issue, and largely a matter of taste as
> well as a cargo cult thing.

Incorrect, wishful thinking.

> (I’m referring to two different cults, the old one that uses tables as a
> tool for almost everything and the new one that curses tables and often
> favors approaches that are much more problematic than simple layout tables
> can ever be – even using CSS formatting instead of <table> for data that
> is inherently and heavily tabular.)

There are a number of layout issues with layout tables; most notably, that 
they do not adapt nicely to viewport size changes, especially not where CSS 
is not (fully) supported (such as in text browsers).

The difference between table markup and table styles is that the latter 
provide the benefit of tabular presentation where CSS is (fully) supported, 
and that they can be more easily adapted to changing viewport conditions; 
however, they should be used sparingly, and then carefully.

Table markup is useful where there is tabular data, and then it is possible, 
e.g. by setting “display: block” on “tr”, “th” and “td” elements in media-
query triggered rulesets, to have a semantic, responsive data table in *all* 
presentation media.

>> The preferred method is to float the image, adjust the margins of the
>> paragraphs to suit.
> 
> Preferred by some people in some contexts. There is a wide range of
> approaches to layout. Sometimes floating is adequate, sometimes it
> creates pitfalls and trouble. It also depends on the type of layout;
> floating is a rather special thing, as opposite to e.g. CSS positioning.

Given the space that is currently wasted in the screen presentation of this 
particular HTML document for the image column, which makes it longer (and 
more to scroll) than its content would otherwise require, it would benefit 
greatly by switching from HTML 4.01 with asemantic layout tables to semantic 
HTML5 with CSS-floated “figure” elements, among other things.  BTDT.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
0
Thomas
9/11/2016 10:23:28 PM
12.9.2016, 1:23, Lahn the troll wrote:

> It was not a bug, but a feature; the idea was that content in *data* tables
> is *data*,

Thank you for starting this troll message of yours with something that 
can be recognized as trolling so easily. You’re inventing your own 
history, where early tagsoup browsers are described as caring about 
“data tables” as opposite to “layout tables” and for that reason 
breaking CSS rules about (font property) inheritance. And, of course, 
the content of the troll message made no contribution whatsoever to 
solving the problems being discussed.

As usual, it would have been best to simply ignore Lahn’s trolling, but 
this piece was so hilarious in addition to being so revealing.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
0
Jukka
9/12/2016 10:14:37 AM
On 09/11/2016 01:56 PM, Jukka K. Korpela wrote:
>> >   Using a table for layout is generally considered poor taste.
> That’s a completely different issue, and largely a matter of taste as 
> well as a cargo cult thing.
>
  Well, okay, *I* consider it poor taste, even lazy. CSS can be a
difficult in some situations, and using a table just gets the job done.
  I have a stronger opinion the desirability of table-for-layout. The
method added more problems than it solved when adapting pages to work on
wide-screen desktops down to 300px-wide phones. CSS was ultimately a lot
easier.

-- 
James Moe
jmm-list at sohnen-moe dot com
Think.
0
James
9/12/2016 6:46:05 PM
In comp.infosystems.www.authoring.stylesheets message <MPG.323e3879c3b0a
c59896d4@news.eternal-september.org>, Sat, 10 Sep 2016 15:34:51, Mike
Copeland <mrc2323@cox.net> posted:

>   After much tedious effort (I'm slow at this), I have gotten the page
>...
>       http://mrc5305.com/test10.htm


Picture "The Copeland's Winnetka house" :

(1) The apostrophe should follow the "s".

(2) The image JPG file is 623*600 px, but you display it with
<img ... height="288" width="388">.  So you make every user receive 3.35
times as many pixels as needed, then scale it down, and see a distorted
image.

(2) In the text, I see "counselors ... counsellor".  I think those words
should each have the same number of "l"s.

>---

That line should be   minus minus space



-- 
 (c) John Stockton, Surrey, UK.  �@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.


0
Dr
9/12/2016 9:18:29 PM
Thomas 'PointedEars' Lahn wrote:

> Jukka K. Korpela wrote:
>> 11.9.2016, 23:36, James Moe wrote:
>>>  IIRC the table element does not inherit the font specification.
>> 
>> This depends on the browser and especially its mode, which depends,
>> among other things, on the doctype declaration. Some old browsers had a
>> bug (possibly intentional) that prevented some font properties from
>> being inherited by tables. And modern browsers still widely simulate
>> such bugs in “quirks mode”.
> 
> It was not a bug, but a feature; the idea was that content in *data*
> tables is *data*, and, being potentially a lot of data, should not be
> rendered in the same font-size as the rest of the document because that
> would make the presentation too large.  It were the people who started 
> misusing tables solely for layout who encountered the fact that this
> sensible default did not play well with their misuse (as we can see here).
> 
> And nothing is "simulated" in modern browsers; where the behavior occurs,
> “table” elements have
> 
>   font-size: medium;
> 
> set in the user agent stylesheet, which is equivalent to
> 
>   font-size: 1rem;
> 
> in *all* rendering modes.

I stand corrected as to “nothing is ‘simulated’” (the rest of my argument is 
still sound: one makes a jump to conclusions, a fallacy, when assuming that 
the historic behavior was a bug, i.e. unintentional).  In my Chromium 53 on 
GNU/Linux at least, it appears to be indeed the rendering in Quirks Mode 
(triggered by Mike’s DOCTYPE declaration without a recognized system 
identifier, i.e. a DTD URI) that causes this “font-size” declaration.

For example, in my HTML5 document, <http://PointedEars.de/es-matrix>, the 
user agent stylesheet for the “table” element is only

  table {
    display: table;
    border-collapse: separate;
    border-spacing: 2px;
    border-color: grey;
  }

while in Mike’s HTML document, which is declared to be HTML 4.01 
Transitional, it is

  table {
    white-space: normal;
    line-height: normal;
    font-weight: normal;
    font-size: medium;
    font-style: normal;
    color: -internal-quirk-inherit;
    text-align: start;
    font-variant: normal normal;
  }

and

  table {
    display: table;
    border-collapse: separate;
    border-spacing: 2px;
    border-color: grey;
  }
  
> [on why and when to use semantic markup]

Further reading: <http://html5doctor.com/lets-talk-about-semantics/>


PointedEars 
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann
0
Thomas
9/13/2016 7:39:04 PM
In article <I53LLCmlux1XFwd1@invalid.uk.co.demon.merlyn.invalid>, 
reply1600@merlyn.demon.co.uk.invalid says...
> 
> Picture "The Copeland's Winnetka house" :
> 
> (1) The apostrophe should follow the "s".
   Fixed
> 
> (2) The image JPG file is 623*600 px, but you display it with
> <img ... height="288" width="388">.  So you make every user receive 3.35
> times as many pixels as needed, then scale it down, and see a distorted
> image.
> 
> (3) In the text, I see "counselors ... counsellor".  I think those > 
words
> should each have the same number of "l"s.
   Fixed

   John, I really do appreciate this feedback.  However, I don't 
understand #2: the JPG file size issue.  It's true that the JPG files I 
have are displayed smaller than their actual size, but I don't 
understand the calculation imposition of the user.  Please explain 
what's happening...and why it's bad.
   BTW, I changed the sizes to the actual JPG sizes, and of course the 
images expand to much larger than I had intended.  8<{{  Is there a way 
to compress the images to be more like what I had intended?
   TIA

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

0
Mike
9/15/2016 12:06:18 AM
On Wed, 14 Sep 2016 17:06:18 -0700, Mike Copeland wrote:

> changed the sizes to the actual JPG sizes, and of course the 
> images expand to much larger than I had intended.  8<{{  Is there a way 
> to compress the images to be more like what I had intended?

Yes. If you have an image file with width W and height H that you'd like to
display at width w (or height h), you declare width=w and for the value of
height you use the calculated figure (w/W)xH (resp., you declare height=h
and for the value of width you use the calculated figure (h/H)xW. Any other
width height values will most likely destroy the aspect ratio. HTH.

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.
0
tlvp
9/15/2016 3:10:47 AM
On 9/14/2016 at 8:06 PM, Mike Copeland's prodigious digits fired off:
> In article <I53LLCmlux1XFwd1@invalid.uk.co.demon.merlyn.invalid>,
> reply1600@merlyn.demon.co.uk.invalid says...
>>
>> Picture "The Copeland's Winnetka house" :
>>
>> (1) The apostrophe should follow the "s".
>     Fixed
>>
>> (2) The image JPG file is 623*600 px, but you display it with
>> <img ... height="288" width="388">.  So you make every user receive 3.35
>> times as many pixels as needed, then scale it down, and see a distorted
>> image.
>>
>> (3) In the text, I see "counselors ... counsellor".  I think those >
> words
>> should each have the same number of "l"s.
>     Fixed
>
>     John, I really do appreciate this feedback.  However, I don't
> understand #2: the JPG file size issue.  It's true that the JPG files I
> have are displayed smaller than their actual size, but I don't
> understand the calculation imposition of the user.  Please explain
> what's happening...and why it's bad.
>     BTW, I changed the sizes to the actual JPG sizes, and of course the
> images expand to much larger than I had intended.  8<{{  Is there a way
> to compress the images to be more like what I had intended?
>     TIA
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

The point is that the actual image file size that must be downloaded is 
the real image size, not the defined displayed image size.  If a user is 
on dial-up that /may/ represent a negative imposition in terms of how 
fast the page loads for the user.

However, for /most/ users in this modern day of fast broadband there is 
really no issue.

Still, it's bad practice, generally, to use HTML to scale images.  There 
are many free image tools (irFanView) that can easily and quickly scale 
images.  Use them to, say, reduce an image of 4032x3024 to 900x675, 
from, say, 3Mb to 74Kb.

If, in this case, you scale the image using HTML, the user must still 
download the larger file.  It's trivial to me on a 100 Mb/s broadband 
link but it could be a slight pain to a dial-up user.



-- 
Ed Mullen
http://edmullen.net/
"We win justice quickest by rendering justice to the other party." - 
Mohandas Gandhi
0
Ed
9/15/2016 7:30:55 AM
15.9.2016, 10:30, Ed Mullen wrote:

> On 9/14/2016 at 8:06 PM, Mike Copeland's prodigious digits fired off:
 >
>> [...] I don't
>> understand #2: the JPG file size issue.  It's true that the JPG files I
>> have are displayed smaller than their actual size, but I don't
>> understand the calculation imposition of the user.
[...]
> The point is that the actual image file size that must be downloaded is
> the real image size, not the defined displayed image size.

Another point is that the quality of the image as scaled by a browser 
may be worse than as scaled by good image processing software. This used 
to be a problem especially when scaling upwards. In general, this 
problem has lost much of its relevance, since browsers have improved.

> However, for /most/ users in this modern day of fast broadband there is
> really no issue.

It is true that bandwidths are generally much better than in the early 
days of the Web. Yet, there are many circumstances where it still 
matters whether unnecessarily large amounts of data are transferred. 
Imagine a smartphone user in the countryside using Internet connection 
over phone network that does not always work that well, perhaps sharing 
this connection with a few devices around. (It works, but sometimes 
rather slow.)

There�s also the point that if you scale the image yourself, you see the 
result
and tune the scaling if needed. Of course you can see the result of 
scaling by a browser, too, but it is easier to fail to actually look at 
it. A good look may reveal that the image is really too small in that 
size, or should perhaps be cropped first, or otherwise modified so that 
it does its job well.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
0
Jukka
9/15/2016 11:21:41 AM
"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote

> It is true that bandwidths are generally much better than in the early 
> days of the Web. Yet, there are many circumstances where it still 
> matters whether unnecessarily large amounts of data are transferred. 
> Imagine a smartphone user in the countryside using Internet connection 
> over phone network that does not always work that well, perhaps sharing 
> this connection with a few devices around. (It works, but sometimes 
> rather slow.)
> 

I'm in Glendale, California near Los Angeles, with several cell towers near 
me, however, my home is in a dead zone, and I sometimes have to wait and 
wait and wait for some huge image to come down while I'm waiting for the 
actual article to come down.  Sometimes, I wish I still HAD dial up!
0
Adrienne
9/16/2016 7:01:09 PM
In comp.infosystems.www.authoring.stylesheets message <MPG.324393e0fbaa2
2d99896d6@news.eternal-september.org>, Wed, 14 Sep 2016 17:06:18, Mike
Copeland <mrc2323@cox.net> posted:

>In article <I53LLCmlux1XFwd1@invalid.uk.co.demon.merlyn.invalid>,
>reply1600@merlyn.demon.co.uk.invalid says...
>>
>> Picture "The Copeland's Winnetka house" :
>>
>> (1) The apostrophe should follow the "s".
>   Fixed
>>
>> (2) The image JPG file is 623*600 px, but you display it with
>> <img ... height="288" width="388">.  So you make every user receive 3.35
>> times as many pixels as needed, then scale it down, and see a distorted
>> image.
>>
>> (3) In the text, I see "counselors ... counsellor".  I think those >
>words
>> should each have the same number of "l"s.
>   Fixed
>
>   John, I really do appreciate this feedback.  However, I don't
>understand #2: the JPG file size issue.  It's true that the JPG files I
>have are displayed smaller than their actual size, but I don't
>understand the calculation imposition of the user.  Please explain
>what's happening...and why it's bad.
>   BTW, I changed the sizes to the actual JPG sizes, and of course the
>images expand to much larger than I had intended.  8<{{  Is there a way
>to compress the images to be more like what I had intended?

To add to what others have said :-

Also, Windows Paint can scale down.  My guess is that using it to scale
to 50% or 25%, repeated if necessary, will always give good results; and
you may be able to accept a power-of-two reduction, or find that Paint
scaling to the ideal size is visually acceptable.

I have here reasonably fast broadband; but there is clearly contention
for bandwidth, and the speed that I get can vary by a factor of more
than five.  Moreover, your site (as far as I know) is audibly
interesting; and might contend too much with whatever else I may be
using, such as <http://www.bbc.co.uk/programmes/b07tyx1q>.

It's better to scale once at the author's end, than to make scaling code
run remotely whenever a page is viewed.


On a vaguely related topic : Firefox Zoom can be set to Zoom Text Only,
which I like because many sites write too small and use quite enough
space for pictures already.  One may want an IMG element to scale with
the text, even with Firefox at ZTO; just scale it in em or ex units,
using a CSS style.

I used this in a page about Euler's work.  He sometimes used an old-
style Greek "beta"; Yucca may know its Unicode value, and know a font
containing the glyph, but I suspect few readers will have it.  Euler's
printer had the corresponding problem, and the archived PDF clearly
shows non-identical hand-written old-beta characters.  So I made a
little image of one of the better ones, and put it in the "text" as
&#976;/<img src="old-beta.png" style="width:0.57em;" alt="old-beta">.
&#976 is clearly a beta, but is clearly different to &beta;.

-- 
 (c) John Stockton, Surrey, UK.  �@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.


0
Dr
9/16/2016 10:33:16 PM
In article <nre080$94u$1@dont-email.me>,
 "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:

> Another point is that the quality of the image as scaled by a browser 
> may be worse than as scaled by good image processing software. This used 
> to be a problem especially when scaling upwards. In general, this 
> problem has lost much of its relevance, since browsers have improved.

It is still a problem when scaling upwards except for very modest 
amounts. Quite different from scaling down, where results are almost 
always pretty satisfactory.

-- 
dorayme
0
dorayme
9/17/2016 11:33:20 AM
Reply: