8000 consider incorporating metaformats into core mf2 parsing spec · Issue #73 · microformats/microformats2-parsing · GitHub
[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

consider incorporating metaformats into core mf2 parsing spec #73

Open
snarfed opened this issue Nov 28, 2023 · 2 comments
Open

consider incorporating metaformats into core mf2 parsing spec #73

snarfed opened this issue Nov 28, 2023 · 2 comments

Comments

@snarfed
Copy link
Member
snarfed commented Nov 28, 2023

Should we? Or not? I have no clue, deferring to people who understand standards and mf2 parsing better.

https://microformats.org/wiki/metaformats

At least two implementations so far:

Earlier related projects:

cc @tantek @aciccarello @kevinmarks @barnabywalters @jackyalcine @capjamesg
@snarfed snarfed mentioned this issue Nov 28, 2023
Open
@aciccarello
Copy link

I think the spec needs to be refined some more at a minimum before considering incorporating it into the core spec. With the challenge of different sites using meta tags inconsistently, we'll probably need to do more experimentation to find a good balance of correctness and usability.

Other thoughts:

  • I haven't contributed much to specs before so I can't speak to the work of managing standards
  • My use case for metaformats revolves mostly around link previews so keeping it as a separate fallback feels reasonable to me.
  • I suspect some real-world applications might need some additional translation to better handle some one-off patterns on larger sites but that's probably outside of even the metaformats spec.

@sknebel
Copy link
Member
sknebel commented Nov 29, 2023

agreed with @aciccarello , it needs more refinement, practical testing and checks that adding it won't interfere with existing uses before we should consider adding it to the main spec, if at all. Personally, I think it makes a lot of sense for it to stay separate entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@snarfed @sknebel @aciccarello
0