Infrastructure for links to specification

[Raynos]

As per #108 it would be nice to be able to add links to specifications and references like the MDN.

It'd be better if we added this to the markdown files and then add some CSS hooks in the template to make this styled consistently.

Currently this just adds the links belong the textual context without any styling.

As an aside do we want to favour links to W3C HTML5 or WHATWG HTML? (I favour WHATWG).

[nimbupani]

We have a meta tag called moreurl that you can set on each markdown post to indicate more info. See http://html5please.us/#exclusions where we link to 'learn more'.

Initially I had linked the name itself for that, but @paulirish said it was not good-looking, and we moved it there. Also we link to caniuse.com too but call it view browser % share but I feel like it should just be called Learn more.

[Raynos]

@nimbupani I saw that you already have moreurl.

The issue here is that it allows only one link. What if we want to link to both the MDN reference and the W3C/WHATWG specification. I think both of those are valid references.

It also appears that moreurl doubles as both a learn more and a caniuse url. Basically if it's not present it renders the caniuse url and if moreurl is present it overwrite the caniuse url.

I don't think this is generic enough to link to references, having three links (W3C, MDN, caniuse) would be useful.

[nimbupani]

I would rather people choose to read more on caniuse.com than just on html5please. It has more data plus tests.

[Raynos]

That's a valid non-duplication of effort. In that case we want to make sure all the caniuse links work.

[nimbupani]

Agreed, I had created #27 for this reason.

[paulirish]

I think caniuse links are important for all items, as long as we can have them..

still... learning more about a specific feature is useful. And I'd rather just see the most useful resource for each feature than standardizing on a destination. (like css-tricks probably is this for a number)

so

yeah i'm +1 on this. i like the implementation too

[paulirish]

cc @err0

talking to divya about this i think we dont need to make this a new data field.. let's just add it inline in the prose when the feature could use it.. i agree datalist could.

so..

<datalist> enables autocomplete combo boxes...

and

Server-Sent Events are real-time events emitted by the server and received by the browser.

.. this way its less formal and we dont have superfluous link maintenance.. just adding extra links for features when it makes sense.

linking to specs might not always make sense and MDN articles might not be present so its best to leave this flexible and conversational.

dig?

[Raynos]

@paulirish still opens the question as to whether we want to go and add specification links for every feature we can?

I just thought that having a single location for every item which links to the specification like we have the single caniuse link location would be useful.

[nimbupani]

@Raynos I think it is better to not do that, and explain it in context. We already have caniuse.com links for specific details on each feature.

[Raynos]

In that case we'll just make sure the caniuse works and that specific entries have specific links where needed.

[err0]

It's a "how to use" question. Caniuse does not provide this. I think a consistent location for "how to use" is useful vs. reading through the content and clicking links hoping to find the spec. Some content such as audio and border-image already have links.

[paulirish]

The spec rarely teaches "how to use" so if that's the aim, I don't think
spec-linking helps.

As I said, I'm good with links to more info, when its appropriate.. Just
don't think I need to do it for border-radius the same as WebRTC..

[err0]

Consistent location and style is really what I am pushing for. What you did here with the subject linked as the first word in the content was great.

[paulirish]

Yup. I think that's the best way forward.