Observable mechanics not quite correct...

[adrianhopebailie]

From web-monetization created by marcoscaceres: adrianhopebailie/web-monetization#16

@marcoscaceres wrote:

The spec talks about observing the head for inclusions of the particular meta tag... we probably need to rewrite all this to align more with how the HTML parser works.

There are also conflicting requirements.... like it says, "there MUST only be 1 meta tag", but it doesn't say what happens if there are two or more. Which one wins? Is the whole thing invalid? We should clarify that a bit more.

[adrianhopebailie]

@sublimator wrote:

While we are on the subject, the concept of a Tags Set is quite awkward, cause you have to be careful in the ordering of removing/inserting tags. Besides, currently there's only one tag, which describes the recipient paymentPointer ...

Maybe one tag with key/vals encoded would be nicer ?

[adrianhopebailie]

it doesn't say what happens if there are two or more

At least with the current implementation, we throw an error when more than one detected.

We instead need to write all this as a parsing algorithm.

Do you have a link to an example of what you mean by that ?

[adrianhopebailie]

Good points. I'm not averse to it being a link element rather than meta, especially if that means the parsing used by manifest and how CSS deals with stylesheets being dynamically added/removed can be re-used. With a browser-vendor hat on, anything that allows re-use of code (or at least, doesn't require another mental model) lowers the barrier to adoption.

[adrianhopebailie]

Also other things... like demanding the tags only be in the head for some reason? But the reason is not given.

[adrianhopebailie]

Just following up... generally, we want to avoid dictating things in the spec, like:

The <meta> Tags Set MUST be in the head of the document.

We instead need to write all this as a parsing algorithm. We can look at how Web Manifest deals with finding <link rel=manifest> or how CSS deals with stylesheets being dynamically added/removed.

[adrianhopebailie]

At least with the current implementation, we throw an error when more than one detected.

Not sure what throwing an error means in this context? Like a JS error at the global object?

Do you have a link to an example of what you mean by that ?

Ok, this is an extreme example... sorta, but we basically need to hook into:
https://html.spec.whatwg.org/#parsing

And getting more specific, here is how we would hook into processing/fetching the particular link relationship:
https://html.spec.whatwg.org/#fetching-and-processing-a-resource-from-a-link-element

(if we go down the <link> route)

Similarly with meta if we stick with that. We would need to deep dive into all that to figure out where to hook into the HTML parser to process these elements correctly.

[adrianhopebailie]

Actually, while I was tracking down some info for #23 I found out that initially @sharafian proposed one tag with a query string encoding key/vals.

[adrianhopebailie]

Not sure what throwing an error means in this context?

Doesn’t mean much more than only one stream at a time will be active. Any
more than one will fail with an unhandled error in the MutationObserver
callback, logged to the console.

[adrianhopebailie]

Awesome, thanks the info :)

[adrianhopebailie]

Depends on #19

[sublimator]

Was going to edit these comments and put in the original authors but it seems it is sending email notifications ...