Decide about the future of microformats on fsfe.org #1389

New Issue

reinhard · 2020-05-15T08:31:06Z

reinhard commented

2020-05-15 08:31:06 +00:00

Currently, some pages use h-entry microformats, but in a very inconsistent way, and I've got the feeling that most website authors don't really understand or care about the concept, but rather copy and paste from some random other page. I'm not sure the way h-entry is used by us currently is effective in any way.

I propose that we either set tangible rules about how and for what we use h-entry, or we ditch it altogether.

Currently, some pages use h-entry microformats, but in a very inconsistent way, and I've got the feeling that most website authors don't really understand or care about the concept, but rather copy and paste from some random other page. I'm not sure the way h-entry is used by us currently is effective in any way. I propose that we either set tangible rules about how and for what we use h-entry, or we ditch it altogether.

reinhard commented

2020-05-15 09:33:34 +00:00

Actually I think there is a third possibility: We remove all manually set microformat classes, but define rules for adding these microformats in the build process based on the semantics we already have, just like currently for example "p-author" is set autoamtically in fsfe_headings.xsl.

max.mehl commented

2020-05-15 11:45:43 +00:00

The second and third option sounds fine for me, depending on how much work you would like to invest into tangling microformats into the build script

reinhard commented

2020-05-16 11:21:01 +00:00

The work I'd like to invest mostly depends on the real benefits we have from having these microformats at all. So I'd ask for as much input as possible from anybody who has experience with this.

reinhard commented

2020-05-16 11:21:35 +00:00

@hugo I'd like to direct your attendance to this discussion.

reinhard commented

2020-05-27 15:11:22 +00:00

I now asked for further input on the mailing list.

paul commented

2020-05-27 16:20:59 +00:00

I think those additions are only any good, if they are getting used for anything specific. Any development should focus on a use case.

I.e. can your microformats...

provide a canonical way for tagging and topical linking? E.g. in place of the current include mechanics.
be used for page aggreagation, e.g. "all pages by a specific author"?
be used in external services of FSFE, e.g. calendars, blog aggregators, nextcloud file tagging, translator UI, git access control, etc. etc...
be used for technical services, e.g. a customised site search

They are not useful

for anything you expect the browser to do with them, because in reality browsers will not do anything with them, and if they do users wont know because the behaviour is unreliable across different versions anyway
for internet search engines, because you cannot make meaningful predictions about how they are used there
for anything you expect desktop/mobile/whatever applications to do, unless you have a specific use case in mind, in which case you should focus on the use case, not the format

Take a vcard/hcard file for example. Can you import it into your android address book right away? Can you sync it with Nextcloud from where it is included? Can you click it to make a phone call right away? This could be awesome! If on the other hand it is included in a way, where this does not happen, it is dead weight.

If in doubt, it is better to increase your options by removing clutter from the code, so you have a better chance of implementing features, you do want. If you find later that you could have used some microformat, it is easyer to reimplment it, once you know what it will be used for, and how to test if it is working.

Also, if some botched non-standard provides your use case, while the "official" version does not, use the working convention. We already do this with the 'apple-touch-icon' header. It often turns out, the easyer convention is more friendly towards Free Software, than some overengineered corporate standard.

I think those additions are only any good, if they are getting used for anything specific. Any development should focus on a use case. I.e. can your microformats... - provide a canonical way for tagging and topical linking? E.g. in place of the current include mechanics. - be used for page aggreagation, e.g. "all pages by a specific author"? - be used in external services _of FSFE_, e.g. calendars, blog aggregators, nextcloud file tagging, translator UI, git access control, etc. etc... - be used for technical services, e.g. a customised site search They are _not_ useful - for anything you expect the browser to do with them, because in reality browsers will not do anything with them, and if they do users wont know because the behaviour is unreliable across different versions anyway - for internet search engines, because you cannot make meaningful predictions about how they are used there - for anything you expect desktop/mobile/whatever applications to do, _unless_ you have a specific use case in mind, in which case you should focus on the use case, not the format Take a vcard/hcard file for example. Can you import it into your android address book right away? Can you sync it with Nextcloud *from where it is included*? Can you click it to make a phone call right away? This could be awesome! If on the other hand it is included in a way, where this does not happen, it is dead weight. If in doubt, it is better to increase your options by _removing_ clutter from the code, so you have a better chance of implementing features, you _do_ want. If you find later that you could have used some microformat, it is _easyer_ to reimplment it, once you know what it will be used for, and how to test if it is working. Also, if some botched non-standard provides your use case, while the "official" version does not, use the working convention. We already do this with the 'apple-touch-icon' header. It often turns out, the easyer convention is more friendly towards Free Software, than some overengineered corporate standard.

paul commented

2020-05-27 16:37:47 +00:00

Despite this pragmatism, I am all for open standards. If some feature that is currently provided in a custom way, could be provided using standardised formats instead, then a switch can easily open up additional opportunities.

Despite this pragmatism, I am all for open standards. If some feature that is currently provided in a custom way, _could_ be provided using standardised formats instead, then a switch can easily open up additional opportunities.

Sign in to join this conversation.

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: FSFE/fsfe-website#1389