search

microformats / h-entry

For collecting and handling issues with the h-entry vocabulary specification: http://microformats.org/wiki/h-entry
17 stars 5 forks source link

Proposed - Allow for the h-geo properties to be added to an h-entry #29

Open dshanske opened 2 years ago

dshanske commented 2 years ago

This encompasses the proposed properties for h-entry of p-latitude and p-longitude, and probably covers p-altitude on this basis even though this was not proposed.

The reason for allowing these, as opposed to p-location as an embedded h-geo, would be in cases where nested microformats are not preferable, and a simplified structure preferred.

So, these would represent the location of the h-entry in coordinates, which could alternatively be represented as a nested p-location. In this case, a p-location could still be present representing a textual version of a location name.

dshanske commented 2 years ago

Related https://github.com/indieweb/microsub/issues/45

sknebel commented 2 years ago

would be in cases where nested microformats are not preferable, and a simplified structure preferred.

What are those cases?

dshanske commented 2 years ago

For one, Micropub and Microsub, which use simplified mf2 vocabulary.

sknebel commented 2 years ago

I don't see where microsub has an issue with nested formats? For micropub, I personally don't think adding more variants and special cases to mf2 just to extend support for the form-encoded variant is positive for effort overall, and the JSON form again does not have problems with nested formats.

dshanske commented 2 years ago

@sknebel Microsub tries to go for a simplified representation. But, point taken there.

Added this based on these properties being on the proposed list. Will leave this open for commentary. Maybe the solution is the proposal is rejected.

sknebel commented 2 years ago

sure, not complaining that you made the issue - to the contrary, thanks for doing the bookkeeping :)

Maybe to phrase my objection more generally: My concern is that this adds another variation of how things can be marked up, that most consumers will normalize in some fashion anyways (e.g. to generate jf2, or post markup, or ...) and that then all consumers need to handle, while I don't see a real benefit for publishers over the existing markup for location - it doesn't add anything we can't already express.