本周工作思考
- 本周的绝大部分时间在在跟进拖拽的问题，主要遇到了几类问题：
- 非可拖拽目标区的定位，拖拽的API中对drop事件和dropend分别对应可放置区域和拖拽目标，小节列表在定义上把除去右侧导航和顶部导航的区域都是可放置目标区域，但是实际dom上没有触发事件，所以使用代码模拟实现这个功能，其实这个也是我个人认为HTML5 Drag API设计的太过抽象，对来说拖拽目标有 drag start，drag end，可放置区域上有drag over，drag enter，drag leave，drop，有一种情况是拖拽目标飞到非可放置区域释放了，这个时候只触发drag end，此时程序无法拿到可放置区域的任何信息。从拖拽本身来说，离开区域应该是不做任何操作，实际上对更易用的交互来说，比如我们这种交互需求，需要默认的操作，所以API，应该有一个类似 drag abort的事件，应对这种拖拽在非放置取的情况，从更广泛的场景上来说 ，浏览器Tab和Tab之间， 两个Chrome之间的拖拽就非常适合这个API的使用，当然还有不同程序和浏览器的拖拽交互，不同浏览器之间的拖拽目前看似乎都有技术硬伤的存在；当然目前API的也具有相对的先进性，比如我们有一个小的需求是在非置顶区章节拖拽到非置顶区域时，拖拽预设图像要变成红色，之前在技术预研的时候，我发现不能实现，就和@贾琨说了这个技术上问题，这周随着最这块技术的深入掌握，我发现是可以自定义这个图像，甚至可以直接使用Canvas或者Video，具有相对高的可定制性，但也有一定的复杂性；
- IE兼容上，对于施加了dragable的元素来说，其内部input的的焦点触发和光标，有明显的bug，可能也是IE浏览器的地方方言，焦点触发后其光标是不展示的，需要二次激活，这个问题只改了一行代码，实际上查了将近一天的时间，只为修复这个莫名其妙的问题，通过这个bug，我很理解Microsoft为什么放弃IE了，因为类似的问题我们遇到好几个了，我的理解是IE已经修不过来这些bug了，比如自定义标签了加入disabled属性，自定义标签里的事件触发机制，带有非常明显的IE的特色，不能完全说IE有明显的bug，但是从浏览器的发展来看，不符合标准就是bug，这个行业里事实上的规则了；
- 还有其他疑难问题，根本上都是现有拖拽dom实现的问题，基于树状的拖拽，硬要在结构上做成一维数据，还是有一些复杂的，在课程分类，组织架构有过类似的树状拖拽排序，从交互上看相对简单，限制条件较少，相对这次的实现，前期的设计没有做好，很多bug在填设计上的坑，这是一个很大的教训，中间有想过重新设计，我发现成本也是比较大，并且也不见得是最好的设计给后期扩展和测试都会带来极大的风险，就放弃了这个方向。