Add language to http://ampersandjs.com/learn/role-attribute to discuss accessibility implications
wraithgar opened this issue · comments
Assigning certain role attribute values to some elements affects the way accessibility readers present your UI to the end user.
It would be nice to at least mention this in the learn page, and hopefully even go into some best practices (if some can be determined)
Hey @AmpersandJS people. This issue is important. The basis of your recommendations for using a role attribute are sound -- preventing collisions between devs and designers in use of id and class attributes. The problem is that role is important for ARIA: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
A better solution is to recommend data-* attributes. On one hand they can name the attribute in semantically meaningful ways. More importantly they enable people to use role in support of making their web apps helpful to people with screen readers or other assistive devices. As it is now, you are steering people in a direction that can discriminate against people with disabilities.
For your own code, find and replace role with data-role and then rewrite that page to be about "The humble data-* attribute". jQuery won't notice the difference if your selectors change from [role=anything] to [data-role=anything]. And same goes for the HTML markup.
Related: http://www.w3.org/wiki/PF/XTech/HTML5/RoleAttribute#ARIA_1.0_Pre-Defined_Roles (ARIA reserved roles)
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#data-* (definition of data- under the context of use by scripts)
We most certainly don't want to cause problems for accessibility. My question currently is just if it's better to avoid using them or to add as much semantic value to the doc as possible?
There's a potentially nice overlap in this, in that JS also cares about the element's purpose in the app.
So, perhaps encouraging people to use it may actually be a net gain in accessibility where most won't add roles at all otherwise? If we could accomplish that, that'd be awesome.
If it turns out that's not the case we'll certainly change the recommendation.
I'm still looking for a definitive resource or expert in how they're actually used for accessibility.
Help in figuring this out would be much appreciated.
@HenrikJoreteg this is the resource we were trying to find http://www.w3.org/wiki/PF/XTech/HTML5/RoleAttribute#ARIA_1.0_Pre-Defined_Roles
It outlines explicitly the ARIA 1.0 pre-defined roles that are considered 'reserved'. As you can see it's not a small list, and has a section at the end for extendability too.
I'm personally of the mind that in that light, and after re-reading the html definition on data- http://www.w3.org/TR/html5/dom.html#custom-data-attribute and seeing how it's explicitly not to be interpreted by anything outside the site itself, we should be using data- instead of role.
My gut feeling is to think of ARIA as another separate concern. So let the CSS work from id and class, let the javascript work from data-* attributes, and let ARIA stuff work from role and the various aria-* attributes.
I've been using data-* attributes for binding DOM to javascript in various production environments for several years now. I haven't done anything directly with ARIA. I learned about ARIA while investigating the Fluid Infusion project:
http://fluidproject.org/products/infusion/
https://github.com/fluid-project
They seem to be quite serious about an inclusive web. Google seems to think Mozilla's pages on ARIA are the place to start, but I think you might find the code in Infusion worth looking at. And perhaps it will be a case where Ampersand proves flexible enough to use Fluid components in the view to gain the benefits of their thinking on accessibility and inclusiveness.
On a quick glance, I'm +1 on shifting the recommendation from role to data-, and updating getByRole in ampersand-view appropriately, as well as the various role selectors in, eg ampersand-dom-bindings.
Given the wide range of roles already defined, and their use in accessibility, it doesn't make sense to me to try and compete with their use. Given how generic the roles are, it also doesn't make sense to me to try and overload them by trying to use them for both accessibility and js hooks.
The question then is what should we switch to? The benefits of role were:
- It's short, and easy to remember
- It was always the same attribute name - the trouble with data-* is that it's easy to get creative with the attribute name which leads to inconsistency.
data-role="foobar" would be the obvious alternative, but that feels a bit weird as it's kinda confusing with role now, and getByRole gets more confusing.
this proposes data-js, which has the benefit of being clearly related to JS, and is fairly short. Though, I don't know what you'd rename getByRole and the role shortcuts in ampersand-dom-binding to?
+1 for data-js but as you said, to quote classic: “There are only two hard things in Computer Science: cache invalidation and naming things”
I agree w/ the data-role feeling like it was an arbitrary decision that's based on the practice of having used role before.
data-& is unfortunately invalid html :/
Without haven given much thought (so heads up on that) I feel like if we go with data-js the function becomes getByDataJs(foo) or getByData('js', foo)
The nice thing about this is we can leave getByRole so as not to break anyone using that in production. REMOVING getByRole imo can be a totally different discussion i.e. do we deprecat now, do we have a timeline goal?
getByData might be kinda confusing, as people may think that it refers to "data" itself, not data attribute.
About getByData('js', foo), I agree with @latentflip that people can get sometimes too "creative".
Just my 2 cents. getByData('js', foo) may become very tiresome after a while, writing js every time you want to bind something, I kind of prefer a more specific approach like getByDataJs(foo)
Just for the sake of creativity getByJsTag(foo), getByJsRole(foo) or getByJsNode(foo).
Some pondering I've gone back and forth on about this issue:
- There have been instances where I've wanted to be able to reference an element via multiple "roles", mainly for some views where the template was user supplied and some features conceivably could exist on either a single element or multiple.
- The spec for the
roleattribute says that it is actually a space separated list of values (of which the browser uses the first one it recognizes for ARIA purposes).
So, I'd like for any getByX() method to support picking out the given value from a list. In which case, what if we made getByRole() pick an element that contains the given value in the combined set of role and data-role values?
It's short, and easy to remember
It was always the same attribute name - the trouble with data-* is that it's easy to get creative with the attribute name which leads to inconsistency
+1
FWIW, data-js doesn't appeal to me; I would prefer data-role (though that would imply getByRole() which wouldn't allow them to live side-by-side) or data-name (which may be confused w/ the name attribute, but at least it's less confusing than data-id).
A few more options from the synonym finder: title, tag, label, moniker, handle. Most of those are already used in HTML, of the ones that aren't, I like data-handle the best...
Great thoughts @legastero, 👍 on whatever solution supporting multiple roles. We can do that with [data-role~=logged_in] [role~=logged_in] or whatever.
Also, on @legastero's point about role allowing multiple attributes, I'm intrigued as to what the potential fallout of using non-aria roles in role is? I guess the concern is future collision, but that feels like a minor concern. Which I guess is back to @HenrikJoreteg's question of whether it's still actually okay to still use role, and just teach people how to also add proper accessible roles where it makes sense.
pick an element that contains the given value in the combined set of role and data-role values?
I really like this idea; it allows us to transition to data-role while still allowing role to co-exist side-by-side during a transition period.
On discussion with @wraithgar I'm back to a firm 👍 on not using role, as it's just plain not meant for this, and I defer to @dobbs completely on the accessibility implications, so sorry for re-suggesting it in my last comment.
I dislike data-role though. And I don't like data-js anymore. Maybe that's because I'm difficult :)
data-hook, getByHook
<div>
<h1 data-hook="name"></h1>
<div data-hook="profile-form"></div>
</div>bindings: {
'model.name': {
type: 'text',
hook: 'name'
}
}
subviews: {
profileForm: {
view: ProfileForm,
hook: 'profile-form'
}
}data-intent / getByIntent() or
data-purpose / getByPurpose()?
In a direct message w/ @latentflip I shot the idea of 'data-bind' down because it's wrapped up in my head w/ model bindings but not view bindings. However I think it's still important to bring up in case I'm completely wrong.
Hook sounds pretty good :)
The benefit of separating this concern from the role attribute is making Ampersand more amenable to developers who do know about ARIA and are using it to make their web applications inclusive.
The risk of putting names in role is mainly about interfering with the operations of screen readers and other assistive devices. Someone using Ampersand but unaware of ARIA might chooses a role name that's "reserved". In so doing they would invoke unexpected behavior from a screen reader that almost certainly doesn't match whatever they were expecting to do.
There you have both a pro and con pointing towards separating completely from the role attribute.
With regard to naming, I rather like the idea of data-binding because that term matches well with jargon already used by various other javascript frameworks when talking about connecting javascript to the DOM. You can google for "data-binding" or "javascript data binding" and find material that matches with the intent of this api. That said getDataBinding doesn't sound like quite the right thing, 'cos from the javascript side, your looking for DOM elements. Maybe getElementsByDataBinding for matching other DOM apis. It's long which is not always great. But it would again be easy to grep for in a code base, or in Google.
Just a heads up we're thinking of changing .get() which could also change what this unnamed function is called.
AmpersandJS/ampersand-view#18
Knockout uses data-bind http://knockoutjs.com/documentation/binding-syntax.html
I dislike bind because that's not what we're doing, we're defining a selector for binding OR view insertion OR whatever else. It's a selector, not a binding. That knockout link is a great example of actual attribute binding, storing the binding info in that attribute.
A few thoughts.
Everyone keeps saying it might interfere with screenreaders so I tried it on the sample app that ampersand-cli generates. I used the chromevox screenreader extension from chrome: https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmljglcjbhoiplfn
It reads text in the page containing what you click. Starting with headers, etc. To see what it did I added "navigation" (a known reserved role) as a role to the navbar, it read the contents of the nav, then simply said "navigation" when it was done reading the contents as additional context.
It didn't read any of the other roles (like page-container) out loud.
I'm afraid I disagree that our use of this goes against its intended purpose, here's the spec: http://www.w3.org/TR/role-attribute/ the abstract follows:
The Role Attribute defined in this specification allows the author to annotate markup languages with machine-extractable semantic information about the purpose of an element. Use cases include accessibility, device adaptation, server-side processing, and complex data description.
I don't know about you folks, but I never used to use role for anything, which meant I provided zero help to screen readers. Since encouraging use of role my apps are now all marked up with additional semantic context beyond just reading tag names (which is what the screen reader seems to do by default).
I simply fail to see what damage is being done. If you can show me what we're doing that's causing harm for accessibility I'll be the first to push for a change.
But, the way I see it, we have a chance to provide developers more incentive to markup their apps to make them better for accessibility and help draw attention to the need for doing it. I didn't know role even existed before we started looking for something to use for this problem!
Role allows a clear, semantic mechanism for describing what its purpose is in the document.
So, from what I'm hearing the "cons" can be summarized as: "someone will use a reserved role attribute to describe something that isn't actually playing that role and confuse the screenreader".
I don't understand how that's even likely to happen. Why would I assign a role of "menu" or "list" or "button" or "navigation" to something that doesn't actually serve that semantic purpose?
Apparently I'm in the minority, but I still see encouraging the use of role as a huge net positive for improving and increasing awareness of accessibility.
If anything I think we should be encouraging developers to use the "reserved" roles where they semantically make sense.
Other relevant reading on ARIA: https://developer.mozilla.org/en-US/docs/Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets which explains how the use of the role attribute in combination with aria- can provide even more contextual information.
A potentially useful Stack Overflow answer: http://stackoverflow.com/a/18664038/107722
I like the idea of using this choice to encourage developers to learn the reserved role words for the sake of accessibility, which is always completely in line with semantically meaningful markup, and is also generally in line with meaningfully descriptive code.
But if that’s what we’re doing, we’d of course need to also add that info and context to the ampersand role docs. :)
Yup, if this is the route we end up going, we should definitely take the opportunity to educate and explain these things properly in the docs.
@HenrikJoreteg are users potentially adding role values beyond what's allowed in WAI-ARIA? There is a list of roles that are expected by assistive technologies--anything else has potential to cause problems. It can change what type of DOM object ends up in the Accessibility Tree and change what behavior is expected from a user of a screen reader or a screen magnifier. If the value of role as proposed might be anything other than what's on this list, you need a custom attribute.
You can, however, add the actual WAI-ARIA role using JavaScript. For example, if you're creating a checkbox component, you can dynamically add role="checkbox" and compute aria-checked="[true|false]". If the framework can infer and add correct ARIA attributes where a user might forget, even better. Let the framework do the heavy lifting--but it needs to be right according to the spec so that assistive technologies can use it.
In the first example on http://ampersandjs.com/learn/role-attribute
<div><a class="save-button" role="action-save">save result</a></div>
This is a perfect example of where misusing role is going to cause problems.
Firstly: this should be a button, not an anchor (http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#first-rule-of-aria-use).
But if you really must use an anchor, this should absolutely have a role value of button. As it is, this will be announced by screen readers as something like "save result link" (implying a navigation will occur), where you are obviously presenting it as a button (implying that it will perform an action and not navigate). Using role="button" will cause this to be presented to assistive technology as a button, which would seem to be what you want here.
Educating developers to use role for something other than its intended use is a bad idea. Educating developers to use role for its intended use, however, would be fantastic! You can even use a similar idea to what you seem to be presenting here - instead of using class="save-button", you could use a role selector:
a[role=button] {
<style as button>
}
a[role=button][data-foo=action-save] {
<some other stuff>
}
👍 thanks @alice
Also, you should take a look at http://www.w3.org/TR/wai-aria/roles and http://www.w3.org/WAI/PF/aria-implementation/#mapping_role
If the element does not have a role attribute, or if the role attribute contains no tokens matching the name of a non-abstract WAI-ARIA role, the user agent MUST fall back on normal processing of the base markup for the element with the role attribute. For example, for
<table role="foo">use the element name table to determine what platform accessibility API role to use according to the host language's role mapping. For<input type="text" role="bar">, use the platform accessibility API for a text input.
Oh, and http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#what-does-adding-a-role-do-to-the-native-semantics (that whole document is really good, in fact).
Use of the role attribute as described is a misuse and prohibited in HTML.
The ONLY conforming values for the role attribute in HTML are those defined in the WAI-ARIA specification
The attribute, if specified, must have a value that is a set of space-separated tokens representing the various WAI-ARIA roles that the element belongs to."
http://www.w3.org/html/wg/drafts/html/master/dom.html#aria-role-attribute
This can be easily checked using http://validator.w3.org/nu/
The following code:
<a class="save-button" role="action-save">
produces the following error:
Error: Bad value action-save for attribute role on element a.
It is prohibited because the role attribute value maps to the role property in all accessibility APIs. These APIs communicate the semantics (roles/states and properties) of HTML elements and attributes via the browser to assistive technologies (AT). Role values override the native roles of all elements. When a non standard undefined role value is used, typically AT have no way to know what the element represents and how to convey its meaning to the user.
Strongly recommend using data attribute, 'data-role' is fine. Leave the role attribute for its defined and important purpose in HTML.
@alice I realise what I have said above contradicts somewhat what the ARIA spec says, but some browsers have implemented role value mapping in such a way that they expose any value regardless of whether its a defined value or not.
@stevefaulkner No problem, happy to be corrected! (Although I would be curious to know which browser/OS combinations do that...)
@stevefaulkner @alice @marcysutton thank you all for your input. We're trying to do the right thing and simply didn't have the right information. It sounds like we have our answer and we'll make a change. Now we'll just have to figure out what the best alternative is.
Thanks again.
@alice I know that IE does in UIA ARIArole property, but don't have access to a machine to do checking (on hols) on others, so can't confirm the veracity of my claim right now. What ARIA describes is the correct and hopefully implemented behaviour in most browser/AT combos.
@HenrikJoreteg a more general issue with use of role (with conforming values) is that simply sticking the role on is not enough - What ARIA does not do If roles (and associated properties) are used then the behaviours must also be implemented that are associated with those roles. The ARIA design patterns are super useful in understanding what is required for many custom widgets.
Thanks @stevefaulkner!
Current front runners for alternatives are rel and name.
I'm leaning toward rel personally.
In real world code I've used name to distinguish between form inputs I care about serializing and those I don't (I capture changes and do other things w/ those values instead)
Also I like rel but the html5 spec does mention "acceptable values" which to me reads like a closed list.
$.02
ETA getting links like this from Henrik's helpful request on twitter: http://microformats.org/wiki/existing-rel-values and I'm infinity percent less concerned about role breaking things on a random browser (which is something people usually QA for anyways) than I was about limiting accessibility (which sadly isn't on most QA radars). So my concerns w/ rel are miniscule.
Sorry, but 'rel' is not like 'role'.
'data-role' is much more like 'role'.
And it's html5 btw. ;)
html5 is about semantics and rel (relationship) is not a 'role'.
What about css classes that follow a convention: .js-{role}?
(this is what Github uses for dom bindings)
Before this dissolves into a long list of suggestions. Here's some outlines, since we've been back and forth this once in the past internally (which brought us to role in the first place). The following are listed without my own additional biases:
- we aren't gonna do classes with a prefix. It's just not clear enough when looking at a template whether it's safe to change/remove it, and it's too easy to start using .js-* or whatever in CSS.
- we aren't going to use role, as discussed
- we might reuse an existing neglected attribute, like rel or name, basically for the reason that it's less letters than data-*
- we might use data-role, data-hook or data- since that's the most "correct" option as far as the spec goes
- we probably won't add a new attribute since it's not spec friendly and there's probably no real need.
And the things this decision will affect are:
- what we document as the suggested way
- what we name the shortcut getter method in views, eg: getByRole currently
- the shortcut alternative to 'selector' in both bindings and sub views, which is currently 'role: "something"'
So the discussion probably should only revolve around shortcomings of the two "mights" above, unless there are any fresh ideas not covered by the above.
Philip Roberts
&yet
On 19 Aug 2014, at 21:59, Andrei Canta notifications@github.com wrote:
What about css classes that follow a convention: js-{role}?
—
Reply to this email directly or view it on GitHub.
I don't want to quibble over details but there's only one correct option: data-*
I'd rather accept a few keystrokes more than put my trust in some 'neglected' html-attribute.
A snake pit...IMHO.
Adding some more info:
The spec for rel specifies that non-recognized values in a space-separated list are to be ignored.
This validator: http://validator.w3.org/nu/ complains about using a strange rel on the a but not on the p :-/
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
</head>
<body>
<p rel="something"></p>
<a rel="otherthing" href="asdf"></a>
</body>
</html>
Since I suggested it, (and not that my vote really counts, but...) I still think rel is quite appropriate. And it really doesn't have anything to do with "saving keystrokes".
I know there's argument above about the "semantics" and what's appropriate. But anyone who lectures with a suggestion that there's any sort of "one true perfect semantic" for HTML5 tags and attributes hasn't really payed much attention. At best, "HTML5 semantics" are about "best fit" and "best effort". There's plenty of places where the "semantics" have been debated and debatable, and it generally comes down to judgement calls.
In that spirit, here's how I define the semantic for using rel in the suggested way: since rel (aka, "external relationship") is kind of irrelevant for most tags, repurposing rel to mean "internal relationship". That is to say, I use rel to mean "relationship between the given tag and the JS code." Is it perfect? No. But it's pretty close to what people mean by "role" and it avoids the ARIA conflicts.
As for validation and collision of rel values, the spec indeed does say to ignore custom values, and it allows multiple space separated values, so even in the "worst" case where we're talking about an <a> tag (where rel can indeed be used for external relationships), you can stuff both an external value like "me" in there with an internal value like "profile-button".
This is not just theory. I've done this many times on many different sites/apps, and we've never had any issues with search engines or other tools.
If you end up not using rel and go with a data-*, please don't use data-role, as that will be even more confusing to have to explain to people how role and data-role are totally different.
it does not fail with rev but i don't like the complete lack of semantics there.
More info on changes to rel and rev here: http://blog.whatwg.org/the-road-to-html-5-link-relations
sigh
I dislike how long data-* is. Especially when typing out in longer form: [data-hook=something] or if you're add lots of them in your templates.
What about just making something up. All browsers deal with it fine and have for years. The precedent has certainly been set by angular with ng-.
I'm leaning toward agreeing with @getify on this and just using rel. To me it's either that or just make one up, i'm liking @latentflip's hook suggestion.
rel would also play nicely in function form getByRel(), etc.
I'd avoid any reusing of older attributes who "mostly" work or "in most cases". It doesn't sound stable and trustworthy.
And anyone who knows html5 can easily accept the fact that "role" belongs to a certain standard and therefore data-* has to be used.
Regarding 'data-hook' I'd like to mention that a "hook" has a special meaning in certain coder communities (linux hackers, windows kernel level development etc.). A "hook" is a special procedure to "hook into a syscall".
OK, sorry for the theory, I'm sure you know that already, but just in the case you show your code to some colleague who's hacking linux etc. ;)
I agree with @brakmic. The name attribute means something important on form input elements, and rel means something important on <a> and <link>. jQuery already exposes .data() as a getter method to get values from data-* attributes.
Please don't follow angular's example and make up your own attribute prefix. Angular gets a LOT right, but that choice is going to bite them in the long run. XML has proved that namespaced attributes become difficult for people to use correctly.
More importantly, you really only need one attribute to replace your existing use of role. HTML5 added data-* specifically for this purpose. Creating your own prefix is inviting more made-up attributes.
If you really want shorter usages, there's another way to use those selectors. From your example...
<div><a class="save-button" data-action="save">save result</a></div>
bindings: {
'model.saveable': {
type: 'booleanClass',
selector: '[data-action=save]'
}
}
OR
<div><a class="save-button" data-action-save="1">save result</a></div>
bindings: {
'model.saveable': {
type: 'booleanClass',
selector: '[data-action-save]'
}
}
Both of those cases are the same character length as role=action-save. And you're probably going to have to replace the 'role' shortcut in that json with something else anyway which can get you to more terse selectors.
Actually after a little more thought... maybe data-action is what you want. The whole point of this part of a view is about attaching dynamic behavior of some kind to a DOM element. There's some way to act on the element in question. Action might be a more appropriate name than role was to begin with.
I've seen data-ui used for this purpose.
Also getUi() makes a lot of sense from JavaScript land.
A humble suggestion since it seems like data-* is the 'proper' way, and what we are doing is really using data-* as a selector, use data-select and the function selectByData (to coincide w/ the renaming of .get() to .select() which I also think is a good idea AmpersandJS/ampersand-view#18)
My concern with using an HTML attribute is that when I see role, name, and rel I will go to MDN or W3 to look up what it is and not Ampersand's documentation.
Seeing data-* I could still go to MDN or W3, but the documentation would still lead me to believe there is a convention being used by the programmer instead of leading me on a wild goose chase as to why the programmer is using weird role, name, or rel values.
data-*: 👍
name, rel, role: 👎
(Sorry, timezones mean I'm a bit late to this so some of this has already been covered but here's my thoughts.)
Whilst the role attribute is defined in the spec it doesn't prescribe how user agents should present them. This means a particular use of a particular role might be fine in some user agents but not in others (e.g. potentially a Braille reader could present the same role in a different way to an audio reader). Hopefully user agent support of roles will only increase so it's difficult to say that even if something works now it will still work in future.
The data attribute spec contains the following:
Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
These attributes are not intended for use by software that is independent of the site that uses the attributes.
My, admittedly superficial, reading of this issue suggests to me that you are using them to "store custom data private to the page or application" and this data is "not intended for use by software that is independent of the site that uses the attributes". Can't think of a more textbook use case :-)
If you want to be fully future friendly then you should also namespace your data attributes and this is specifically encouraged by the spec for "[a]uthors of libraries that are reused by many authors". This again sounds to me a lot like the situation here :-)
Okay, after flip-flopping on all of these for a couple of days in my head, I'm putting a strong +1 for data-hook="{whatever}" with getByHook and { hook: "{whatever}" } being the ampersand-view/dom-bindings shortcuts respectively. (We'd leave getByRole/role in there for backwards compatibility until it's deprecated though).
I also propose we change those shortcuts to use [data-hook~="{whatever}"] internally, which will still match <el data-hook="{whatever} other stuff" /> to allow for multiple hooks per element.
I also agree we should probably change it to select() and selectByHook has per AmpersandJS/ampersand-view#18.
I'd happily debate alternative names to hook, however, remember that an alternative has to be quite general. We use these on:
- things like buttons to specify the action the button should take when pressed:
<button data-hook="do-something"></button> - on elements to specify it's where a binding happens:
<h1 data-hook="title"></h1>along with{ bindings: { "model.title": { "hook": "title" } } } - on elements to specify it's where a subview will be rendered
<ul data-hook="list-items"></ul>
For me those various uses rule out, data-name, data-action, as they are too specific to cover the above use cases. I'm not particularly concerned about the fact hook has meaning for kernel developers, since this is software and everything means the same and different things by context.
As to why not rel: I think @getify's argument in favour of internal/external semantics is a great one. And I think rel is a reasonably elegant solution to this problem. If this was a one-off internal project I'd probably say "yep rel is good enough for me".
However, this is a "serious" open source project. To quote @decadecity from a conversation I had with him "[we] are asking people to trust [us] to make decisions for them, they should be able to see that you understand the consequences of that". Every time someone looks at/uses rel they're going to have to do mental backflips to understand why it's there; or they're going to have to explain to coworkers why ampersand is a good idea, even though the people who created it made this weird decision to use a random attribute when data- is there for just this purpose.
Yes data-hook is a few chars longer, however, with getByHook and { hook: '{whatever}' } shortcuts we've minimised the impact of that already. Even without being a slave to the spec, it's the correct solution.
If people really want to use rel or role or whatever there's literally nothing stopping them, we're just providing additional shortcuts and documentation to do something sane, consistent and "correct" (for whatever that's worth).
Hm, what about "data-ctx" and/or "data-context"?
After this whole debate, huge +1 for @latentflip with his whole explanation.
ctx is widely used when working with canvas, so it's not greatest choice imo. Plus context means slightly different thing in a whole js environment.
I read this entire thread thinking "Why not just use data-hook? @latentflip specifically said this was for JS hooks! Just use data-hook!" And then @latentflip suggested data-hook and I was like "Yay! Hooray for intuitive decisions!" and then everyone ignored it and I got sad. And now it's back! Hooray!
TL;DR: I like data-hook, and it's immediately obvious to me what it's for.
From thesaurus.com :)
data-aim
data-aspect
data-handle
...or simply 'data-role'
However, as long as it follows html5 all names are quite acceptable, imho. :)
As long as we're all bikeshedding: data-js. Doesn't get anymore obvious than that.
It's funny, I was contemplating this all last night and finally came to some peace about it in my head, philip's original data-hook suggestion just made sense to me. But, I kept seeing notifications about comments on this issue then was happy to discover @latentflip had reached the same conclusion.
data-hook is it, decision made.
Plus we'll make the change to support multiple space-separated hooks per element as @latentflip described.
data-js or data-ctx would be fine if that's all it were used for, but those are not as great when used in function form: getByCtx or getByJs.
I like rel, but it would be the first thing we do that arguably violates HTML5 spec, so I don't want to do that.
I'm not entirely sure on selectByHook as the alternative for the named method, i think simply doing queryByHook might be better, but I'll add those thoughts over on that issue: AmpersandJS/ampersand-view#18
Thanks everyone for your input.
This thread is amazing. Thoughtful conversation, useful information, and no trolls. That's a rarity.
Zeke wrote:
This thread is amazing. Thoughtful conversation, useful information, and no trolls. That's a rarity.
Amen to that.
I wanted to +1 the data-* approach and point out a few more features of DOM and CSS that might make it even more attractive:
HTMLElement.dataset API
el.setAttribute("data-js", "foo");
console.log(el.dataset.js); // "foo"
el.dataset.js = "bar";
console.log(el.getAttribute("data-js")); // "bar"YMMV wrt cross-browser support.
More complex CSS attribute selectors.
As latentflip mentioned above, [att~=val] will match space-separated tokens. E.g. [data-js~="bar"] will select data-js="foo bar baz" or data-js="bar" but not data-js="bark" The attribute substring selector [data-js*=bar] will match all three.
Another interesting one is [att|=val]. E.g. [lang|=en] matches lang="en" or lang="en-us" but not lang="eng"… This selector is intended for language codes but could be overloaded pretty easily. (You may also be able to achieve this with [lang=en], [lang^="en-"]...) The thought here is that you could a data-js="type-subtype" pattern and rely on selectors that could provide an unambiguous match across what is effectively a superclass value: [data-js|=myclass] would match both data-js="myclass" and data-js="myclass-mysubclass"
Closing this \o/ thanks everyone.