options

options.md

Options Pros/Cons

Single Attribute with character delimited key/value pairs

Code Sample

<input
  type="text"
  name="password"
  aria-required="true"
  purpose="field: password; moreinfo: url('PasswordFAQ.html'); symbol: url('images/helpicon.png'); importance: critical;"
/>

Pros

• Only a single attribute has to be added
• Less attribute namespace to be taken

Cons

• On the surface this has less "attribute bloat" but it doesn't really offer any advantages over separating these out into their own attributes

AUI attributes (aui-*)

Code sample

<element
  aui-field="password"
  aui-moreinfo="PasswordFAQ.html"
  aui-symbol="images/helpicon.png"
  aui-importance="critical"
/>

Pros

• attribute values are "cleaner" than the above option (no awkward semi-colon delimitation)
• this will seem familiar to developers used to implementing aria-* style attributes
• this will seem very familiar to angular developers (<div ng-bind="..." />)
• great for modern frameworks (react, angular, etc) in which the "template" is built in a javascript file where relevant data will be available

Cons

• attribute bloat
• a lot of attributes to remember (although character delimited key/value pairs have the same problem only within the purpose attribute's value)

CSS-Style declaration of key/value pairs

Code sample

.foobar {
  field: "password";
  moreinfo: url('PasswordFAQ.html'); 
  symbol: url('images/helpicon.png'); 
  importance: critical;
}

Pros

• utilizing a selector allows elements to share configuration (an attribute approach would force a lot of repeating assuming multiple elements would require identical config)
• no attribute bloat whatsoever

Cons

• separation of markup and configuration
• requires a separate entity? (assuming this would be either within a special "tag" (like css in <style />), or a separate file all together

Javascript object (very similar to the above approach but just in javascript instead)

NOTE: This could be in JSON format as well (it'd look almost identical to the below code sample)

Code sample

{
  '.foobar': {
    field: "password";
    moreinfo: url('PasswordFAQ.html'); 
    symbol: url('images/helpicon.png'); 
    importance: critical;
  }
}

Pros

• All of the pros for the "CSS-Style declaration of key/value pairs"
• Already in javascript which I'd assume would be the language consuming this anyway
• Developers are familiar with js so they'd be comfortable with the syntax

Cons

• All of the cons for the "CSS-Style declaration of key/value pairs"

dataset (data-* or data-aui-* attributes)

Code sample

<div
  data-aui-field="password"
  data-aui-moreinfo="PasswordFAQ.html"
  data-aui-symbol="images/helpicon.png"
  data-aui-importance="critical"
/>

Pros

• Modern frameworks all support passing data attributes through to the rendered html (react wounldn't throw any warnings)
• This is a very common convention which means less push-back/resistance from developers implementing this

Cons

• Basically all of the cons listed above in "AUI attributes (aui-*)"

In the first example should be name="password" not telnum"

For the last data-aui-*
Cons: (the idea of Attribute Bloat, while true, these attributes would not impact HostLanguage developers in the same way as true attributes would require, as we would need their buy-in for aui-* attributes but wouldn't for data-aui-*
(Am I right in this assumption?)

My preference would be the single attribute with character delimited key/value pairs. With a limit of three pairs. To account for this limitation we could look at the semantics and define three base attributes. In the example about the based attribute is "purpose."

An addition my other preference is "data-" but not "data-aui-". I believe "aui" should be more descriptive. Potentially "custom" but not sure.