Publishing Maintenance Working Group Telco

Annotations - adding Markdown as an annotation body format - w3c/epub-specs#2942

Ivan Herman: Originally it was about HTML not markdown, but I don't want to repeat that discussion
… I expect internationalization review will have comments, which is I why I mentioned html
… we had a long discussion on it, and the consensus was it would not be supported
… but we still need something for i13n
… so I changed to markdown
… the spec already allows markdown
… so we have to agree to support it
… and explain how it relates to i13n
… markdown generally allows adding html tags for certain things i13n related
… but there are a lot of markdown implementations and levels
… so we need to spec it specifically
… there were also some voices that said we shouldn't have markdown either
… one practical thing - the way the impls work is by converting to html, that is how tag inclusion works
… that would be a security issue, so we would need to use the sanitizer to clean that up

Hadrien Gardeur: I have less of an issue with markdown than html
… I do have a concern about using it to sneakily add html
… simple styling is fine (bold, etc) and it is easy to type
… if we are using it to pull in html I an concerned, and I think most people will just sanitize it out
… markdown is good because it is easy to enter

Ivan Herman: I agree the main reason is the styling
… but html will be important for i18n
… so we can get past that review by pointing to the html support of markdown

Hadrien Gardeur: I think most implementations will just remove all html

Brady Duga: I worry about support for annotation styling
… markdown should be noted as at risk
… markdown has a good fall down to plain text
… using HTML tags as a back door is lying to get through the review
… outside of web readers you're putting annotations in a system level box
… it will simply appear as HTML with tags
… no one is writing HTML fields
… I don't think this is a real way to get annotations in

ajelinek: we already store annotations as html
… my main concern is markdown isn't very standardized
… it is no more secure than html
… the dom sanitizer is not supported everywhere
… so as an implementor I don't want to see markdown in the standard
… I don't want to be in the business of saying what tags are allowed
… markdown is essentially a superset of html

Susan Neuhaus: Abe Jellinek, do you support i18n? vertical, rtl

Abe Jellinek: rtl where it is supported, not vertical

Wendy Reid: So there is no one true markdown

Ivan Herman: let's separate these things
… first is markdown, yes or no?
… outside of that, the only 18n we have is unicode

<Wendy Reid> https://www.rfc-editor.org/rfc/rfc7763

Ivan Herman: is our message to say we don't offer anything else?
… I have heard competing things

Abe Jellinek: I appreciate that we could help with i18n with markdown, but I don't think it is worth the security risk
… and it forces implementors to add a lot of support for a feature that might be risky

Susan Neuhaus: I did find the rfc markdown

Shinya Takami: markdown or html will have issues with vertical text
… I discussed with Japanese publishers
… Makoto has discussed this as needed, but the publishers don't seem to care
… I find plain text is just fine

Brady Duga: Makoto raised the issue that some people prefer to read vertically
… while some prefer to read horizontally
… and he noted that HTML is bad at that
… plain text is actually the most accessible thing we can do
… I don't think anyone in Japan has implemented vertical text in annotations
… I don't think the vertical horizontal switching is a reason to support
… either HTML or Markdown

Wendy Reid: markdown is nice, because it is readable without the styles
… it doesn't stop you from being able to read it
… if I want to use markdown syntax in plain text, I can, it just won't become styled. But maybe if my RS supports it, it will be fine. Otherwise it just stays plaintext, and is transfered as such
… reading between the comments, we shouldn't officially support markdown, but reading systems can decide to add support if they want

Ivan Herman: is the proposal to remove the reference to markdown?
… so the format must be plaintext, full stop

Wendy Reid: Yes
… when someone reads the spec people may wonder why, so we may need to add a note explaining the choice

Ivan Herman: These days they like an i18n section
… so we should explain that in practice html won't work here
… I am happy to go that way and see what the powers that be say

Wendy Reid: We could include markdown as MAY

Ivan Herman: we are defining interchange, it doesn't make sense to say MAY, since that basically says nothing
… we don't define what the RS does with these

Wendy Reid: EPUB is also interchange, and we have found people like it when we tell them what to do

Shinya Takami: RSes should delete the markdown to export

Ivan Herman: The export is all we are standardizing, so it doesn't make sense to say that

Charles LaPierre: On export the RS would have to convert to plain text

Wendy Reid: That is why saying plaintext is a must implies that markdown is fine but may look funny

Susan Neuhaus: supporting markdown is a legitimate feature of RSes, so staying neutral is a good idea

Charles LaPierre: For a11y side, markdown gives structure, then a screen reader could utilize it

Dale Rogers: I am hearing reluctance, can the spec kick the can down the road and tell people to check reading system support?

Abe Jellinek: If we did that we would want to tag the text as markdown, so we don't confuse plain text and markdown

Wendy Reid: We can always kick things down the road!

GeorgeK: If somebody put in markdown, then the rs would have to strip it out on export
… then if someone put in markdown, it would just go in as markdown in the plain text
… On the a11y side, most people understand plain text, I am not sure how much regular people know about markdown
… they also tend to be short, so they don't need as much help (the length of annotations)

Abe Jellinek: The RS could use WYSIWYG editing, so they may not know anything about markdown to use it

<Ivan Herman> +1 to Abe Jellinek

Wendy Reid: I think we have consensus in plaintext as the default for annotation bodies
… we know people will use markdown in annotations. Lots of tools support it
… but we also know there are multple types of markdown
… the question for us is, do we want to say MAY use markdown, or just say plaintext only with a note about the decision

<Ivan Herman> +1 to Wendy Reid

Brady Duga: Do we want to say that rs MAY use markdown
… doesn't solve the problem of which markdown we support

Ivan Herman: I agree. I don't think MAY helps
… let us try to make a resolution for plain text as the normative part, with a note about markdown (no single makrdown, not many implementations in RSes)

<Wendy Reid> Proposed: For annotation bodies, plain text will be the interchange format.

<Susan Neuhaus> +1

<Wendy Reid> +1

<Abe Jellinek> +1

<Shinya Takami> +1

<Masakazu Kitahara> +1

<Ivan Herman> +1

<Daniel Kimberg> +1

<sethd> +1

<Brady Duga> +1

<Grigorily Manucharian> +1

<Dale Rogers> +1

<Gregorio Pellegrino> +1

<Charles LaPierre> +1

<Hadrien Gardeur> +1

RESOLUTION: For annotation bodies, plain text will be the interchange format.

<GeorgeK> +1

Ivan Herman: We will have to do a PR to remove it

SMIL TF

Hadrien Gardeur: I discussed with laurent and gautier, we think a task force makes sense
… the TF may not need regular calls, we can work async on many topics
… the issues have been very popular
… we think most people will be interested in chiming in in issues
… so calls won't be the standard work mode

Wendy Reid: That is fine
… more participation is great

Ivan Herman: Do you need any resources?

Hadrien Gardeur: Not really. we just need an official task force so it shows up
… we will probably use discord or slack

Ivan Herman: Just make sure to properly label the issues as for the TF

Hadrien Gardeur: can I set the labels?

Ivan Herman: yes

Wendy Reid: and if you need new ones, let us know

GeorgeK: So this is pm only not joint cg/wg

Hadrien Gardeur: Yes, we thought it made sense since we are making normative changes

Wendy Reid: Yes, anyone can participate in the github issues
… so if that get's people interested, that is great
… we can get people in as guests for short term
… when needed

Wendy Reid: Any other topics?

Brady Duga: Are we doing tpac?

Wendy Reid: yes

sethd: There is a lot to be said for async. Meetings are hard to make
… github is very permanent, our slack is entirely unused
… slack seems like a good place to discuss things

Ivan Herman: It depends on the channel
… for instance the chairs and editors use it a lot
… it is possible to set up a channel for SMIL

sethd: I meant more generally
… nothing progresses because we don't have time

Shinya Takami: slack deletes comments on the w3c slack

Hadrien Gardeur: I think you may be able to get slack for free

Ivan Herman: it didn't work out

Hadrien Gardeur: Do we have influence on early in the week? I prefer early to avoid conflict

Wendy Reid: We always request MT, we will hopefully get that again

Dale Rogers: response to Seth about informal places to chat
… we discussed discussions

Brady Duga: saying things are available are great, if we aren't specific about using it
… it won't get used.
… it would be nice to have someplace to ask a quick question that
… doesn't get saved in the archive
… it might be nice to mandate something like that