2012-03-21 00:48:31 -04:00
|
|
|
/** stylesheet for lasertank-js **/
|
|
|
|
|
|
|
|
|
|
body {
|
|
|
|
|
background-image: url('images/dirt.gif');
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
font-size: 14px;
|
2012-03-21 00:48:31 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.game {
|
|
|
|
|
position: relative;
|
|
|
|
|
|
2012-03-21 23:21:49 -04:00
|
|
|
background-color: #c0c0c0;
|
2012-03-21 21:26:30 -04:00
|
|
|
border: 2px outset;
|
|
|
|
|
|
2012-03-21 00:48:31 -04:00
|
|
|
margin: 0px auto;
|
|
|
|
|
width: 696px;
|
|
|
|
|
}
|
|
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
/** menu **/
|
|
|
|
|
.game ul.menu,
|
|
|
|
|
.game ul.menu ul {
|
2012-03-21 21:51:47 -04:00
|
|
|
list-style: none;
|
|
|
|
|
|
|
|
|
|
margin: 0;
|
|
|
|
|
padding: 0;
|
|
|
|
|
|
|
|
|
|
cursor: default;
|
|
|
|
|
}
|
|
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.game ul.menu > li {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
padding: 0px;
|
|
|
|
|
margin: 1px;
|
|
|
|
|
}
|
|
|
|
|
.game ul.menu > li:hover {
|
|
|
|
|
margin: 0px;
|
|
|
|
|
border: 1px outset #d3d7cf;
|
|
|
|
|
}
|
2012-03-21 21:51:47 -04:00
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.game ul.menu > li ul {
|
|
|
|
|
position: absolute;
|
|
|
|
|
display: none;
|
|
|
|
|
|
|
|
|
|
background-color: #c0c0c0;
|
|
|
|
|
|
|
|
|
|
margin: -1px 0px 0px -1px;
|
|
|
|
|
min-width: 7em;
|
2012-03-21 21:51:47 -04:00
|
|
|
}
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.game ul.menu > li li {
|
|
|
|
|
padding: 0.2em 0.5em 0.2em 1em;
|
|
|
|
|
border: 1px outset #d3d7cf;
|
2012-03-21 21:51:47 -04:00
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
color: gray;
|
2012-03-21 21:51:47 -04:00
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
white-space: no-wrap;
|
|
|
|
|
}
|
|
|
|
|
.game ul.menu > li a {
|
|
|
|
|
position: relative;
|
|
|
|
|
background-color: #c0c0c0;
|
|
|
|
|
|
|
|
|
|
cursor: default;
|
|
|
|
|
color: black;
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
|
|
|
|
|
padding: 0px 0.4em;
|
|
|
|
|
margin: 0px;
|
|
|
|
|
|
|
|
|
|
line-height: 1.4em;
|
|
|
|
|
}
|
|
|
|
|
.game ul.menu > li li > a {
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
}
|
|
|
|
|
.game ul.menu > li li:hover {
|
|
|
|
|
background-color: #729fcf;
|
|
|
|
|
}
|
|
|
|
|
.game ul.menu.focus > li:hover ul {
|
|
|
|
|
display: block;
|
|
|
|
|
margin-top: -3px;
|
|
|
|
|
z-index: 1000;
|
2012-03-21 21:51:47 -04:00
|
|
|
}
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.game ul.menu.focus > li:hover > a {
|
|
|
|
|
z-index: 1001;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-21 21:51:47 -04:00
|
|
|
|
2012-03-21 22:44:44 -04:00
|
|
|
.game img.opening {
|
|
|
|
|
display: none;
|
|
|
|
|
|
|
|
|
|
width: 512px;
|
|
|
|
|
height: 512px;
|
|
|
|
|
}
|
|
|
|
|
.game.opening img.opening {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-21 00:48:31 -04:00
|
|
|
/* 16x16 board */
|
|
|
|
|
.game canvas {
|
|
|
|
|
width: 512px;
|
|
|
|
|
height: 512px;
|
|
|
|
|
border: 2px inset gray;
|
|
|
|
|
}
|
2012-03-21 22:44:44 -04:00
|
|
|
.game.opening canvas {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
2012-03-21 00:48:31 -04:00
|
|
|
|
|
|
|
|
.game .hud {
|
|
|
|
|
position: absolute;
|
|
|
|
|
|
|
|
|
|
background-image: url('images/hud.bmp');
|
|
|
|
|
background-repeat: no-repeat;
|
|
|
|
|
|
|
|
|
|
width: 180px;
|
|
|
|
|
height: 245px;
|
|
|
|
|
right: 0px;
|
|
|
|
|
top: 0px;
|
|
|
|
|
}
|
2012-03-21 23:22:53 -04:00
|
|
|
|
|
|
|
|
/** control buttons (cloned to the pixel for margins/padding) **/
|
|
|
|
|
.game .control {
|
|
|
|
|
position: absolute;
|
|
|
|
|
|
|
|
|
|
/* intentionally 10px on left and 15px on right to stay consistent with
|
|
|
|
|
* original game */
|
|
|
|
|
border: 1px inset #d3d7cf;
|
|
|
|
|
width: 145px;
|
|
|
|
|
top: 249px;
|
|
|
|
|
right: 15px;
|
|
|
|
|
|
|
|
|
|
/* bottom handled by button margin */
|
|
|
|
|
padding: 4px 5px 0px 5px;
|
|
|
|
|
margin: 0px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.game .control button {
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
margin-bottom: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.game .control .gapl {
|
|
|
|
|
margin-right: 5px;
|
|
|
|
|
width: 70px;
|
|
|
|
|
|
|
|
|
|
float: left;
|
|
|
|
|
clear: left;
|
|
|
|
|
}
|
|
|
|
|
.game .control .gapr {
|
|
|
|
|
width: 70px;
|
|
|
|
|
float: left;
|
|
|
|
|
}
|
|
|
|
|
.game .control .full {
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/** dialogs **/
|
|
|
|
|
.dialog {
|
|
|
|
|
position: absolute;
|
|
|
|
|
display: none;
|
|
|
|
|
|
|
|
|
|
background-color: rgba( 0, 0, 0, 0.5 );
|
|
|
|
|
|
|
|
|
|
top: 0px;
|
|
|
|
|
left: 0px;
|
|
|
|
|
right: 0px;
|
|
|
|
|
bottom: 0px;
|
|
|
|
|
|
|
|
|
|
/* by setting the z-index > the menu z-index, it will automatically lose focus
|
|
|
|
|
* and be hidden */
|
|
|
|
|
z-index: 2000;
|
|
|
|
|
}
|
2012-03-24 19:39:11 -04:00
|
|
|
.dialog.show {
|
|
|
|
|
display: block;
|
|
|
|
|
}
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.dialog > .body {
|
|
|
|
|
position: absolute;
|
|
|
|
|
|
|
|
|
|
background-color: #c0c0c0;
|
|
|
|
|
border: 2px outset #d3d7cf;
|
|
|
|
|
|
|
|
|
|
min-width: 150px;
|
|
|
|
|
width: 150px;
|
|
|
|
|
margin: 0px auto;
|
|
|
|
|
padding: 0.5em;
|
|
|
|
|
top: 250px;
|
|
|
|
|
left: 0px;
|
|
|
|
|
right: 0px;
|
|
|
|
|
|
|
|
|
|
z-index: 2001;
|
|
|
|
|
}
|
2012-03-24 21:03:07 -04:00
|
|
|
.dialog > .body > .title {
|
|
|
|
|
background-color: #000080;
|
|
|
|
|
background-image: -webkit-linear-gradient( left, #000080, #1084d0 );
|
|
|
|
|
background-image: -moz-linear-gradient( left, #000080, #1084d0 );
|
|
|
|
|
background-image: -ms-linear-gradient( left, #000080, #1084d0 );
|
|
|
|
|
background-image: -o-linear-gradient( left, #000080, #1084d0 );
|
|
|
|
|
margin: -0.5em -0.5em 0.5em -0.5em;
|
|
|
|
|
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
color: white;
|
|
|
|
|
|
|
|
|
|
padding: 0.4em;
|
|
|
|
|
}
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
.dialog .close {
|
|
|
|
|
float: right;
|
2012-03-24 19:39:34 -04:00
|
|
|
margin-top: 0.5em;
|
|
|
|
|
}
|
|
|
|
|
.dialog > .body > p:first-of-type {
|
|
|
|
|
margin-top: 0;
|
|
|
|
|
}
|
|
|
|
|
.dialog > .body > p:last-of-type {
|
|
|
|
|
margin-bottom: 0;
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
}
|
|
|
|
|
|
2012-03-24 19:39:11 -04:00
|
|
|
#noscript .body {
|
|
|
|
|
width: 500px;
|
|
|
|
|
}
|
|
|
|
|
|
Initial menu concept
One of the only remaining portions of the UI at this point (disregarding missing
functionality) was the menu bar. At this point, I had to make a number of
choices, among them:
- Do I mimic the original Windows UI, or provide a more native experience?
- Do I support pre-{CSS3,ES5,HTML5} environments, or take advantage of each?
The menu bar in this commit has the boxy style of the classic Windows theme --
not because I like it, but because it is representative of the original game,
which was available only for that operating system. The same style is applied to
the color of the "window" div in which the game is contained, as well as any
dialogs. However, the buttons displayed on the screen are in the style native to
the user's environment. With Gecko and Webkit offering the ability to style
elements (including menu bars, etc) in a way that looks native[1], the question
naturally arises -- do we provide more of a native port look, or a true clone
look? Should the latter be the case, it may be more appropriate to style the
buttons as boxes.
The next decision was whether or not to support environments that do not provide
many of the common CSS3, ES5 and HTML5 features. Initially, the project wished
to use CSS sprites in order to support older browsers, however with the move to
the canvas element, it seems unnecessary to provide such compatibility. Consider
also the push by organizations like Mozilla and Google to automatically upgrade
users' browsers, helping to ensure they have the newest available features. Also
consider that supporting older environments only discourages users to upgrade,
feeding the challenges that web developers already face in creating
cross-browser software. With all of that, the decision was made to simply use
the features provided by ECMAScript 5, CSS3 and HTML5, using browser extensions
where necessary (for unstandardized features, e.g. -prefix-foo in CSS).
It is rare that I get to work intimately with these newer features, as I find
myself most often having to maintain compatibility with older environments. This
will be an exciting chance to be able to explore these features and to showcase
them for others who wish to see them used in a complete piece of software. That
said, LaserTank is a fairly old game and, as such, is unlikely to take advantage
of features like CSS transitions (animations are handled by timers and rendered
to the canvas and there is not much else to transition), as that would take away
from the retro feel of the original game.
With the menu implementation, I attempted to limit myself to CSS as much as
possible in order to reduce the amount of code that had to be written for the
display of the menus and dialogs. The menus display using the :hover selector
and the dialogs with the new :target selector. JavaScript is used to to register
click events on the menu so that moving the mouse to another menu item will have
it automatically displayed, keeping each of the menus hidden until a click.
JavaScript is also used to determine when the menu should be hidden on mouseout.
The menu does not function exactly like the menu in Windows, but it will be
functional for now. I would like to worry about such issues after the bulk of
the game logic has been developed.
This commit's implementation is conceptual; it will be refactored shortly.
[1] https://developer.mozilla.org/en/CSS/-moz-appearance
2012-03-24 19:13:12 -04:00
|
|
|
#todo .body {
|
|
|
|
|
width: 350px;
|
|
|
|
|
}
|
|
|
|
|
#todo:target {
|
|
|
|
|
display: block;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
a.button {
|
|
|
|
|
-webkit-appearance: push-button;
|
|
|
|
|
-moz-appearance: button;
|
|
|
|
|
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
cursor: default;
|
|
|
|
|
|
|
|
|
|
padding: 0.2em 1em;
|
|
|
|
|
|
|
|
|
|
color: inherit;
|
|
|
|
|
}
|