这是Jerry 2020年的第81篇文章，也是汪子熙公众号总共第263篇原创文章。

Jerry之前的文章从医院到家，再重返SAP成都研究院，Jerry还没死 提到，我手术后重返SAP成都研究院，退出了Global的Spartacus开发团队，开始从事SAP Commerce Cloud新一代Storefront的开发工作。文章 SAP Spartacus简介，对SAP Spartacus做了一个概要介绍。

本文给大家分享Jerry上周解决一个Spartacus issue的经验。

原本Jerry也自夸是一位SAP全栈开发工程师——我能纯熟应用SAP UI5，SAP Fiori Elements，SAP WebClient UI，SAP ABAP Webdynpro进行全栈开发，并且深刻理解这些工具/框架的底层工作原理。

不过，当最近解决Spartacus的Accessibility issue时，我还是感觉本人的前端常识远远不够用。

满足Accessibility(可拜访性)的利用，即利用以“所有人”为外围(包含某些残疾人)，能在更广大的场景下毫无阻碍地被应用。

互联网的力量存在于它的普适性中，让包含残疾人在内的所有人都能拜访互联网, 是普适性中必不可少的一部分。
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee
Inventor of the World Wide Web

Accessibility也是SAP Product Standard(产品规范)之一，在SAP产品从设计到开发，测试，直至最初公布的整个流程中，确保产品对Accessibility的良好反对，是每位SAP开发人员致力的指标之一。

Accessibility听起来有点形象？SAP产品为了满足Accessibility，到底须要做什么具体的开发工作？确实，Accessibility是一个比拟抽象的领域，比方Jerry目前工作的Spartacus Accessibility, 落实到编程层面的实现，总共分为下图几类(Accessibility缩写为a11y). 而我上周手头上解决的一个issue, 是对于键盘的可拜访性反对(Keyboard Accessibility). 简略来说，就是用户能用鼠标操作Spartacus实现的性能，用键盘也必须同样能实现。

“挪动-点击”的鼠标交互模式对于普通用户来说，是最为简便高效的网页定位形式。然而对于视觉存在阻碍的用户来说，用肉眼定位鼠标箭头的地位, 不是一件容易的事件。而对于某些存在肢体阻碍的用户来说，应用鼠标甚至都是一件十分艰难的事件(这一点Jerry刚刚被推出手术室后的头七天几乎深有体会)。

对这些因为某种原因无奈应用鼠标来拜访浏览器利用的非凡用户来说，如何将鼠标的“挪动-点击”的交互模式转换成其余更易操作的步骤呢？

咱们利用键盘的tab键，按秩序遍历页面上的元素。

通过这种形式，将本来用鼠标抉择页面元素的形式，切换成了用键盘Tab键来代替。

当按下Tab键遍历到某个元素时，该元素取得焦点(focus), 触发onfocus事件。Jerry解决的issue, 如下图所示，问题症状就是Spartacus Organization Unit List这个列表的行我的项目，取得焦点时的轮廓线(outline)显示不尽如人意，视觉效果须要改良。

列表行我的项目第一列的实现，是一个自定义复合控件(Composite Control, SAP UI5也有相似概念，叫做Reusable Control), 由一个a标签和一个button标签形成，其中a标签通过自定义管道cxUrl在页面渲染时动静生成一个url, 指向该行我的项目对应的Organization Unit明细页面。当a标签持有focus时，鼠标点击或者回车键按下之后，跳转到Org Unit明细页面。

Button标签联合自定义的cx-icon标签一起，二者独特实现一个三角箭头。点击后，会开展和收拢该Org Unit的子Unit列表。

Issue形容的问题

当行我的项目复合控件内的a标签被tab键focus之后，因为a标签的css设置，它自身会显示被focus的轮廓线成果。同时，a标签的父节点，tr标签设置了伪类focus-within, 其成果是，一旦tr有任意子节点失去focus, tr自身也会失去focus.

如此一来，a标签失去focus时，列表行我的项目就会同时呈现两套轮廓线，一套是标签a focus之后显示的outline , 另一套是标签tr的focus outline.

因为这个列表行我的项目一些另外的bug, 这两套轮廓线的叠加显示，视觉效果不佳。更蹩脚的是，在不同宽度的屏幕下，a标签本身的focus轮廓线还会有差别：只有当窄屏时，能力显示残缺的上下左右四条轮廓线。


我刚刚退出团队时，团队的开发经理给我调配了一位开发大佬，负责解答我开发过程中遇到的技术问题。据开发经理介绍，这位大佬是Spartacus的元老级人物，从Spartacus立项到当初最新的3.0版本始终参加其中。这位大佬第一次和我电话里相互介绍彼此时，给我学习Spartacus的倡议粗心就是，“遇到问题尽量本人多思考，多想方法，而不是马上就在Slack上
问我，这样你会成长很快”。


这正好和Jerry每当进入一个SAP新的畛域时的学习办法统一，我也没感觉什么不妥。

所以当我打算先把我correction的思路和大佬探讨时，大佬间接回复我一波三连击：

  • 我冀望的行为是XXX
  • make it happen
  • show me the PR

我过后看到大佬提出的需要，第一反馈就是: 1 border when highlighting the row这个需要，技术上无奈实现啊! 我过后的想法是，伪类focus-within不就是通过被润饰元素的子节点接管到focus, 从而达到本身也被focus的成果吗？这意味着Org Unit List行我的项目内，只有有任意一个元素被focus, 整个行我的项目必然有两套focus轮廓线呈现，而不是大佬要求的一套。所以，大佬这个需要技术上无奈实现啊。

于是，我向大佬表白了我的认识：我认为这个需要技术上无奈实现。

大佬没有回复我。

起初我把这个issue波及到的一些知识点列举了一下，通过google和stackoverflow逐个进行了学习：

  • scss的工作原理
  • scss里%和&的用法
  • scss里@minxin的用法
  • scss里@include, @extend的用法
  • pseudo class :focus和:focus-within的区别
  • tabindex的应用办法
  • onfocus和onblur的关联
  • css specificity的含意和calculation rule
  • a标签能接管focus事件的前提条件
  • 页面元素margin, padding和border的区别，各自应用场景
  • 几种css选择器和优先级

学习完这些知识点之后，我立刻悔恨了，感觉当初不该对大佬说出“这个性能技术上无奈实现”这句傻话。事实上，要实现行我的项目focus时只显示一套focus轮廓线的需要，办法几乎太多太多了。

第一次尝试

我把a标签的tabindex设置成-1, 这样a就不会收到focus了。a标签的兄弟节点，button标签收到focus时，其父节点即tr通过:focus-within，也收到focus, 成果如下:

然而，因为a标签的tabindex为-1, 意味着它不能再接管focus事件，所以回车之后无奈触发跳转到unit明细页面的操作了，这条路行不通。

第二次尝试

我想通过调整a:focus的outline-offset值，设法让其和tr的focus轮廓线齐全重合，这样focus事件产生时，视觉上讲，用户也只会看见一套轮廓线。

然而我察看了现有的tr轮廓线，发现有计算逻辑参加在外面，而a标签并没有。简略评估了一下，如果要让a标签在不同的屏幕尺寸下的轮廓线和tr标签的轮廓线始终保持重合，代价太大，得失相当，所以我放弃了。

第三次尝试

间接暗藏a标签的focus轮廓线。这样，技术上来说，尽管标签a失去focus时，它会和父标签tr同时被赋予各自的focus轮廓线，但前者的轮廓线被设置成暗藏，因而视觉效果上行我的项目只有一条轮廓线，这就满足了大佬的需要。

最初行我的项目失去focus时的轮廓线成果如下：

尽管通过这个issue我学到的css相干常识，在前端开发大佬们眼中不值一提，但这些的确是我以前不理解或者没有了解透彻的，因为以前始终做SAP UI5和SAP WebClient UI的应用层开发，99%的状况下不会间接操作css和scss.

我也非常感谢给我提出需要的开发大佬，在我贸然说出"这个需要技术上无奈实现"的时候，没有立刻怼我，而是抉择了间接忽视，这才给我发明了通过google和stackoverflow空虚本人的机会。

通过这个issue我的领会就是，程序员在本人尚不齐全相熟的畛域工作时，如果没有十足的把握，最好别贸然说出“这个性能技术上无奈实现”这种话，否则，后续可能会被打脸。

感激大家有急躁读完我工作中的产生的这件琐事，心愿对大家有一点点启发，感激浏览。

更多Jerry的原创文章，尽在："汪子熙":