qpih.txt (1.8 KB)
弄好了，你把js发给我，我改了你测试一下
核实了我就推广到以后的tab版本里面。
测试一下，一定要清除cache。
qpih.txt (1.8 KB)
已经没问题了。
好的，修改起来比争论简单多了。不过我的观点还是一样 不应该很多页面混在一起。
指出问题可以，请注意措辞。
此问题也就是一些创新词典（如 TAB）和词典软件的兼容问题？对事不对人，大可不必言辞激烈。HTML 能有多自由，词典也能有多自由，在一两年前，还有人开发过在词典内（不依托词典软件）能全文搜索的的 CC-CEDICT ，好像还用的 React 还是 Vue，也有兼容性问题。
回到本帖提到的问题，是不是把 id="qpih1" 变成 id="qpihN-ENTRY-NAME" 也能解决问题？N 为第几个 tab，ENTRY-NAME 为词头名，可能需要用 hash/encode 来避免特殊字符。这样多个词条（如 (a)pple 和 apple [strip key]）叠起来也能正常切换。
对啊，解决方案是很多的。改个id并非难事， 你思路和我一样的。前方四个字母是随机生成的， meandmyhomies每次做词典都有生成唯一的字母代号，词条只要用数字递增序号就行了，hash和encode反而不太直观。
使用mdict程序时，觉得tab词典有意义，但使用GD-ng，感觉tab方式已经没有太大必要。
如果id要全球唯一，那就得在每个地方加一个很长的guid，体积和overhead都猛增。
不仅如此，javascript里面还得把这个值本身传来传去。
最简单的方法是根本不用ID或者tagName. 永久有效，和是不是唯一完全无关，和name, namespace 完全无依赖。
不行的，词条内容序号是唯一的，但是tab按钮序号是1234这样的，在同一个词典里面堆积了多个词头的时候肯定重复。这些我都考虑过了。
主要是保持屏幕稳定，不用跳跃和大量滚动屏幕
几十个同类辞典分为一个tab小组，利用效率还是比直接排列在词典分组高，也方便比较相似内容。
我想说的就是GD中就可以分组，而且更新加入等更为方便，也更个性化。 
对的，tab最大的优点就是横向压缩空间，一般字典软件只顾竖着堆积内容。而且是已经安排好的 不需要人工去定义横向分类。
如果查词的结果每个词典都用独立的页面横向展示，就和浏览器开多个标签页面一样，效果是不是和tab字典差不多？不过资源占用，效率估计是问题。
我认为至少不同的字典要分开来，可能就像虚拟器一样，隔离+共享同时存在。
完全堆积在一起就必然把所有依赖ID 和 TagName的字典弄残了
我倒是觉得TAB也被最顶级的英语字典采纳了，比如 OED 和 M-Webster 官网都是TAB结构的（这绝非偶然）