JavaScript GUI库的想法 [英] JavaScript GUI library idea

问题描述

过去一周我一直在询问有关图书馆设计的问题，

希望获得有关我的总体想法的反馈一个JavaScript GUI

库。我需要一个漂亮的GUI库，所以我很有可能会因为我需要新的小部件来写这个。我没有找到这样的东西

而且我很惊讶/失望，这还不存在。我的图书馆

原型很好用。我认为这些想法的一部分通常不会用于JavaScript库开发，而是在我深入潜入之前

任何经验丰富的建议都可能使我的工作变得更好。 />

在尝试为Web应用程序后端开发丰富的GUI时，我开始需要一大堆表现和编码的GUI小部件的


类似。像弹出式菜单，下拉菜单栏，树状菜单，

可调节的桌子宽度，旋转器...所有Java中的东西

Swing或其他GUI小部件库。是的我知道所有这些东西

单独作为JavaScripts存在但我想建立一个库

使用类层次结构和继承来利用

所有优秀的OOP封装思想等。当然这个库

将不同于桌面应用程序GUI库，因为HTML，CSS和

浏览器已经提供了很多需要的东西（< ul>'用于菜单，

< table>用于表格，各种字体显示内容，某种形式

元件）。在JavaScript中，我们在

浏览器已经为我们提供的功能之上添加了功能。


这可能最终成为一个大型库，但如果每个类都在它是自己的

文件，并且类层次结构是已知的，然后人们可以将它们串在一起

只需要他们需要的部分。我想开发一种方法来自动化这一步
。从大型库中为您的页面编译需要编译一个JavaScript文件的东西。


对于JavaScript继承，我想使用这些想法
http：//www.kevlindev.com/tutorials/j ... t / inheritance /


我将为所有内容使用一个命名空间。我的图书馆不会干涉

与其他图书馆。


没有直接扩展功能或数组并打破像

Prototype这样的东西。 js呢。相反，我将根据需要对这些进行子类化，并在子类中扩展
。直接扩展函数或数组不会很好地满足我的命名空间要求。


没有像Prototype.js那样试图转动的单片支持脚本

JavaScript到Ruby或Python等等。只需JavaScript。


使用JavaScript和DOM插入的所有机器CSS（使项目工作的东西，例如：display：none

或display：block）进入标签'

样式元素，使它们具有特异性1,0,0,0。这样一来，如果没有在CSS

规则中使用！important，那么图书馆的用户无法覆盖。


机械分离CSS其余的JavaScript带有

的想法，即对DOM元素的样式属性的每次更改都是和/ b $ b&b效果。因此，所有效果都会很好地隐藏在单个

效果对象中。这一个对象将是唯一一个寻找

浏览器特定黑客的地方。黑客可以通过复合效果重复使用。


一个默认的CSS文件集，可以覆盖漂亮的东西

，库用户可以根据需要自己的样式表。这具有最低可能的特异性，因此这些规则很容易被覆盖。


两个库接口。一个高级界面，允许通过每个小部件的单行JavaScript访问

小部件选项。


< head>

< script type =" text / javascript" src =" seriousWidgets.js">< / script>

< / head>

< body>

< ul id =" myMenuBar">

< li> item 1< li>

< li> item 2< li>

< ul>

< script>

var my_menu_bar = new

Serious.MenuBar（document.getElementById（" myMenuBar" ），

{option1：value1，

option2：value2}）;

< / script>

< / body>

第二个界面，一个完全不突兀的外观，适合那些想要不惜一切代价避免使用JavaScript并且具有功能的小工具的人在

标准方式。外观仍然很容易被CSS覆盖。


< head>

< script type =" text / javascript" src =" easyWidgets.js">< / script>

< / head>

< body>

< ul class =" easyMenuBar">

< li> item 1< li>

< li> item 2< li>

< ul>

< / body>


任何有关的想法，想法，警告或警告。


谢谢，

彼得

解决方案

pe ********** @ gmail.com 写道：

我去过在上周询问有关图书馆设计的问题，
希望获得有关JavaScript GUI图书馆整体构思的反馈。我需要一个漂亮的GUI库，因此我很有可能在需要新的小部件时写这个。我还没有找到这样的东西
而且我很惊讶/失望，这还不存在。我的图书馆
原型很好用。我认为这些想法的一部分通常不会用于JavaScript库开发，而是在我深入了解之前
任何有经验的建议都可能使我的工作变得更好。


如果没有客户端脚本支持这是它的主要缺陷它不起作用。

在尝试为Web应用程序后端开发丰富的GUI时，我开始
需要大量的GUI小部件，其行为和编码类似。诸如弹出菜单，下拉菜单栏，树状菜单，可调节的桌子宽度，旋转器......以及Java中的所有东西Swing或其他GUI小部件库。


XUL和HTA存在。

是的我知道所有这些东西都是单独存在的JavaScripts但是我想构建一个使用的库一个类层次结构和继承，以利用封装的所有优秀OOP思想
等等。


除非要求.NET或SpiderMonkey 2.0，否则你可以忘记

课程。


< URL：http：//javascript.crockford.com/inheritance.html>

当然这个库与桌面应用程序GUI库不同
因为HTML，CSS和浏览器已经提供了很多需要的东西
（< ul>'用于菜单，< table> ;对于表格，各种字体显示内容，
某些表单元素）。


您误解了Web浏览器作为应用程序平台。

在JavaScript中，我们在浏览器已经为我们提供的功能之上添加了功能。


这就是为什么可以优雅降级的原因。
[...]
对于JavaScript继承我想用这些想法
http://www.kevlindev.com/tutorials/j...t / inheritance /

事实错误。

我将使用一个命名空间。


除非要求.NET或SpiderMonkey 2.0，否则你可以忘记

命名空间。

我的库不会干扰其他图书馆。


你不能确保。

[...]
所有机械CSS（使物品工作的东西，例如：display：none
或display：block）将JavaScript和DOM插入到标签的
样式元素中，使它们具有特异性1,0,0,0。通过这种方式，图书馆的用户无法在他们的CSS
规则中使用！important来覆盖。
[...]
< head>
< script类型= QUOT;文本/ JavaScript的" src =" seriousWidgets.js">< / script>
< / head>
< body>
< ul id =" myMenuBar">
< li>第1项< li>
< li>第2项< li>
< ul>
< script>
var my_menu_bar = new
Serious.MenuBar（document.getElementById（" myMenuBar"），
{option1：value1，
option2：value2}）;
< / script>
< /体>


这个功能不允许优雅降级，只需要当前IEeeks的b $ b，并希望不会用于其未来的版本。 CSS

可以在所有其他UA中完成工作，并允许优雅降级。

第二个界面，一个完全不突兀的外观，适合那些想要的人不惜一切代价避免使用JavaScript，并使用以标准方式运行的小部件。外观仍然很容易被CSS覆盖。


废话。两只鸟都可以用一块石头杀死。

任何想法，想法，警告或警告都赞赏。

[x]完成

PointedEars

PointedEars，


感谢您的回复。我对你提到的

事情进行了一些扩展感兴趣。

Thomas''PointedEars''Lahn写道：

Peter Michaux写道：
如果没有客户端脚本支持这是它的主要缺陷它是行不通的。


我要求用户在过去几年中发布了一个浏览器

并且已经打开了javascript。对于一个javascript

库来说这是不合理的吗？你认为你的所有剧本都是主要缺陷吗？

也许我错过了你的观点。

XUL和HTA存在。


这些看起来分别特定于Mozilla和IE。如果这是真的那么

并没有因为我想做的事而削减它。

< URL：http：//javascript.crockford.com/inheritance。 HTML>


感谢您的链接。

对于JavaScript继承，我想使用这些想法
http://www.kevlindev.com/tutorials/j...t / inheritance /

事实错误。

为什么它是真的错了？我对这种方法的合理批评非常感兴趣

这个方法。

除非要求.NET或SpiderMonkey 2.0，否则你可以忘记
名称空间。

我的意思是模拟名称空间，例如
http://blog.dreamprojections.com/arc...12/27/450.aspx

[...]
所有机制CSS（使项目工作的东西，例如：display：none
或display：block）用JavaScript和DOM插入标签'' s
样式元素使它们具有特异性1,0,0,0。通过这种方式，图书馆的用户无法在他们的CSS
规则中使用！important来覆盖。
[...]
< head>
< script类型= QUOT;文本/ JavaScript的" src =" seriousWidgets.js">< / script>
< / head>
< body>
< ul id =" myMenuBar">
< li>第1项< li>
< li>第2项< li>
< ul>
< script>
var my_menu_bar = new
Serious.MenuBar（document.getElementById（" myMenuBar"），
{option1：value1，
option2：value2}）;
< / script>
< / body>

此功能不允许优雅降级，仅适用于当前的IEeeks，并且希望不适用于其未来的版本。 CSS
可以在所有其他UA中完成工作，并允许优雅降级。

" IEeeks"？不知道那个。


为什么这段代码不允许优雅降级？

第二个界面，一个完全不突兀的外观，适合那些不惜一切代价避免使用JavaScript并且具有以标准方式运行的小部件的人。外观仍然很容易被CSS覆盖。

废话。两只鸟都可以用一块石头杀死。

这两个接口的原因是效率。如果用户不会使用

easyWidgets界面，那么通过html搜索带有className的标签就没有意义了，包括

easyMenuBar等等


谢谢，

彼得

pe ********** @ gmail.com 写道：

Thomas''PointedEars''Lahn写道：

Peter Michaux写道：
如果没有客户端脚本支持这是它的主要缺陷，它是行不通的。
我要求用户在过去几年中发布了一个浏览器
并且已经打开了javascript。对于一个javascript
库来说这是不合理的吗？你认为你的所有剧本都是严重缺陷吗？
也许我错过了你的观点。

要求最新的浏览器，并要求它有客户端脚本

支持启用是两个不同的东西。特别是IEeek（参见

以下）和RadioActiveX（我想你明白了）。我们之前真的讨论过

这个广告。搜索相关的档案，并搜索它们以进行UI库讨论。到目前为止，你不是第一个想到这一点的人，在这里尝试过，并且不可避免地失败了。阅读

可能会帮助你将时间投入到更有意义的事情上。

>对于JavaScript继承，我想使用这些想法
> http://www.kevlindev.com/tutorials/j...t / inheritance /

事实错误。

为什么事实上是错的？我对这种方法的合理批评非常感兴趣。

例如，语言中没有类和子类
$ b您定位的执行环境支持$ b。并且init（）

方法，可能是在没有最小线索的情况下复制的原型垃圾

代码，是无稽之谈。该语言已经有了构造函数。

除非需要.NET或SpiderMonkey 2.0，否则您可以忘记
名称空间。

我的意思是模拟名称空间，如
http://blog.dreamprojections.com/arc...12/27/450.aspx

我说，那些不是名称空间。使用用户定义的容器

对象用于其他用户定义的对象比宣布全局的所有内容更好，这是肯定的。但是不能保证

不会干扰其他未知的库。 ECMAScript 1-3实现的动态特性

不允许这样的限制。

> [...]
>所有机器CSS（使项目工作的东西，例如：display：none
>或display：block）用JavaScript和DOM插入标签'
>样式元素使它们具有特异性1,0,0,0。这样一个用户
>在没有使用！重要的情况下，库不能覆盖它们的CSS
>规则。
> [...]
> < head>
> < script type =" text / javascript" src =" seriousWidgets.js">< / script>
> < / head>
> < body>
> < ul id =" myMenuBar">
> < li>项目1< li>
> < li>第2项< li>
> < ul>
> < script>
> var my_menu_bar = new
> Serious.MenuBar（document.getElementById（" myMenuBar"），
> {option1：value1，
> option2：value2}）;
> < / script>
> < / body>

此功能不允许优雅降级，仅适用于当前的IEeeks，并且希望不适用于其未来的版本。 CSS
可以在所有其他UA中完成工作，并允许优雅降级。

IEeeks？不知道那个。

IEs。用户代理基于Microsoft Internet Explorer。它的布局引擎

是这个严重的borken和它的API是有缺陷的，有些人，包括我b / b，倾向于认为Eeek在谈论为它开发时。而且，因为IE7不会在Windows 2000及更早版本中发布，所以它可能会保持这种状态。

为什么呢？这段代码不允许优雅降级？

因为没有客户端脚本支持就没有菜单。

哪些可以轻松避免设计方法需要花费更多的时间来考虑开发。

>第二个界面，一个完全不突兀的外观，适合那些
>希望不惜一切代价避免使用JavaScript，并拥有在
>中运行的小部件。标准方式。外观仍然很容易被CSS覆盖。

废话。两只鸟都可以用一块石头杀死。

两个接口的原因是效率。如果用户不会使用easyWidgets界面，则没有必要通过html搜索带有className的标签，包括
easyMenuBar。等。

效率和维护考虑因素是为什么这应该是一个脚本版本完成的b / b
，如果是这样的话。一个版本仅在必要时才使用客户端

脚本。它之前已经完成了。


并且，重新考虑这一点，对于更新的IE版本显然它可以在没有客户端脚本的情况下完成
。这里发布的最新，最有价值的b $ b令人信服的例子我记得是


< URL：http：//www.cssplay.co.uk/ menus / dd_valid.html>

HTH


PointedEars

Hi,

I''ve been asking questions about library design over the last week and
would like to get feedback on my overall idea for a JavaScript GUI
library. I need a nice GUI library so there is a good chance I will
write this as I need new widgets. I haven''t found anything like this
and I''m surprised/disapointed this doesn''t already exist. My library
prototype works nicely. I think parts of these ideas are not commonly
used for JavaScript library development and before I dive in too deeply
any experienced advice might make my efforts a lot better.

While trying to develop a rich GUI for a web app backend I started
needing a large set of GUI widgets that behaved and were coded
similarly. Things like flyout menus, drop down menubars, tree menus,
adjustable table widths, spinners...all the things that are in Java
Swing or other GUI widget libraries. Yes I know all of these things
exist individually as JavaScripts but I would like to build a library
that uses a class hierarchy structure and inheritance to take advantage
of all the nice OOP ideas of encapsulation etc. Certainly this library
will be different than a desktop app GUI library since HTML, CSS and
the browser already provide a lot of what is needed (<ul>''s for menus,
<table> for tables, all sorts of font display stuff, some form
elements). In JavaScript we are adding functionality on top of what the
browser already gives us.

This could end up being a big library but if each class is in it''s own
file and the class hierarchy is known then people could string together
only the pieces they need. I would like a develop a way to automate
this step. Something like compiling one JavaScript file with all you
need for your page from the big library.

For JavaScript inheritance I want to use these ideas
http://www.kevlindev.com/tutorials/j...t/inheritance/

I will use one namespace for everything. My library will not interfere
with other libraries.

No direct extending of Function or Array and breaking stuff like
Prototype.js does. Instead I will subclass these as necessary and
extend in the subclass. Directly extending Function or Array would not
go well with my namespace requirement.

No monolithic support script like Prototype.js that tries to turn
JavaScript into Ruby or Python or whatever. Just JavaScript.

All machinery CSS (the stuff that makes the items work eg. display:none
or display:block) inserted with JavaScript and the DOM into the tag''s
style elements so that they have specificity 1,0,0,0. This way a user
of the library cannot override without using !important in their CSS
rules.

Separation of machinery CSS and the rest of the JavaScript with the
idea that every change to a DOM element''s style attribute is and
"effect". So all the effects will be tucked away nicely in a single
Effects object. This one object will be the only place to look for
browser specific hacks. Hacks can be reused by composite effects.

A default set of CSS files for the pretty stuff that can be overridden
as desired by the library user in their own style sheets. This has
lowest possible specificity so these rules are easily overridden.

Two library interfaces. One advanced interface that allows access to
widget options through a single line of JavaScript per widget.

<head>
<script type="text/javascript" src="seriousWidgets.js"></script>
</head>
<body>
<ul id="myMenuBar">
<li>item 1<li>
<li>item 2<li>
<ul>
<script>
var my_menu_bar = new
Serious.MenuBar(document.getElementById("myMenuBar "),
{option1:value1,
option2:value2});
</script>
</body>

A second interface, a completely non-obtrusive facade for those who
want to avoid JavaScript at all costs and have widgets that function in
standard ways. Appearance still easily overridden with CSS.

<head>
<script type="text/javascript" src="easyWidgets.js"></script>
</head>
<body>
<ul class="easyMenuBar">
<li>item 1<li>
<li>item 2<li>
<ul>
</body>

Any thoughts, ideas, cautions or warnings appreciated.

Thanks,
Peter

解决方案

pe**********@gmail.com wrote:

I''ve been asking questions about library design over the last week and
would like to get feedback on my overall idea for a JavaScript GUI
library. I need a nice GUI library so there is a good chance I will
write this as I need new widgets. I haven''t found anything like this
and I''m surprised/disapointed this doesn''t already exist. My library
prototype works nicely. I think parts of these ideas are not commonly
used for JavaScript library development and before I dive in too deeply
any experienced advice might make my efforts a lot better.
It does not work without client-side script support which is its major flaw.
While trying to develop a rich GUI for a web app backend I started
needing a large set of GUI widgets that behaved and were coded
similarly. Things like flyout menus, drop down menubars, tree menus,
adjustable table widths, spinners...all the things that are in Java
Swing or other GUI widget libraries.
XUL and HTA exist.
Yes I know all of these things exist individually as JavaScripts but I
would like to build a library that uses a class hierarchy structure and
inheritance to take advantage of all the nice OOP ideas of encapsulation
etc.
Unless .NET or SpiderMonkey 2.0 is a requirement, you can forget about
classes.

<URL:http://javascript.crockford.com/inheritance.html>
Certainly this library will be different than a desktop app GUI library
since HTML, CSS and the browser already provide a lot of what is needed
(<ul>''s for menus, <table> for tables, all sorts of font display stuff,
some form elements).
You are misunderstanding a Web browser as an application platform.
In JavaScript we are adding functionality on top of what the browser
already gives us.
Which is why graceful degradation is possible.
[...]
For JavaScript inheritance I want to use these ideas
http://www.kevlindev.com/tutorials/j...t/inheritance/
Factually wrong.
I will use one namespace for everything.
Unless .NET or SpiderMonkey 2.0 is a requirement, you can forget about
namespaces.
My library will not interfere with other libraries.
You cannot ensure that.
[...]
All machinery CSS (the stuff that makes the items work eg. display:none
or display:block) inserted with JavaScript and the DOM into the tag''s
style elements so that they have specificity 1,0,0,0. This way a user
of the library cannot override without using !important in their CSS
rules.
[...]
<head>
<script type="text/javascript" src="seriousWidgets.js"></script>
</head>
<body>
<ul id="myMenuBar">
<li>item 1<li>
<li>item 2<li>
<ul>
<script>
var my_menu_bar = new
Serious.MenuBar(document.getElementById("myMenuBar "),
{option1:value1,
option2:value2});
</script>
</body>
This feature, which does not allow for graceful degradation, is required
only for current IEeeks, and hopefully not for its future versions. CSS
can do the work in all other UAs, and allows for graceful degradation.
A second interface, a completely non-obtrusive facade for those who
want to avoid JavaScript at all costs and have widgets that function in
standard ways. Appearance still easily overridden with CSS.
Nonsense. Both birds can all be killed with one stone.
Any thoughts, ideas, cautions or warnings appreciated.

[x] done
PointedEars

PointedEars,

Thanks for the reply. I''m interested in a bit of expansion on the
things you mentioned.
Thomas ''PointedEars'' Lahn wrote:

Peter Michaux wrote: It does not work without client-side script support which is its major flaw.
I''m requiring the user has a browser released in the last couple years
and have turned javascript on. Is that unreasonable for a javascript
library? Do you consider all of your scripts as "majorly flawed"?
Perhaps I missed your point.
XUL and HTA exist.
These look specific to Mozilla and IE, respectively. If that is true it
doesn''t cut it for what I want to do.
<URL:http://javascript.crockford.com/inheritance.html>
Thanks for the link.

For JavaScript inheritance I want to use these ideas
http://www.kevlindev.com/tutorials/j...t/inheritance/

Factually wrong.

Why is it factually wrong? I am very interested in justified criticisms
of this method.
Unless .NET or SpiderMonkey 2.0 is a requirement, you can forget about
namespaces.

I mean simulated namespaces like
http://blog.dreamprojections.com/arc...12/27/450.aspx

[...]
All machinery CSS (the stuff that makes the items work eg. display:none
or display:block) inserted with JavaScript and the DOM into the tag''s
style elements so that they have specificity 1,0,0,0. This way a user
of the library cannot override without using !important in their CSS
rules.
[...]
<head>
<script type="text/javascript" src="seriousWidgets.js"></script>
</head>
<body>
<ul id="myMenuBar">
<li>item 1<li>
<li>item 2<li>
<ul>
<script>
var my_menu_bar = new
Serious.MenuBar(document.getElementById("myMenuBar "),
{option1:value1,
option2:value2});
</script>
</body>

This feature, which does not allow for graceful degradation, is required
only for current IEeeks, and hopefully not for its future versions. CSS
can do the work in all other UAs, and allows for graceful degradation.

"IEeeks"? Don know that one.

Why does this code not allow for graceful degradation?

A second interface, a completely non-obtrusive facade for those who
want to avoid JavaScript at all costs and have widgets that function in
standard ways. Appearance still easily overridden with CSS.

Nonsense. Both birds can all be killed with one stone.

The reason for the two interfaces is efficiency. If a user will not use
the easyWidgets interface then there is no point in having the
javascript search through the html for tags with className including
"easyMenuBar" etc.

Thanks,
Peter

pe**********@gmail.com wrote:

Thomas ''PointedEars'' Lahn wrote:

Peter Michaux wrote:
It does not work without client-side script support which is its major
flaw.
I''m requiring the user has a browser released in the last couple years
and have turned javascript on. Is that unreasonable for a javascript
library? Do you consider all of your scripts as "majorly flawed"?
Perhaps I missed your point.

Requiring a recent browser, and requiring it to have client-side script
support enabled are two different things. Especially with IEeek (see
below) and RadioActiveX (I think you get the idea). We really discussed
this ad nauseam here before. Search the archives about that, and search
them for UI library discussions. You are by far not the first person
(here) who thought of this, tried it and, inevitably, failed. Reading that
will probably help you investing your time in something that makes more
sense.

> For JavaScript inheritance I want to use these ideas
> http://www.kevlindev.com/tutorials/j...t/inheritance/

Factually wrong.

Why is it factually wrong? I am very interested in justified criticisms
of this method.

For example, there are no classes and no subclasses in the languages
supported by the execution environments you target. And the init()
approach, probably copied without minimum clue from the Prototype junk
code, is nonsense. The language already has constructors for that.

Unless .NET or SpiderMonkey 2.0 is a requirement, you can forget about
namespaces.

I mean simulated namespaces like
http://blog.dreamprojections.com/arc...12/27/450.aspx

As I said, those are not namespaces. Using a user-defined container
object for other user-defined objects is a better approach than declaring
everything global, that is for sure. But there is no guarantee that there
will be no interference with other, unknown libraries. The dynamic nature
of ECMAScript 1-3 implementations does not allow for such restrictions.

> [...]
> All machinery CSS (the stuff that makes the items work eg. display:none
> or display:block) inserted with JavaScript and the DOM into the tag''s
> style elements so that they have specificity 1,0,0,0. This way a user
> of the library cannot override without using !important in their CSS
> rules.
> [...]
> <head>
> <script type="text/javascript" src="seriousWidgets.js"></script>
> </head>
> <body>
> <ul id="myMenuBar">
> <li>item 1<li>
> <li>item 2<li>
> <ul>
> <script>
> var my_menu_bar = new
> Serious.MenuBar(document.getElementById("myMenuBar "),
> {option1:value1,
> option2:value2});
> </script>
> </body>

This feature, which does not allow for graceful degradation, is required
only for current IEeeks, and hopefully not for its future versions. CSS
can do the work in all other UAs, and allows for graceful degradation.

"IEeeks"? Don know that one.

IEs. User agents based on Microsoft Internet Explorer. Its layout engine
is this badly borken and its API is this flawed that some people, including
me, tend to think "Eeek" when talking about developing for it. And since
IE7 is not going to be released for Windows 2000 and earlier, it is
probably going to stay that way.
Why does this code not allow for graceful degradation?

Because there will be no menu without client-side script support.
Which can be easily avoided with a design approach that took more
consideration to develop.

> A second interface, a completely non-obtrusive facade for those who
> want to avoid JavaScript at all costs and have widgets that function in
> standard ways. Appearance still easily overridden with CSS.

Nonsense. Both birds can all be killed with one stone.

The reason for the two interfaces is efficiency. If a user will not
use the easyWidgets interface then there is no point in having the
javascript search through the html for tags with className including
"easyMenuBar" etc.

Efficiency and maintenance considerations are the reason why this should be
done with one script version, if that. One version that uses client-side
scripting only if necessary in the first place. It has been done before.

And, reconsidering this, for more recent IE versions apparently it can
be done without client-side scripting, too. The most recent and most
convincing example posted here that I can remember is

<URL:http://www.cssplay.co.uk/menus/dd_valid.html>
HTH

PointedEars

这篇关于JavaScript GUI库的想法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！