Clarification which of the link types in the Microformats 'existing-rel-values' page are valid

unor commented 8 years ago

Extensions to the predefined set of link types may be registered in the microformats wiki existing-rel-values page. [MFREL]

The anchor text says page, but the link points to the #HTML5_link_type_extensions section on that page.

I assume that for HTML 5.1 the link types have to be defined in the linked section with the id HTML5_link_type_extensions, not in some other section on that page, right? Or is it that the place on that page doesn’t matter as long as the required information (Keyword, Effect on... link, etc.) is specified?

If it has to be that section, I think it would make sense to refer to it explicitly, e.g.

[…] in the HTML5 link type extensions section of the microformats wiki existing-rel-values page

or something like that.

Furthermore, should it keep being named "HTML5", given that WHATWG HTML, W3C HTML5, and W3C HTML 5.1 refer to it?

As a follow-up, I wanted to ask if it would be possible to refer to a page in the wiki that only contains link types that can be used in HTML/HTML5/HTML 5.1, because I think the current page is not very user friendly:

When doing an in-page search (Ctrl+f) for a keyword, it’s easy to land in a different section and to miss that it doesn’t apply to HTML 5.1.
The edit history can’t be filtered to only show edits in that section only. So there is noise if reviewing edits (also when subscribing to the edit feed), or when trying to find out when something specific happened, etc.

(For backwards compatibility: in MediaWiki, the current page could stay like it is and automatically include the table from the new/separate page.)

chaals commented 8 years ago

It seems like it was nice to have a wiki so people could easily propose things, but it is not a helpful way to tell people what they should expect to be useful. If we manage a rhythm of publication about every year or so, it seems we could usefully define all the accepted useful values in the spec directly.

TzviyaSiegman commented 8 years ago

Note also that @rel is not mapped to Accessibility APIs and the effect of the generated triples on RDFa processors is unclear (at best), Before @chaals pointed me to this issue, I logged a similar one https://discourse.wicg.io/t/rel-cleanup-in-multiple-locations/1426

jribbens commented 8 years ago

Since this #213 has been merged into this one: it is my view that having the official list of valid values as random content on some wiki page is not at all acceptable. Forcing conformance-checking tools to attempt to scrape an arbitrarily-formatted (non-computer-parseable) and fragile (publicly editable) wiki page to try and guess at the list of valid values is dubious at best.

chaals commented 8 years ago

having the official list of valid values as random content on some wiki page is not at all acceptable

Agreed. It seems not to have worked well, and I propose that we put the list into the HTML spec, and update it as relevant.

a3nm commented 8 years ago

I think there are two reasonable solutions. The first is to fix a list of allowed values in the spec, and update it regularly from the wiki. The second is to say in the spec that any value is valid, and non-normatively say that users are invited to go to the wiki to find common values and register their own values (i.e., the spec does not attempt to keep track of the possible values).

chaals commented 8 years ago

I think it makes sense to follow a hybrid of @a3nm's proposals above:

fix a list of allowed values in the spec, and update it regularly from the wiki

but instead of allowed values, talk about values whose meaning is formally defined, and

say in the spec that any value is valid, and non-normatively say that users are invited to go to the wiki to find common values and register their own values

essentially allowing for experimentation.

a3nm commented 8 years ago

@chaals's idea sounds good, but the standard needs to be precise about whether attribute values that are not listed in the standard are valid, or whether they are invalid, i.e., they can be rejected by conformance checkers.

chaals commented 8 years ago

Yes, my proposal is that any value should be accepted by a conformance checker - perhaps with a warning that its meaning has not been standardised, and may be overridden by a future version of HTML...

halindrome commented 8 years ago

Conformance checkers should absolutely accept any value for the rel attribute. And, oh by the way, for the role attribute. Same problem.

LJWatson commented 7 years ago

@unor is right in saying the existing rel values page is not user friendly!

If someone can tell me which table(s) we want to pull data from (Formats, HTML link type extensions, other), and a sensible way of identifying which rel values in the table(s) need extracting, that would be helpful.

LJWatson commented 7 years ago

It seems its the values from the HTML5 link type extensions table that is our source. What then are the criteria for including any of these in the HTML spec?

TzviyaSiegman commented 7 years ago

It would be most helpful to clarify which terms are deprecated (put the word "deprecated next to them"?) and provide clearer definitions that reflect the broader community. For example, "publisher" is currently defined within the context of social media. "footnote" was dropped, but this would be valuable in the world of long-form and scholarly publishing.
It would be helpful if the spec and microformats wiki clarified the relationship to IANA registry. If it's just a matter of media-type, it would be helpful to clarify some language. There is a lot of confusion.

BigBlueHat commented 7 years ago

I've done a bit of digging to help clarify the past, present, and future: https://github.com/BigBlueHat/relify/wiki

My intent is to publish this in some more sensible format, but for now, this hopefully paints a complete(ish) picture of how we got to here. :smile:

The IANA Registry is by far the most widely trusted registry among other Hypermedia API formats that depend on link relationships. The Atom syndication format was also updated via RFC5988 to reference the IANA registry.

Additionally, HTML 1.1 mentions using IANA as the registration authority for "Relationship names for link and anchor elements. RFC5988 created that registry, which is in active use.

Lastly, RDFa defines rel as supporting CURIEs and IRIs as an extension mechanism. HTML5 still doesn't express the use of IRI's as values for rel and rev (though rev was brought back for use with RDFa enabled HTML5 documents).

Ideally, HTML5.2 would:

choose the IANA registry for link relationships--or provide a W3C comparable replacement with adequate governance, process, and provenance expression
improve the definition of rel and rev values to provide IRIs as the recommended preregistration extension mechanisms
registry any HTML5 defined link relationships with the IANA registry

Thanks! 🎩

siusin commented 5 years ago

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.

w3c / html

Clarification which of the link types in the Microformats 'existing-rel-values' page are valid #160