By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,743 Members | 1,058 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,743 IT Pros & Developers. It's quick & easy.

framed ∞

P: n/a
Share this Question
Share on Google+
12 Replies


P: n/a

"Xah Lee" <xa*@xahlee.org> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Frameset Infinity!
http://xahlee.org/js/frame2/frameset.html

HTML Frame tutorial + Infinity!
http://xahlee.org/js/frame/0.html

Why oh Why????
Feb 14 '06 #2

P: n/a
Just created Tab Menu tutorial.

Two tutorials for Tab Menu.

JavaScript implementation:
http://xahlee.org/js/tabs/a.html

Pure CSS implementation:
http://xahlee.org/js/tabs2/a.html

Xah
xa*@xahlee.org
http://xahlee.org/

Feb 19 '06 #3

P: n/a
In article <11*********************@g47g2000cwa.googlegroups. com>,
Xah Lee <xa*@xahlee.org> wrote:
Just created Tab Menu tutorial.

Two tutorials for Tab Menu.

JavaScript implementation:
http://xahlee.org/js/tabs/a.html
I avoid javascript whenever possible. Tabs are much simpler in CSS.
Pure CSS implementation:
http://xahlee.org/js/tabs2/a.html


This is an example of how NOT to do it, in my opinion.

You don't need to express tabs as a list. This is especially
important for tabs, which you may want to look like a horizontal
list of links for non-css browsers, rather than a vertical list of
links.

All you need is a border and color definition for the 'A' tag. Then
your tabs are as simple as a series of links:

<div id="nav">
<a name="#" id="current">current active tab</a>
<a href="page1.html">page 1 tab</a>
<a href="page2.html">page 2 tab</a>
</div>

See? No <ul...> list required.

The following CSS definitions for the HTML above will result in a nice
series of tabs, with the current tab having no bottom border to look
continuous with the page:

#nav { /* navigation bar which will have the tabs */
font-size: 1em;
text-decoration: none;
clear: both;
padding-top: 1px;
padding-left: 4px;
border-bottom: 1px solid #000000;
white-space: nowrap;
}
#nav a, #nav a:hover, #nav a#current { /* basic tab properties */
font-size: 1em;
text-decoration: none;
border-top: 1px solid black;
border-left: 1px solid black;
border-right: 1px solid black;
padding-left: .2em; padding-right: .2em;
padding-bottom: 0px;
}
#nav a { /* normal color of tab is CCCCCC */
border-bottom: 1px solid black;
color: #000000;
background-color: #CCCCCC;
}
#nav a:hover {
border-bottom: 1px solid black;
color: #000000;
background-color: #CCFFFF;
}
#nav a#current { /* color of "current" tab is white with green text */
border-bottom: 1px solid white;
color: #009933;
background-color: white;
}

-A
Feb 19 '06 #4

P: n/a
axlq wrote:
In article <11*********************@g47g2000cwa.googlegroups. com>,
Xah Lee <xa*@xahlee.org> wrote:
http://xahlee.org/js/tabs2/a.html
You don't need to express tabs as a list. This is especially
important for tabs, which you may want to look like a horizontal
list of links for non-css browsers, rather than a vertical list of
links.


When CSS isn't applied, a vertical list is a much better fallback than a
horizontal list, from both usability and accessibility standpoints.
<div id="nav">
<a name="#" id="current">current active tab</a>
<a href="page1.html">page 1 tab</a>
<a href="page2.html">page 2 tab</a>
</div>

See? No <ul...> list required.
And how do you think a screen reader will interpret this, as opposed to
list markup? How about Lynx? You've created a serious readability
problem, if nothing else.
The following CSS definitions for the HTML above will result in a nice
series of tabs,


....but only for graphical desktop browsers. You've completely ignored
any other browsing environment. :(

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Feb 19 '06 #5

P: n/a
axlq wrote:
You don't need to express tabs as a list. This is especially
important for tabs, which you may want to look like a horizontal
list of links for non-css browsers, rather than a vertical list of links.


Yes, this is sometimes true.

But bear in mind that in most cases the navigation of a page is
semantically and structurally a list. Semantic markup is
generally a good idea.

http://www.alistapart.com/stories/taminglists/
has details.

(BTW, why are you guys posting to 4 newsgroups?
Any really good reason?)


Feb 19 '06 #6

P: n/a
On Sun, 19 Feb 2006, mbstevens wrote:
(BTW, why are you guys posting to 4 newsgroups?
It's the standard modus operandi for xah lee.
Any really good reason?)


Many commentators seem to think that xah lee is a troll. Check
newsgroup archives for plenty of examples.

[f'ups set, just in case]
Feb 19 '06 #7

P: n/a
In article <45************@individual.net>, kchayka <us****@c-net.us> wrote:
axlq wrote:
See? No <ul...> list required.


And how do you think a screen reader will interpret this, as opposed to
list markup? How about Lynx? You've created a serious readability
problem, if nothing else.


I always TEST things on Lynx. The example will look like a horizontal
list of links, exactly as I intend. It's a horizontal list of links on
ALL browsers. The only difference is that on CSS browsers, pretty
little borders appear around the links.
The following CSS definitions for the HTML above will result in a nice
series of tabs,


...but only for graphical desktop browsers. You've completely ignored
any other browsing environment. :(


Wrong. What I proposed was INTENDED for other environments.

-A
Feb 20 '06 #8

P: n/a
axlq wrote:
[again nothing that is on-topic in cljs]


The relevance this discussion once had to J(ava)Script/ECMAScript
programming, it does not have it anymore. Please stop crossposting
to comp.lang.javascript, unless you are going to introduce that
relevance again, and set Followup-To where it is appropriate.

Thanks in advance.
PointedEars
Feb 20 '06 #9

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:
axlq wrote:
[again nothing that is on-topic in cljs]


The relevance this discussion once had to J(ava)Script/ECMAScript
programming, it does not have it anymore. Please stop crossposting
to comp.lang.javascript


Please stop replying to posts with just header tweaking to keep your
precious cljs group clean. It doesn't work, as I explained to you before.

A crosspost without a follow up can not be "fixed" afterwards. Trying to
change things only add to the noise.

--
John Skilled Perl programmer for hire: http://castleamber.com/

Fox noGO:http://johnbokma.com/firefox/removin...earch-bar.html
Feb 20 '06 #10

P: n/a
axlq wrote:
In article <45************@individual.net>, kchayka <us****@c-net.us> wrote:
axlq wrote:
See? No <ul...> list required.
You've created a serious readability problem, if nothing else.


It's a horizontal list of links on ALL browsers.


Hmmm... seems you've ignored the readability part.
The only difference is that on CSS browsers, pretty
little borders appear around the links.
You are quite mistaken. A horizontal list of links like you suggested is
just a bunch of words that all run together. It is a PITA to parse with
your eyes, or with a screen reader.

You have both an accessibility and a usability problem here. A vertical
list with proper list markup makes everything better, *especially* in
non-CSS situations. Too bad you don't see this. :(
What I proposed was INTENDED for other environments.


But you haven't really thought it through, have you?

HAND

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Feb 20 '06 #11

P: n/a
Events: A Introduction to the Model of GUI programing
http://xahlee.org/js/events.html

Comments welcome. Thanks.

Xah
xa*@xahlee.org
http://xahlee.org/

Mar 4 '06 #12

P: n/a
Xah Lee wrote:
Events: A Introduction to the Model of GUI programing
http://xahlee.org/js/events.html

Comments welcome. Thanks.


The main benefit of writing explanatory material is that authors gain a
better understanding of what they are writing about. I've written
similar stuff but keep it to myself since releasing it to the public
would probably do more harm than good... :-)

Some comments on your article:
*Superficial*
You don't go into very much depth at all, leaving your readers to learn
just about everything from your MSDN references - as a result, they will
likely write IE-centric code and wonder why it doesn't work in other
browsers.
*Different event models*
You don't mention that there are two different event models, a pretty
fundamental concept for using events in browsers.
*References*
You have many reference to Microsoft resources, but none to the W3C.
Given that W3C is more important as a standards setting body, they
should be your primary reference.

MSDN should only be referenced where a suitable W3C reference doesn't
exist. Wherever an MSDN reference is used, an equivalent reference for
other platforms should be included - say Gecko and Opera at least (where
available).

There are some good articles about events, you should also reference
those, e.g. Quirksmode:

<URL: http://www.quirksmode.org/js/introevents.html >

and check your article for consistency with them.
*Attaching events*
You note two methods for attaching events, but there are others such as
addEventListener and attachEvent - but that would require you to explain
that there are two different event models.

*Event properties*
No mention is made of event properties, or even of event objects.
--
Rob
Mar 7 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.