| 18:19 | <Michael Ficarra> | I've started working on documenting our editorial conventions: https://github.com/tc39/ecma262/wiki/Editorial-Conventions |
| 18:19 | <Michael Ficarra> | I'd like to reserve some time to talk about it at tomorrow's editor call |
| 18:59 | <bakkot> | Probably don't need to worry about documenting things ecmarkup enforces? |
| 19:02 | <Michael Ficarra> | I think it's a mix |
| 19:02 | <Michael Ficarra> | some things are still good to know because they get our editorial philosophy across better |
| 19:03 | <Michael Ficarra> | certainly some things are not worth occupying your brain until/unless you make that mistake and ecmarkup fixes it for you |
| 19:06 | <bakkot> | I'm thinking specifically "denote all characters literally, using HTML entities only as required by HTML syntax" |
| 19:06 | <bakkot> | and someday the list/record spacing though right now ecmarkup doesn't handle those as well as I'd like |
| 19:08 | <bakkot> | (specifically: spacing is handled by the formatter, whereas the more advanced parser capable of recognizing lists/records is only used for linting. the more advanced parser skips <del> and inlines <ins>, because that's how you want the linter to work, but that means it's unsuitable for formatting. I just need to update it to retain that information somewhere that the linter will ignore it.) |
| 20:08 | <Michael Ficarra> | I'm happy to draw the line a bit different, but I'm sure there are going to be things that are checked by ecmarkup that we'll still want to communicate |