Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Help! Three puzzling MS style-invocations
1 view
Skip to first unread message
tlvp
May 16, 2012, 12:06:16 AM5/16/12
to
OK, I guess I understand what to expect from the style-specification
| text-align:justify; /* 0 */
but what do I make of this?
| text-justify:inter-ideograph; /* 1 */
(All text in the document in question is using Latin characters, at times
decorated with a diacritical mark chosen from among just a few relatively
common ones (acute, grave, circumflex, umlaut, ogonek, and their closest
relatives), but nothing properly "ideographic" like Japanese Kanji or
Chinese glyphs or the like.)
Is that just MS being ornery, and covering all bases, even those that are
thousands of km away from the document involved? Should I imagine I might
safely strike that fragment from the CSS that MS is offering me without any
harm to the visible presentation of that document?
And what about these?
| punctuation-wrap:simple; /* 2 */
| text-autospace:none; /* 3 */
Thanks for reassuring me that these are (I hope) all pretty pointless for
mere mortals, or else warning me why they're really not at all so :-) .
Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
| text-align:justify; /* 0 */
but what do I make of this?
| text-justify:inter-ideograph; /* 1 */
(All text in the document in question is using Latin characters, at times
decorated with a diacritical mark chosen from among just a few relatively
common ones (acute, grave, circumflex, umlaut, ogonek, and their closest
relatives), but nothing properly "ideographic" like Japanese Kanji or
Chinese glyphs or the like.)
Is that just MS being ornery, and covering all bases, even those that are
thousands of km away from the document involved? Should I imagine I might
safely strike that fragment from the CSS that MS is offering me without any
harm to the visible presentation of that document?
And what about these?
| punctuation-wrap:simple; /* 2 */
| text-autospace:none; /* 3 */
Thanks for reassuring me that these are (I hope) all pretty pointless for
mere mortals, or else warning me why they're really not at all so :-) .
Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
Jukka K. Korpela
May 16, 2012, 1:07:06 AM5/16/12
to
2012-05-16 7:06, tlvp wrote:
> OK, I guess I understand what to expect from the style-specification
>
> | text-align:justify; /* 0 */
It's trickier than it looks like. The methods of justification have not
> OK, I guess I understand what to expect from the style-specification
>
> | text-align:justify; /* 0 */
been specified, and they may vary by browser, content language, phase of
the moon, etc. But in general, *I* would expect ugly results, since
usually browsers a) apply simple methods that just increase inter-word
spacing, b) do not hyphenate words, and c) often have to work under
constraints that make the column narrow (perhaps just a few words per line).
> but what do I make of this?
>
> | text-justify:inter-ideograph; /* 1 */
it means:
"Justification primarily changes spacing at word separators and between
characters in block scripts. This value is typically used for CJK
languages."
I would expect even IE apply that, more or less, in the versions that
support this setting. The text-justify property was probably invented by
Microsoft but originally implemented with a few values only. Their document
http://msdn.microsoft.com/en-us/library/ms531172%28v=vs.85%29
describes the setting as follows:
"Justifies lines of ideographic text, and increases or decreases both
inter-ideograph and inter-word spacing."
That page is obscure about implementation details, but it seems that
this value was introduced in IE 8 and that in "Standards Mode", you can
alternatively use the name -ms-text-justify for it.
Anyway, I would not expect this setting to have much effect unless the
text contains so-called Chinese-Japanese-Korean characters,
"ideographs". If the text contains them, then the setting affects the
way justification is made, on some browsers, probably in a useful way.
> (All text in the document in question is using Latin characters, at times
> decorated with a diacritical mark chosen from among just a few relatively
> common ones (acute, grave, circumflex, umlaut, ogonek, and their closest
> relatives), but nothing properly "ideographic" like Japanese Kanji or
> Chinese glyphs or the like.)
non-default value. The default is auto, and its meaning is up to the
browser. So the declaration _could_ have an effect. The details of
justification are browser-dependent, and a browser could use different
algorithms for texts in Latin letters, too, for different values.
My tests suggest that there is no difference on IE 9. This is what I
expected, but there is really no guarantee.
> Is that just MS being ornery, and covering all bases, even those that are
> thousands of km away from the document involved?
> Should I imagine I might
> safely strike that fragment from the CSS that MS is offering me without any
> harm to the visible presentation of that document?
there is always a 0.1% chance of making silly mistakes in routine
operations - one of the reasons for "if it works, don't clean it up").
And if it has an effect, there is no reason to expect it to be harmful;
rather the contrary.
> And what about these?
>
> | punctuation-wrap:simple; /* 2 */
> | text-autospace:none; /* 3 */
For the latter, presented as -ms-text-autospace, the page
http://msdn.microsoft.com/en-us/library/ms531164%28v=vs.85%29 refers to
"CSS Text Level 3, Section 9.4", but there isn't even such a section in
the current CSS3 Text draft. Moreover, the initial value, according to
the Microsoft page, is none, so the declaration would do nothing except
for possibly removing the effect of setting this property in other style
sheets (like a user style sheet).
The former has appeared in some drafts and proposals, e.g.
http://www.w3.org/TR/1999/WD-i18n-format-19990322/#a6-1
Note the statement "this property may in the future be expanded to cover
other punctuation behaviors behaviors for other types of punctuation as
well, not just full-width". It would in fact be an interesting feature
in styling, even for Western texts, as it might be used to achieve
"optical justification" instead of mechanical. But it seems that the
idea has been abandoned for now.
To summarize, the odds for getting nasty effects, or *any* effects, from
these declarations, especially for English text, are very, very small.
But Microsoft's idea of ejecting them, apparently for global safety, is
distorted.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
tlvp
May 16, 2012, 2:04:45 AM5/16/12
to
On Wed, 16 May 2012 08:07:06 +0300, Jukka K. Korpela wrote (and I lazily do
not trim any of it):
Thanks, Jukka, I'm sorry to be needing these tutorials, but I'm grateful
you're willing to offer them so helpfully and so freely. Cheers, -- tlvp
not trim any of it):
you're willing to offer them so helpfully and so freely. Cheers, -- tlvp
tlvp
May 16, 2012, 11:59:24 PM5/16/12
to
On Wed, 16 May 2012 00:06:16 -0400, tlvp wrote:
> ... but what do I make of this?
| <span style='font-size:12.0pt;mso-fareast-font-family:"Times New Roman";mso-fareast-language:EN-US'></span>
Yup: that's something MS Word thought it desirable to insert just before a
closing </P>, with empty content 'twixt opening and closing SPAN tags.
What can Word have been intending? And can I not safely purge it?
TIA; and cheers, -- tlvp
> ... but what do I make of this?
| <span style='font-size:12.0pt;mso-fareast-font-family:"Times New Roman";mso-fareast-language:EN-US'></span>
Yup: that's something MS Word thought it desirable to insert just before a
closing </P>, with empty content 'twixt opening and closing SPAN tags.
What can Word have been intending? And can I not safely purge it?
TIA; and cheers, -- tlvp
dorayme
May 17, 2012, 2:47:43 AM5/17/12
to
In article <k67qrf14q8m4.141ut5pwwz2bg$.d...@40tude.net>,
yourself to this grunting snoring fat companion. Note the difference
between the two paragraphs in
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Inline boxes</title>
<style type="text/css" media="screen">
p {font-size: 100%; border: 1px solid;}
</style>
</head>
<body>
<p>text...</p>
<p>text ...<span style="font-size: 8em;"></span></p>
</body>
</html>
If that difference is something you want, you can easily get it by
styling Ps to suit. The above is an exaggerated example to show that
what counts is the interdependencies in the document and styling. Even
empty elements get themselves ready for the moment content enters,
they allow for the appropriate height of any unsuspecting text that
might wander in there.
Think of it this way: an innocent sentence "Cras vel eros." is
wandering around and stumbles into the span. Quick smart, that span
grabs it as if it is a baker with a bit of dough and no matter how big
or how small it was before, he shapes it to have the height that that
span is predetermined to have. If this text does not wander in, well,
the height is still there ready and waiting to accommodate the size,
the ascenders and descenders.
--
dorayme
tlvp <mPiOsUcB...@att.net> wrote:
> On Wed, 16 May 2012 00:06:16 -0400, tlvp wrote:
>
> > ... but what do I make of this?
>
> | <span style='font-size:12.0pt;mso-fareast-font-family:"Times New
> Roman";mso-fareast-language:EN-US'></span>
>
> Yup: that's something MS Word thought it desirable to insert just before a
> closing </P>, with empty content 'twixt opening and closing SPAN tags.
>
> What can Word have been intending? And can I not safely purge it?
>
No, you can't. Once you get into bed with the devil, you accommodate
> On Wed, 16 May 2012 00:06:16 -0400, tlvp wrote:
>
> > ... but what do I make of this?
>
> | <span style='font-size:12.0pt;mso-fareast-font-family:"Times New
> Roman";mso-fareast-language:EN-US'></span>
>
> Yup: that's something MS Word thought it desirable to insert just before a
> closing </P>, with empty content 'twixt opening and closing SPAN tags.
>
> What can Word have been intending? And can I not safely purge it?
>
yourself to this grunting snoring fat companion. Note the difference
between the two paragraphs in
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Inline boxes</title>
<style type="text/css" media="screen">
p {font-size: 100%; border: 1px solid;}
</style>
</head>
<body>
<p>text...</p>
<p>text ...<span style="font-size: 8em;"></span></p>
</body>
</html>
If that difference is something you want, you can easily get it by
styling Ps to suit. The above is an exaggerated example to show that
what counts is the interdependencies in the document and styling. Even
empty elements get themselves ready for the moment content enters,
they allow for the appropriate height of any unsuspecting text that
might wander in there.
Think of it this way: an innocent sentence "Cras vel eros." is
wandering around and stumbles into the span. Quick smart, that span
grabs it as if it is a baker with a bit of dough and no matter how big
or how small it was before, he shapes it to have the height that that
span is predetermined to have. If this text does not wander in, well,
the height is still there ready and waiting to accommodate the size,
the ascenders and descenders.
--
dorayme
tlvp
May 17, 2012, 3:34:06 AM5/17/12
to
On Thu, 17 May 2012 16:47:43 +1000, dorayme wrote:
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <meta http-equiv="content-type" content="text/html; charset=utf-8">
> <title>Inline boxes</title>
> <style type="text/css" media="screen">
> p {font-size: 100%; border: 1px solid;}
> </style>
> </head>
> <body>
> <p>text...</p>
> <p>text ...<span style="font-size: 8em;"></span></p>
> </body>
> </html>
Interesting, dorayme; thanks. In IE 7, there's no difference I can discern
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <meta http-equiv="content-type" content="text/html; charset=utf-8">
> <title>Inline boxes</title>
> <style type="text/css" media="screen">
> p {font-size: 100%; border: 1px solid;}
> </style>
> </head>
> <body>
> <p>text...</p>
> <p>text ...<span style="font-size: 8em;"></span></p>
> </body>
> </html>
in how those two P elements render. Ah, but in my antique FF 3.6.28, oh
what a difference! I never knew coffee served without milk could taste so
different from coffee served instead without cream :-) .
Moral, for me at any rate: elements with empty content and absent elements
are even more different one from the other, conceptually, than are empty
passwords and absent passwords.
Thanks for the eye-opener. Cheers, -- tlvp
dorayme
May 17, 2012, 5:50:23 AM5/17/12
to
In article <13u9hxby6r9wd.15lwp6rph17wz$.d...@40tude.net>,
> Moral, for me at any rate: elements with empty content and absent elements
> are even more different one from the other, conceptually, than are empty
> passwords and absent passwords.
>
Also look at what happens when you have a legit and available image
but specify it to be zero width in an img element. In some browsers,
height room is provided for tall, zero-thin non-appearences.
--
dorayme
tlvp <mPiOsUcB...@att.net> wrote:
> On Thu, 17 May 2012 16:47:43 +1000, dorayme wrote:
>
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> > "http://www.w3.org/TR/html4/strict.dtd">
> > <html>
> > <head>
> > <meta http-equiv="content-type" content="text/html; charset=utf-8">
> > <title>Inline boxes</title>
> > <style type="text/css" media="screen">
> > p {font-size: 100%; border: 1px solid;}
> > </style>
> > </head>
> > <body>
> > <p>text...</p>
> > <p>text ...<span style="font-size: 8em;"></span></p>
> > </body>
> > </html>
>
> Interesting, dorayme; thanks. In IE 7, there's no difference I can discern
> in how those two P elements render. Ah, but in my antique FF 3.6.28, oh
> what a difference! ...
> On Thu, 17 May 2012 16:47:43 +1000, dorayme wrote:
>
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> > "http://www.w3.org/TR/html4/strict.dtd">
> > <html>
> > <head>
> > <meta http-equiv="content-type" content="text/html; charset=utf-8">
> > <title>Inline boxes</title>
> > <style type="text/css" media="screen">
> > p {font-size: 100%; border: 1px solid;}
> > </style>
> > </head>
> > <body>
> > <p>text...</p>
> > <p>text ...<span style="font-size: 8em;"></span></p>
> > </body>
> > </html>
>
> Interesting, dorayme; thanks. In IE 7, there's no difference I can discern
> in how those two P elements render. Ah, but in my antique FF 3.6.28, oh
> Moral, for me at any rate: elements with empty content and absent elements
> are even more different one from the other, conceptually, than are empty
> passwords and absent passwords.
>
but specify it to be zero width in an img element. In some browsers,
height room is provided for tall, zero-thin non-appearences.
--
dorayme
tlvp
May 17, 2012, 4:23:24 PM5/17/12
to
On Thu, 17 May 2012 19:50:23 +1000, dorayme wrote:
> Also look at what happens when you have a legit and available image
> but specify it to be zero width in an img element. In some browsers,
> height room is provided for tall, zero-thin non-appearences.
Ah, for IMG elements I've learned: specify only one of height= or width=
> Also look at what happens when you have a legit and available image
> but specify it to be zero width in an img element. In some browsers,
> height room is provided for tall, zero-thin non-appearences.
values at your own peril -- I never know what a browser will choose for the
other. So I generally specify both; or, rarely, neither, and that for small
images only, whose delayed rendering won't unduly relocate material already
rendered.
Thanks for the remark. Cheers, -- tlvp
dorayme
May 17, 2012, 6:53:08 PM5/17/12
to
In article <1srn1n4jyjo91.1...@40tude.net>,
that in some way or other had content that might seem not to need a
browser to reserve space. In the case of the span, there was no
content, but the styling said to make any possible text a certain
size. In the example I gave you, it was an image that had no width and
so could not appear at all, yet some browsers at least reserve the
height space for the possibility given that the HTML height attribute
is so specified.
About the point you say you have learnt. Not sure it applies so much
to modern browsers. I don't know or have forgotten if there are any
browsers that do not take the natural aspect ratio of pictures like
gifs, pngs, jpgs and calculate the other dimension from the one
supplied.
Some used to think it a good idea to specify both to save time and
jerkiness, the browser able to prepare fully for the space without
having to fetch bits of info and calculate. These days, with faster
internet and processors, not sure it is such a big deal, it is not
such a *peril*.
--
dorayme
tlvp <mPiOsUcB...@att.net> wrote:
> On Thu, 17 May 2012 19:50:23 +1000, dorayme wrote:
>
> > Also look at what happens when you have a legit and available image
> > but specify it to be zero width in an img element. In some browsers,
> > height room is provided for tall, zero-thin non-appearences.
>
> Ah, for IMG elements I've learned: specify only one of height= or width=
> values at your own peril
My point was related to your earlier enquiry. It was about elements
> On Thu, 17 May 2012 19:50:23 +1000, dorayme wrote:
>
> > Also look at what happens when you have a legit and available image
> > but specify it to be zero width in an img element. In some browsers,
> > height room is provided for tall, zero-thin non-appearences.
>
> Ah, for IMG elements I've learned: specify only one of height= or width=
> values at your own peril
that in some way or other had content that might seem not to need a
browser to reserve space. In the case of the span, there was no
content, but the styling said to make any possible text a certain
size. In the example I gave you, it was an image that had no width and
so could not appear at all, yet some browsers at least reserve the
height space for the possibility given that the HTML height attribute
is so specified.
About the point you say you have learnt. Not sure it applies so much
to modern browsers. I don't know or have forgotten if there are any
browsers that do not take the natural aspect ratio of pictures like
gifs, pngs, jpgs and calculate the other dimension from the one
supplied.
Some used to think it a good idea to specify both to save time and
jerkiness, the browser able to prepare fully for the space without
having to fetch bits of info and calculate. These days, with faster
internet and processors, not sure it is such a big deal, it is not
such a *peril*.
--
dorayme
tlvp
May 17, 2012, 8:28:17 PM5/17/12
to
On Fri, 18 May 2012 08:53:08 +1000, dorayme wrote:
> tlvp <mPiOsUcB...@att.net> wrote:
>>
>> Ah, for IMG elements I've learned: specify only one of height= or width=
>> values at your own peril
>
rate, not the last one) I had a little image file, perhaps 80px x 50px,
that I wanted to have displayed at half-size, as 40px x 25px. Being lazy,
and hoping all browsers would be designed so as to preserve aspect ratios,
I used only one of the dimensional attribute=value pairs, width=40 or
height=25, with the img tag evoking that image file. One of the browsers at
my disposal for testing decided any unspecified dimension attribute should
be assigned the value inherent in the image file itself, not the value that
would preserve the aspect ratio. So I was getting that image shown as 80 x
25, or as 40 x 50, except when I explicitly demanded *both* width=40 *and*
height=25.
No, I don't remember which browser that was. Perhaps an early Opera. Or a
pre-7.0 Netscape Nav'r. But I learned my lesson, and ever after I
resolutely specify both dimensions. For, after all, who knows how many
intrepid internauts opening pages I've created are not still be using that
verschluggene ancient browser that cared not a fig for aspect ratios :-) !
> Some used to think it a good idea to specify both to save time and
> jerkiness, the browser able to prepare fully for the space without
> having to fetch bits of info and calculate. These days, with faster
> internet and processors, not sure it is such a big deal, it is not
> such a *peril*.
Actually, specifying the space an image will require is still a good idea
for a text-heavy page with many images, particularly if they are hosted on
separate disparate CDN servers -- many's the image-heavy page I've
encountered whose text keeps jumping out of the open viewport, as images
whose space was not pre-reserved rightfully claim the full allotment of
space they require. Annoying as all get-out to be chasing after that text
just so as to be able to read it :-) .
> tlvp <mPiOsUcB...@att.net> wrote:
>>
>> Ah, for IMG elements I've learned: specify only one of height= or width=
>> values at your own peril
>
> About the point you say you have learnt. Not sure it applies so much
> to modern browsers. I don't know or have forgotten if there are any
> browsers that do not take the natural aspect ratio of pictures like
> gifs, pngs, jpgs and calculate the other dimension from the one
> supplied.
Once upon a time not all that very long ago (this century still, at any
> to modern browsers. I don't know or have forgotten if there are any
> browsers that do not take the natural aspect ratio of pictures like
> gifs, pngs, jpgs and calculate the other dimension from the one
> supplied.
rate, not the last one) I had a little image file, perhaps 80px x 50px,
that I wanted to have displayed at half-size, as 40px x 25px. Being lazy,
and hoping all browsers would be designed so as to preserve aspect ratios,
I used only one of the dimensional attribute=value pairs, width=40 or
height=25, with the img tag evoking that image file. One of the browsers at
my disposal for testing decided any unspecified dimension attribute should
be assigned the value inherent in the image file itself, not the value that
would preserve the aspect ratio. So I was getting that image shown as 80 x
25, or as 40 x 50, except when I explicitly demanded *both* width=40 *and*
height=25.
No, I don't remember which browser that was. Perhaps an early Opera. Or a
pre-7.0 Netscape Nav'r. But I learned my lesson, and ever after I
resolutely specify both dimensions. For, after all, who knows how many
intrepid internauts opening pages I've created are not still be using that
verschluggene ancient browser that cared not a fig for aspect ratios :-) !
> Some used to think it a good idea to specify both to save time and
> jerkiness, the browser able to prepare fully for the space without
> having to fetch bits of info and calculate. These days, with faster
> internet and processors, not sure it is such a big deal, it is not
> such a *peril*.
for a text-heavy page with many images, particularly if they are hosted on
separate disparate CDN servers -- many's the image-heavy page I've
encountered whose text keeps jumping out of the open viewport, as images
whose space was not pre-reserved rightfully claim the full allotment of
space they require. Annoying as all get-out to be chasing after that text
just so as to be able to read it :-) .
0 new messages