summary from the call on implementation of the vocabulary

Summary of implementation of the vocabulary  Native is the best - but we do not know how much  support for it we will get and therfore we want to work towards native suport but not rely on it. so we need an extra solution. We will need to ward implention that there may be a move to native and tag thing that are likely to go in. We can also make a conversion script etc. RDFA and microdata are ruled out may be supported as a secondary implementation but we are not going to rely on them either. ARIA is also ruled out as a primary implementation, as, realistically,  we will not get much in. Still in the running are: value pairs seemed to lose support as we could not have more then one attribute per ellement. looking at the early implementation that seemed bad in about 40% of cases Simple single attribute: (eg: <button purpose="action-undo">Revert</button>) main con was it does not support text, and URIs like symbol and easy lang. Parsing multiple attribute adds a huge slowing down on use agent performance. It can only be in as a part of a solution. Two main contenders There was a new contender of a complex single attribute (from John) such as  <button aui="purpose:submit; symbol:url(http://url); easylang:(this is simple test) "> pros so far: single attribute, allows full implementation and follows the style attribute style sheet . The cons include: complex to parse for AT; slow to parse; a bit complex to write Also this style is being depreciated and many w3c people do not like it. We should find out why As michael said "If we don't wind up pursuing the two-attribute model, we explore whether the issue of having a really complex attribute model for the single attribute is a deal-killer" The aui- attributes seems good. Main cons discussed: adding a lot of attributes meens there is more for the author to learn.   All the best Lisa Seeman LinkedIn, Twitter

Received on Tuesday, 18 September 2018 08:57:41 UTC