The problem with supporting HTML is not with users who use the facility’s within a desktop program to add bolding (et el) but when transferring a GEDCOM as input to an online program where that programs is to expected to use the html and some bad actor have created their own GEDCOM with imbedded html. I am not aware of any that support Markdown in imported or exported GEDCOM files. Some only support bold, italic, underscore and super/subscripts, but others support much more. In my experience, there are already many genealogy products that to some extent support HTML in GEDCOM text fields. So the underlying GEDCOM coding is largely irrelevant to users and mostly impacts developers. In the same way as users would not usually directly edit the GEDCOM file but use a genealogy application. So HTML has better standardization and supports more features.Īnyway, users would not usually expect to edit in either Markdown or HTML codes, but via a word-processing style editor. Those are only in Markdown Extra that is not so widely supported. Markdown does not support all of the features you mention such as tables nor such as footnotes and abbreviations. suggests there is limited standardization across implementations and the examples include URL links that you claim are a bad idea. I'm not sure I understand the advantage of Markdown over HTML bearing in mind that GEDCOM is a communication format for transferring genealogy data from application to application.
0 kommentar(er)
