Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #13681 > unrolled thread

Two-line Buttons

Back to article view | Back to comp.lang.javascript

Contents

  Two-line Buttons Art Shapiro <arthur-temp-3@cox.net> - 2012-04-28 17:06 -0700
    Re: Two-line Buttons "Richard Cornford" <Richard@litotes.demon.co.uk> - 2012-04-29 03:17 +0100
      Re: Two-line Buttons Swifty <steve.j.swift@gmail.com> - 2012-04-29 08:06 +0100
    Re: Two-line Buttons "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-04-29 07:15 +0000
    Re: Two-line Buttons Art Shapiro <arthur-temp-3@cox.net> - 2012-04-29 07:04 -0700

#13681 — Two-line Buttons

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

[toc] | [next] | [standalone]

#13682

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. 

[toc] | [prev] | [next] | [standalone]

#13685

On Sun, 29 Apr 2012 03:17:27 +0100, "Richard Cornford"
<Richard@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

[toc] | [prev] | [next] | [standalone]

#13686

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)

[toc] | [prev] | [next] | [standalone]

#13689

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

Art

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web