- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 16 Oct 2013 14:47:21 +0200
- To: "Michael[tm] Smith" <mike@w3.org>
- CC: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>
Am 16.10.13 14:38, schrieb Michael[tm] Smith: > Silvia Pfeiffer <silviapfeiffer1@gmail.com>, 2013-10-16 22:07 +1100: > >> On Wed, Oct 16, 2013 at 7:54 PM, Michael[tm] Smith <mike@w3.org> wrote: >>> If that's the case, then I think the library developers are doing a >>> disservice to their users. I'd think they at least could provide something >>> like https://developers.google.com/+/web/+1button/#plusone-tag-attributes >> That's what I call "documentation", but not a standard. :-) > Well I guess the word "standard" in the context we normally use it for > Web-platform technologies normally only applies to stuff that's implemented > natively in browsers. So you can't really have a standard for a particular JS > library anyway. But you can have really good user documentation for it. And > to me, good documentation beats a bad standard any day of the week anyway. > >>> The only real benefit of data-* I've ever been able to see is the >>> convenience of the dataset property. But IMHO that doesn't seem worth quite >>> as much weighed against the side effect of (A) libraries adopting data-* >>> for non-private use, with data- prefixed names that end up becoming sort of >>> de facto standard attribute names with well-defined microsyntax/ datatypes >>> while (B) the spec says that there are no invalid values for data-*. That >>> situation is not helpful to Web authors. >> But it's ok - a parser just has to accept that the data-* attributes >> are valid, it doesn't have to ascertain that the value is valid. > It's imaginable that there could be applications other than just parsers > and your own library that you might want to have do checking of the values > of your custom attributes. > >> So, in your opinion, should we change >> http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes >> to only apply to private attributes, >> >> and add to >> http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#extensibility >> the suggestion to use a custom prefix xxx-* for libraries? > I think it'd be helpful to hear from more people who think it's preferable > for libraries to expose custom attributes as data-xxx-foo instead of as > xxx-foo, and what the rationale is. > > But my own opinion as somebody who's trying to provide authors with good > ways to catch authoring mistakes in attribute values is that for attributes > that authors are likely to make mistakes with, we're better off providing > them with attribute names that don't start with the data- prefix and that > therefore aren't part of the everybody-else-ignore-these-attributes > contract that the data- prefix comes with. +1 - Felix
Received on Wednesday, 16 October 2013 12:48:03 UTC