Tipsy <link> not HTML5 valid

[ghost]

Hello,

Using Typsy link in webpage's head generate 2 errors :

• Attribute name not allowed on element link at this point.
• Element link is missing required attribute href.

If I use attribute title instead name, Tipsy plugin don't detect link.

Also, if I use on existing link rel="author" (with both attributes title and name or not) Tipsy plugin don't detect it…

[da2x]

The link element is indeed not the correct element to use for thus purpose. Correct markup should be:

<meta content="Donald Duck"
      data-paypal="d.duck@duckburg.email"
      name="author">

[tbranyen]

I like that approach @da2x we can support both the invalid <link /> and a more semantic <meta />

[tbranyen]

I would advocate publishers go for the <meta /> approach and we should only document that going forward.

[da2x]

Unless you’re aware of massive adoption (…) then just drop support for the link element. No need to slow down every single page load for all eternity to support this given the current level of adoption*.

* assuming it’s low, which I suspect.

[tbranyen]

My vote is to keep backwards compatibility, even if that only means a handful of sites. I'm fine going with just <meta /> if @karger is in agreement.

[da2x]

Pull request for site documentation + generator as well as the extension coming up (I’ve been poking around in this area of the code tonight, so shouldn’t take more than a few minutes).

[karger]

I agree that we should move to meta and should change the documentation reflect that. But I also think having the 2 lines of code needed to support doesn't hurt anything. We can remove it from the documentation so no new ones are created, and can remove it from the code in a few years once tipsy is the main payment standard---at that point the few people relying on it will notice and fix if their site stops working.

[da2x]

Here is the implementation I’ll be going with: Authors will be selected first, if that is unavailable try selecting the publisher, and lastly look for the legacy tag.

meta[name=author] || meta[name=publisher] || link[rel=author] || /tipsy.txt

I’ll leave this here to allow for objections, and will submit pull requests for generator+docs and the extension and WP plugin in a day or two.

Update: Actually, I’ll wait for more stuff to be merged in tipsy and tipsy-site to avoid stepping into conflicts with my other pull requests.

[tbranyen]

@da2x I can help rebase anything that gets conflicted btw, so please don't hesitate to open PRs.

Edit: You'll have to add me as a contributor to your fork in order for me to force push any conflict resolutions / additional commits

[da2x]

@tbranyen (I’m trying to incentivise those of you with commit access to merge my stuff.) Plus, I need some sleep now; and wanted to give people an opportunity to come with suggestions before I did the work.

[ghost]

Add meta support, deprecate the link and remove it in 2 years…

[da2x]

This was changed quite a bit on 2017-02-18 06:00 from the original proposal.

OK, so data-* can’t be used for this purpose.

“These attributes are not intended for use by software that is independent of the site that uses the attributes.” “User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.”

There isn’t another property in HTML that is suitable for custom data, and this can’t be expressed with the current mechanism. Luckily, the HTML+RDFa extension is quite suitable. However, that would create messy parsing and a require increased document complexityand thus add development requirement for publishers.

As a shortcut, which is also the one preferred by Google, is using JSON-LD. Publishers copy and paste a JSON blob of semantic metadata anywhere into their documents.

There is currently no way to express a volunteer supporter/patreon payment vocabulary. WebPayments draft looks promising, but isn’t suitable for describing general information about available payment methods and the payee’s account information as per Tipsy’s purposes. The current common vocabularies simply haven’t defined the things or relations used in Tipsy.

A vocabulary extension is needed: SupporterPayment (a potentialAction), destination (payee’s identifier/account with the given PaymentMethod), Dwolla (a PaymentMethod), and Bitcoin (a PaymentMethod). These are to be defined in http://tipsy.csail.mit.edu/vocab#.

[Semantic] overview: A Website offer the User-Agent a potentialAction of giving a SupporterPayment. acceptedPaymentMethod for this action are can be one or array of PaymentMethod. destination for the PaymentMethod is the payee’s account identifier (email, token, address).

Websites would insert this blob (in expanded format):

<script type="application/ld+json">
  { 
    "@context": "http://schema.org",
    "@type": "WebSite",
    "potentialAction": {
      "@context": {
        "@vocab": "http://tipsy.csail.mit.edu/vocab#"
      },
      "@type":  "SupporterPayment",
      "acceptedPaymentMethod": [
        {
          "@type": "PaymentMethod",
          "url": "http://purl.org/goodrelations/v1#PayPal",
          "destination": "merchantidoremail"
        },
        {
          "@type": "PaymentMethod",
          "url": "http://tipsy.csail.mit.edu/vocab#Dwolla",
          "destination": "hashstringstringhash"
        },
        {
          "@type": "PaymentMethod",
          "url": "http://tipsy.csail.mit.edu/vocab#Bitcoin",
          "destination": "walletaddress"
  } ] } }
</script>

or alternatively in compacted format:

<script type="application/ld+json">
  {
    "@type": "http://schema.org/WebSite",
    "http://schema.org/potentialAction": {
      "@type": "http://tipsy.csail.mit.edu/vocab#SupporterPayment",
      "http://schema.org/acceptedPaymentMethod": [
        {
          "@type": "http://schema.org/PaymentMethod",
          "http://schema.org/url": {
            "@id": "http://purl.org/goodrelations/v1#PayPal"
          },
          "http://tipsy.csail.mit.edu/vocab#destination": "merchantidoremail"
        }, {
          "@type": "http://schema.org/PaymentMethod",
          "http://schema.org/url": {
            "@id": "http://tipsy.csail.mit.edu/vocab#Dwolla"
          },
          "http://tipsy.csail.mit.edu/vocab#destination": "hashstringstringhash"
        }, {
          "@type": "http://schema.org/PaymentMethod",
          "http://schema.org/url": {
            "@id": "http://tipsy.csail.mit.edu/vocab#Bitcoin"
          },
          "http://tipsy.csail.mit.edu/vocab#destination": "walletaddress"
  } ] } }
</script>

So, not as sexy as a single HTML tag, but there is currently no mechanism in HTML that allows extending it in a “sexy” fashion. RDFa is the preferred way to express invisible metadata, it’s extensible to fit Tipsy’s needs, and it can be expressed as a copy-and-paste drop-in blob for publishers.

This doesn’t express the name of the author or publisher. This can either be derived from the meta tags, or by reading the publisher or author data out of JSON-LD (which is very much recommended by Google these days anyway). HOWEVER, seeming as there is no method for expressing the author/publisher in the /tipsy.txt format, which is strongly preferred by publishers, I’d say this be dropped from the in-document mechanism as well. Unless there is a very strong use-case for expressing per-author payments rather than per-publisher/website (or per-page/URL subfolder as expressed in /tipsy.txt). No current publisher uses anything but "_" (whole-domain) structure, by the by.

Rewriting the generator is like 15 minutes work. The WordPress extension could be done in another 15 minutes, but the extension would probably take me 50 minutes. 10 extra minutes to also support compacted format, although I believe if we only document and generate expanded JSON-LD, than this ought to be enough. I’m just a tad worried that some "page optimizer" somewhere with try to compact the JSON blob to be clever. Add another hour for documentation.

Alternatively, Tipsy could just drop a JSON blob in the window object and be done with it. This requires JavaScript execution on every page load for Tipsy users and non-tipsy users alike — something JSON-LD doesn’t (user-agents ignore the non-default script type!). JSON-LD is thus the better option for the web ecosystem as a whole as it doesn’t degrade website execution performance nor litter the global window object.

<script>
  window.tipsyPaymentOptions = window.tipsyPaymentOptions ||
    [
      { "paypal": "donald.duck@email.duckburg" },
      {"bitcoin": "3bafbaf" } ];
</script>

Thoughts?

[tbranyen]

What about a custom element?

<tipsy-payment style="display: none" paypal="some@email.org" />

Valid HTML5 doc:

<!doctype html>
<html lang="en">
  <head>
    <title>Test</title>
  </head>

  <body>
    <tipsy-payment style="display: none" paypal="some@email.org"></tipsy-payment>
  </body>
</html>

[da2x]

[I’ve updated the above JSON-LD proposal to re-use more of existing schemas.]

What about a custom element?

Not a W3C recommendation yet, just in draft state. If I remember correctly, then CSS isn’t applied to unknown [a.ka. custom] elements in older browsers. Introducing such an element could mess up people’s layouts by introducing a block element in unexpected places.

I’m only slightly more in favor of JSON-LD because it potentially makes the payment information available to more user-agents than just Tipsy. Others are less likely to implement and recommend something with a prominent vendor prefix.

I have no strong objections for going with either solutions, though I have a [potentially irrational] feeling that the approach intended for including invisible semantic metadata soups may be _better for the web._

[karger]

So I generally favor adherence to standards but I'm even more strongly in favor of ease of use for the target population and, equally important, not scaring them away with big messy syntax. Even if it's automatically generated, it will be a problem if they have to see it. So, for example, I think it would be fine for the wordpress plugin, which embeds the payment info without the author seeing it, to generate json. But I don't think it's a good idea to ask people manually editing their pages to add script tags and mysterious json.

Presumably, most of the novices will just go with the tipsy.txt file, so they won't be impacted. But I'd like something tolerable for the remaining novices. If we have to break standards to do that, I'd advocate that we do. If we are going to break standards, then doing so in a way that still parses/validates seems preferable. So, e.g., using the data- attribute in a meta tag may violate the semantics* of data tags, but it is perfectly valid syntax. So I'd lean towards something like that.

I don't know enough about the relative adoption/understanding of link vs meta tags to have a strong sense of which will seem more natural/appealing to novices---but that's what I'd base the choice on.

[da2x]

I’ve done some testing, and custom elements will cause all sorts of problems with various libraries and HTML processors. No go until support improves. JSON-LD is the correct option, but data-* is the best option.

How about this?

<meta content="Daily Drivel"
      data-payablewith-paypal="merchantidoremail"
      name="publisher">
<meta content="Donald Duck"
      data-payablewith-bitcoin="3bafbaf"
      name="author">

[tbranyen]

@da2x I like the <meta/> tag better than the alternatives. :+1:

[ghost]

Like the meta too.

Why not add a trick to hide email address in data-* (like replacing @ by something else), for limit abuses by bad crawlers ? ;)

[da2x]

Why not add a trick to hide email address in data-* (like replacing @ by something else), for limit abuses by bad crawlers ? ;)

You’re not supposed to use email addresses anyway. Merchant IDs (required to receive payments via buttons) take the place of email addresses.

[ghost]

But you use merchantidORemail, so Murphy use email. :p

[tbranyen]

This probably won't matter much for a majority of users. Wikipedia splatters their payment email address everywhere on their site, which is incredibly easy to crawl. For the most part I see email addresses listed as ones that are for payments only. Otherwise if you start getting spam, remove it in favor of a merchant id per what @da2x says. I don't think we should enforce either. /2cents

[ghost]

Bon.

tltr : apply the Murphy's Law > force merchantID or hide email

Beaucoup d'utilisateurs d'internet n'ont pas grande connaissance de ces subtilités, utilisent une seule adresse email pour tout, y compris Paypal pour payer ou recevoir de l'argent.

Si vous voulez que Tipsy soit un outils qui se démocratise rapidement, soit proposé dans les principaux CMS et donc potentiellement utilisé par des bloggeurs rompus à ces pratiques ou complètement amateurs, vous devez considérer que Mr Jean (un noob) utilise son adresse email principale si on lui propose un champ correspondant, et ne se rendra probablement jamais compte que les spams qu'il recevra ensuite soient dû à sa mauvaise utilisation.

C'est pour ça que je pense qu'il faudrait soit forcer l'utilisation du merchantID, soit empêcher que l'adresse email puisse être récupéré.

Sorry for my lack of vocabulary. ><