Publishing Maintenance Working Group Telco

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

ivan: 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: 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: 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: I think most implementations will just remove all html

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

sueneu: ajellinek, do you support i18n? vertical, rtl

ajellinek: rtl where it is supported, not vertical

wendyreid: So there is no one true markdown

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

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

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

ajellinek: 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

sueneu: I did find the rfc markdown

shiestyle: 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

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

wendyreid: 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: is the proposal to remove the reference to markdown?
… so the format must be plaintext, full stop

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

ivan: 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

wendyreid: We could include markdown as MAY

ivan: 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

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

shiestyle: RSes should delete the markdown to export

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

CharlesL: On export the RS would have to convert to plain text

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

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

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

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

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

wendyreid: 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)

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

<ivan> +1 to ajellinek

wendyreid: 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> +1 to wendyreid

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

ivan: 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)

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

<sueneu> +1

<wendyreid> +1

<ajellinek> +1

<shiestyle> +1

<MasakazuKitahara> +1

<ivan> +1

<kimberg> +1

<sethd> +1

<duga> +1

<gman> +1

<DaleRogers> +1

<gpellegrino> +1

<CharlesL> +1

<Hadrien> +1

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

<GeorgeK> +1

ivan: We will have to do a PR to remove it

SMIL TF

Hadrien: 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

wendyreid: That is fine
… more participation is great

ivan: Do you need any resources?

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

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

Hadrien: can I set the labels?

ivan: yes

wendyreid: and if you need new ones, let us know

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

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

wendyreid: 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

wendyreid: Any other topics?

duga: Are we doing tpac?

wendyreid: 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: 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

shiestyle: slack deletes comments on the w3c slack

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

ivan: it didn't work out

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

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

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

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