Two-line Buttons

[Art Shapiro]

Folks, I think this is a Javascript issue but if not, please let me know
where I should be investigating.

I have two questions regarding a button I coded for a recreational site.
Take a look at the home page of www.ocrebels.com - the button in
question is in the left, grey column; it's a dark blue button with white
lettering reading "Irvine Weather". (Irvine is the community name.)

I had a lot of trouble creating a two line button, and was pleased to
stumble on the simple solution of embedding a CR and LF character in the
value string. Here's the code that creates that button, not quite as
neat as in the actual code due to Usenet line length standards:

<form>
<INPUT TYPE=button value="Irvine&#13;&#10;Weather"
style="background-color:darkblue; color:white;
border-style:doubledotted;
border-color:Navy; border-width:3px;
font-style:normal;
font-variant:normal;
font-weight:bold;
font-size:14px;
font-family:Arial;
width:160px;
text-align:center"

onmouseover="this.style.backgroundColor='gold';
this.style.color='red';
this.style.fontSize='16px' "

onmouseout="this.style.backgroundColor='darkblue';
this.style.color='white';
this.style.fontSize='14px' "

onClick="window.location.href='http://forecast.weather.gov/MapClick.php?lat=33.67592566096207&lon=-117.78336811170448&site=sgx&smap=1&unit=0&lg=en&FcstType=text';return
false" >

</form>

I have two minor issues, hardly show-stoppers but curious enough to me
to post this.

First, the two lines of the button are nicely centered in Chrome and
Firefox, but are left-justified in IE. Is there an obvious reason for
the difference? I'd certainly prefer the centered presentation.

Second, I tried to change the text on mouse-over. I found that if it
were a single line of text, I could set this.value='blah blah blah' in
the onmouseover clause, and everything worked fine. But if I tried the
same trick of embedding the hex 13 and hex 10 in the this.value string,
for example this.value='blah&#13;&#10;blah', it simply flat-out didn't
work - the text didn't change upon hovering the mouse.

Is there some javascript syntactic subtlety at work here, or have I
stumbled on something more sinister?

Advice eagerly welcome with thanks.

Art

[Richard Cornford]

Art Shapiro wrote:
> Folks, I think this is a Javascript issue but if not, please
> let me know where I should be investigating.

By the look of it you are dealing with the interactions of all of the
basic web development technologies; HTML, CSS and javascript. You should
only expect to get details on the javascript issues here.

> I have two questions regarding a button I coded for a
> recreational site.

I also have a question about that. My question is why?

> Take a look at the home page of www.ocrebels.com - the button
> in question is in the left, grey column; it's a dark blue
> button with white lettering reading "Irvine Weather". (Irvine
> is the community name.)
>
> I had a lot of trouble creating a two line button, and was
> pleased to stumble on the simple solution of embedding a
> CR and LF character in the value string.

I am quite surprised that that worked at all with an <input
type="button"> element. I would be more surprised if it proved reliable
across any wide range of browsers.

> Here's the code that creates that button, not quite as neat as in the
> actual code due to Usenet line length standards:

Readable is sufficient.

> <form>

A form? Often code that posted to the group isn't representative of the
actual code used but in your case this is complete representative of the
mark-up used; the form element is redundant here, except possibly as a
vehicle for CSS styling, in which case it could be any number of other
types of elements.

> <INPUT TYPE=button value="Irvine&#13;&#10;Weather"
> style="background-color:darkblue; color:white;
> border-style:doubledotted;
> border-color:Navy; border-width:3px;
> font-style:normal;
> font-variant:normal;
> font-weight:bold;
> font-size:14px;
> font-family:Arial;
> width:160px;
> text-align:center"
>
> onmouseover="this.style.backgroundColor='gold';
> this.style.color='red';
> this.style.fontSize='16px' "
>
> onmouseout="this.style.backgroundColor='darkblue';
> this.style.color='white';
> this.style.fontSize='14px' "
>
> onClick="window.location.href='http://forecast.weather.gov/

> MapClick.php?lat=33.67592566096207&lon=117.78336811170448
> &site=sgx&smap=1&unit=0&lg=en&FcstType=text';return false" >

The 'text across two lines' requirement could probably be more
consistently achieved with a <button type="button"> element, where you
can put (pretty much) arbitrary (and arbitrarily styled) mark-up inside
the element and so have two lines of text, and reliably centred with
CSS.

However, as you have an onclick hander for your button that pretty much
does nothing else but navigate the page to a new URL, it would seem more
semantically appropriate to use a link here (<a href="...">), and style
it to be a box with the required borders (i.e. to look exactly like your
button does now), which should also facilitate better control over the
layout of the text within the link. This is the reason for my "why"
question, as it would seem to me that when using _hypertext_ mark-up
language a link should be the natural go-to first choice element for
page navigation.

> </form>
>
> I have two minor issues, hardly show-stoppers but curious enough
> to me to post this.
>
> First, the two lines of the button are nicely centered in Chrome
> and Firefox, but are left-justified in IE.

I think you are skating on thin ice trying to have two lines of text
inside an <input type="button> element, so it isn't surprising to me
that you don't have good control over the text alignment of those lines
of text.

> Is there an obvious reason for the difference? I'd certainly
> prefer the centered presentation.

Switching to a more appropriate element will probably give you more
control over that presentation.

> Second, I tried to change the text on mouse-over. I found that
> if it were a single line of text, I could set
> this.value='blah blah blah' in the onmouseover clause, and
> everything worked fine. But if I tried the same trick of
> embedding the hex 13 and hex 10 in the this.value string, for example
> this.value='blah&#13;&#10;blah', it simply
> flat-out didn't work - the text didn't change upon hovering
> the mouse.

When I first looked that that I thought, well that isn't going to have
the expected effect but it should not flat out fail. However, it then
occurred to me that this code was actually within the attribute value
for the event handler. That means it will be subject to the HTML
parser's interpretation before it gets exposed to the javascript engine.
So it looks like the HTML parse is substituting the carriage return and
line feed characters for the entities &#13;&#10; before the javascript
engine gets to first see the code
(which is what should be expected). And as javascript strings are
forbidden from containing any line termination characters the code the
javascript engine is receiving is syntactically incorrect and so will
not be complied into anything executable (as 'flat-out' a failure as
javascript knows).

Almost all desktop web browsers have some mechanism for reporting errors
in javascript, and those mechanisms will report syntax errors (along
with runtime errors). You should become familiar with those error
reporting mechanisms and use them when doing any work with javascript;
they proved useful clues as to what you are doing wrong when things
don't work (as expected, or at all). At least they do with some
experience of how to interpret what they report, but you don't start
getting that experience until you start using them. The error reported
in this case would have been something along the lines of "syntax error:
unterminated string literal", and that really should narrow the
possibilities down when it come to knowing where to look for the
problem.

Obviously if you cannot put line termination characters literally inside
a javascript sting then there has to be a mechanism to put them in there
in some other way when you want to be able to use them. That mechanism
is 'escape sequences', which are a sequence of characters commencing
with a backslash. There are set of sequences for 'special' characters,
where carriage return is \r (backslash and 'r') and line feed is \n
(backslash and 'n'). There are also hexadecimal escape sequences in
which the backslash is followed by an 'x' and then two hexadecimal
digits that represent a (8 bit) character code, so carriage return is
\x0D and line feed is \x0A. Then there are Unicode escape sequences;
backslash, 'u' and four hexadecimal digits (for 16 bit characters) (so
carriage return is \o000D and line feed is \u000A). Employing these
sequences when defining the string in your javascript would have avoided
the syntax error (but note, this is only applicable to javascript source
code (), not HTML VALUE attribute values).

However, if you switched the element type to either <button> or <a> then
you would find yourself using a string of HTML, assigning to the
element's - innerHTML - property and probably using <br> as the line
terminator, so issues with line termination characters should not arise.

> Is there some javascript syntactic subtlety at work here, or
> have I stumbled on something more sinister?

It is neither subtle nor sinister, just the unfortunately
non-transparent outcome of the interaction of two stages of source code
processing (HTML parsing followed by javascript
tokenising/parsing/compiling).

> Advice eagerly welcome with thanks.

Richard.

[Swifty]

On Sun, 29 Apr 2012 03:17:27 +0100, "Richard Cornford"
<Ric...@litotes.demon.co.uk> wrote:

>Almost all desktop web browsers have some mechanism for reporting errors
>in javascript, and those mechanisms will report syntax errors (along
>with runtime errors). You should become familiar with those error
>reporting mechanisms and use them when doing any work with javascript;
>they proved useful clues as to what you are doing wrong when things
>don't work (as expected, or at all).

The OP would find themselves in the perplexing situation that their
code worked when it generated error messages, but not when the code
was changed to eliminate the messages. I've had this happen to me on
several occasions and it can be very frustrating. Especially when
(like me) you are not entirely sure what you are doing.

I've even had a hardware version of this conundrum. On a very early IT
system (c. 1970) a rubber "O" seal fell off a removable disk, and
lodged in the drive's SEEK servo. When the drive was first used, the
rubber ring caused friction and I/O errors (the SEEK timed out).
However, if you drove the disk hard enough, the rubber heated up, and
became less sticky. Smoke would come out of the drive, but you got no
I/O errors when it was smoking. :-)

Before we found the fix, I wrote a program to bypass the problem. It
did maximum possible seeks for a minute or so, which would get the
drive smoking nicely. I called the program "smoker" and was always
amused to hear the operators calling for "smoker" to be run.

"Smoker" helped the engineer to fix the problem. We demonstrated the
problem, then my "fix", and whilst the drive was still smoking, he
removed the covers, and the origin of the smoke was obvious.

Debugging in a bygone era...

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[Evertjan.]

Art Shapiro wrote on 29 apr 2012 in comp.lang.javascript:

> <form>
> <INPUT TYPE=button value="Irvine&#13;&#10;Weather"
> style="background-color:darkblue; color:white;
> border-style:doubledotted;
> border-color:Navy; border-width:3px;
> font-style:normal;
> font-variant:normal;
> font-weight:bold;
> font-size:14px;
> font-family:Arial;
> width:160px;
> text-align:center"
>
> onmouseover="this.style.backgroundColor='gold';
> this.style.color='red';
> this.style.fontSize='16px' "
>
> onmouseout="this.style.backgroundColor='darkblue';
> this.style.color='white';
> this.style.fontSize='14px' "
>
> onClick="window.location.href='http://forecast.weather.gov/MapClick.php
> ?lat=33.67592566096207&lon=-117.78336811170448&site=sgx&smap=1&unit=0&l
> g=en&FcstType=text';return false" >
>
> </form>

Try a <button> element:

=======================================
<style type='text/css'>
button.myButton {
background-color:darkblue;
color:white;
border-color:navy;

border-width:3px;
font-style:normal;
font-variant:normal;
font-weight:bold;
font-size:14px;
font-family:Arial;
width:160px;

height:50px;
text-align:center;
}
button.myHover {
background-color:gold;
color:red;
font-size:16px;
}
</style>

<button
class='myButton'
onclick="window.location.href='http://cnn.com';"
onmouseover='this.className="myButton myHover"'
onmouseout ='this.className="myButton"'
>
Irvine
<br>
Weather
</button>
=======================================

The whole onmouse... & myHover exercise is only necessary for IE,
as with more normal major browsers, this would be fine:

button:hover {
background-color:gold;
color:red;
}


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Art Shapiro]

Thanks for the great input, everyone. I will thoroughly ponder what you
have related and see what comes of it.

Art