[ODK Community] Test build: ODK Collect v1.4.7 rev 1052

[Tino_Kreutzer]

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be extremely
useful to a lot of people, and since it's been around in Enketo notes for a
while, it would expand compatibility instead of introducing a separate way.
Since Html.fromHtml() includes so many allowed tags it could easily make
the form illegible, keeping it restricted with md is probably the better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.) the
only extension needed would be to include a custom syntax for coloring,
say, [color=red]red[/color] for a bbcode syntax - assuming your use case is
coloring individual words within a label rather than all labels as Martijn
suggested.

Tino

···

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support
http://blog.enketo.org/better-notes/ since 2013 before we all agreed to
start collaborating better on these major additions to the form spec
(for performance reasons it has only been enabled in notes/readonly
questions, but I just got funding to solve that and expand it across all
labels). It would be nice if all those forms using markdown started working
in ODK Collect as well. But of course the key is here is to not have to
explain to users that there are two different ways to format labels. So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this instead of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it becomes
very complex if you start supporting more complex tags with attributes such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use #, ##,

tags. I question the need to change font sizes in the middle of a

sentence.

Is it important to be able to change colors of individual words? Maybe the
color requirement can be met by changing the color of the whole label,
using an appearance? I like this much better as we separate semantics from
style, in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware of an
easy way to do this in Markdown, but glad to work with you to find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a year...
Would have been nice to match that. Html formatting is insecure in web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yanokwa]

Moving to the developer list and adding Dimagi, SurveyCTO, and Ona folks.

To summarize, Nafundi has added HTML support to ODK Collect (see
attached) because our clients need inline color and font sizing. We
support a handful of tags
(http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html).

Martijn would prefer Markdown (Enketo already has some limited support
for Markdown already). Markdown does allow and encourage mixing HTML
and Markdown, but that will require Enketo to process HTML which
Martijn isn't excited about because of increased complexity. He also
argues that inline sizing is not needed and per-word coloring is not
important (he suggests coloring the entire label).

I’m looking for a solution that is reasonable for everyone going
forward. For example, what if we switch to BBCode
(https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to
the XML and the form renderers can render it as they choose.

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer tino.kreutzer@kobotoolbox.org wrote:

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be extremely
useful to a lot of people, and since it's been around in Enketo notes for a
while, it would expand compatibility instead of introducing a separate way.
Since Html.fromHtml() includes so many allowed tags it could easily make
the form illegible, keeping it restricted with md is probably the better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.) the only
extension needed would be to include a custom syntax for coloring, say,
[color=red]red[/color] for a bbcode syntax - assuming your use case is
coloring individual words within a label rather than all labels as Martijn
suggested.

Tino

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support since 2013 before we all
agreed to start collaborating better on these major additions to the form
spec (for performance reasons it has only been enabled in notes/readonly
questions, but I just got funding to solve that and expand it across all
labels). It would be nice if all those forms using markdown started working
in ODK Collect as well. But of course the key is here is to not have to
explain to users that there are two different ways to format labels. So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this instead of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it becomes
very complex if you start supporting more complex tags with attributes such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use #, ##,

tags. I question the need to change font sizes in the middle of a

sentence.

Is it important to be able to change colors of individual words? Maybe the
color requirement can be met by changing the color of the whole label, using
an appearance? I like this much better as we separate semantics from style,
in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware of an
easy way to do this in Markdown, but glad to work with you to find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a year...
Would have been nice to match that. Html formatting is insecure in web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[crobert]

Well, now that we have one HTML implementation and one markdown
implementation, I think that adding another into the mix (BBCode) seems
like it only creates more work.

Our about-to-be-released web forms already support HTML (because we didn't
do anything to stop it), and I guess we hadn't seen any reason not to. So
adding even limited HTML support to Collect would instantly improve the
compatibility of forms between our web and Android UI's.

Our only hesitation is performance: if the HTML renderer saps performance
in Collect -- or takes too much memory -- we might think twice about
supporting it. But users ask for the ability to customize labels all the
time, so it would be a hugely popular addition.

I guess that means that we'd lean toward HTML -- until/unless Martijn
convinces us that we're somehow going to regret (lazily) supporting HTML in
our web UI.

Best,

Chris

···

On Mon, Aug 31, 2015 at 3:16 PM Yaw Anokwa wrote:

Moving to the developer list and adding Dimagi, SurveyCTO, and Ona folks.

To summarize, Nafundi has added HTML support to ODK Collect (see
attached) because our clients need inline color and font sizing. We
support a handful of tags
(http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html).

Martijn would prefer Markdown (Enketo already has some limited support
for Markdown already). Markdown does allow and encourage mixing HTML
and Markdown, but that will require Enketo to process HTML which
Martijn isn't excited about because of increased complexity. He also
argues that inline sizing is not needed and per-word coloring is not
important (he suggests coloring the entire label).

I’m looking for a solution that is reasonable for everyone going
forward. For example, what if we switch to BBCode
(https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to
the XML and the form renderers can render it as they choose.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer tino.kreutzer@kobotoolbox.org wrote:

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be extremely
useful to a lot of people, and since it's been around in Enketo notes
for a
while, it would expand compatibility instead of introducing a separate
way.
Since Html.fromHtml() includes so many allowed tags it could easily
make
the form illegible, keeping it restricted with md is probably the better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.) the
only
extension needed would be to include a custom syntax for coloring, say,
[color=red]red[/color] for a bbcode syntax - assuming your use case is
coloring individual words within a label rather than all labels as
Martijn
suggested.

Tino

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt < martijn@enketo.org> wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support since 2013 before we all
agreed to start collaborating better on these major additions to the
form
spec (for performance reasons it has only been enabled in
notes/readonly
questions, but I just got funding to solve that and expand it across all
labels). It would be nice if all those forms using markdown started
working
in ODK Collect as well. But of course the key is here is to not have to
explain to users that there are two different ways to format labels. So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this instead of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it
becomes
very complex if you start supporting more complex tags with attributes
such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use #, ##,

tags. I question the need to change font sizes in the middle of a

sentence.

Is it important to be able to change colors of individual words? Maybe
the
color requirement can be met by changing the color of the whole label,
using
an appearance? I like this much better as we separate semantics from
style,
in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware of an
easy way to do this in Markdown, but glad to work with you to find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a
year...
Would have been nice to match that. Html formatting is insecure in
web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yanokwa]

And you just stick the HTML inline? You support all tags? Do you wrap
everything in CDATA tags?

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Mon, Aug 31, 2015 at 3:28 PM, Christopher Robert crobert@surveycto.com wrote:

Well, now that we have one HTML implementation and one markdown
implementation, I think that adding another into the mix (BBCode) seems like
it only creates more work.

Our about-to-be-released web forms already support HTML (because we didn't
do anything to stop it), and I guess we hadn't seen any reason not to. So
adding even limited HTML support to Collect would instantly improve the
compatibility of forms between our web and Android UI's.

Our only hesitation is performance: if the HTML renderer saps performance in
Collect -- or takes too much memory -- we might think twice about supporting
it. But users ask for the ability to customize labels all the time, so it
would be a hugely popular addition.

I guess that means that we'd lean toward HTML -- until/unless Martijn
convinces us that we're somehow going to regret (lazily) supporting HTML in
our web UI.

Best,

Chris

On Mon, Aug 31, 2015 at 3:16 PM Yaw Anokwa yanokwa@nafundi.com wrote:

Moving to the developer list and adding Dimagi, SurveyCTO, and Ona folks.

To summarize, Nafundi has added HTML support to ODK Collect (see
attached) because our clients need inline color and font sizing. We
support a handful of tags
(http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html).

Martijn would prefer Markdown (Enketo already has some limited support
for Markdown already). Markdown does allow and encourage mixing HTML
and Markdown, but that will require Enketo to process HTML which
Martijn isn't excited about because of increased complexity. He also
argues that inline sizing is not needed and per-word coloring is not
important (he suggests coloring the entire label).

I’m looking for a solution that is reasonable for everyone going
forward. For example, what if we switch to BBCode
(https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to
the XML and the form renderers can render it as they choose.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer tino.kreutzer@kobotoolbox.org wrote:

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be extremely
useful to a lot of people, and since it's been around in Enketo notes
for a
while, it would expand compatibility instead of introducing a separate
way.
Since Html.fromHtml() includes so many allowed tags it could easily
make
the form illegible, keeping it restricted with md is probably the better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.) the
only
extension needed would be to include a custom syntax for coloring, say,
[color=red]red[/color] for a bbcode syntax - assuming your use case is
coloring individual words within a label rather than all labels as
Martijn
suggested.

Tino

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support since 2013 before we all
agreed to start collaborating better on these major additions to the
form
spec (for performance reasons it has only been enabled in
notes/readonly
questions, but I just got funding to solve that and expand it across
all
labels). It would be nice if all those forms using markdown started
working
in ODK Collect as well. But of course the key is here is to not have to
explain to users that there are two different ways to format labels. So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this instead
of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it
becomes
very complex if you start supporting more complex tags with attributes
such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use #, ##,

tags. I question the need to change font sizes in the middle of a

sentence.

Is it important to be able to change colors of individual words? Maybe
the
color requirement can be met by changing the color of the whole label,
using
an appearance? I like this much better as we separate semantics from
style,
in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware of an
easy way to do this in Markdown, but glad to work with you to find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a
year...
Would have been nice to match that. Html formatting is insecure in
web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[crobert]

No CDATA tags, nothing. We just fail to escape HTML-specific characters
when rendering labels in HTML. Our QC engineer is still working through the
test cases, but I guess that she'll soon enough run into >'s and <'s
behaving poorly, and then she'll push us to sort something out. At that
point, we may need to add some kind of option, perhaps at the form level;
or we have them open and close HTML or CDATA sections. We're still
finalizing this web form support. (Sure: the XML gets encoded, but it gets
un-encoded when displayed in Collect, and we use that same code for our web
forms. So it's un-encoded by the time it goes for rendering.)

Chris

···

On Mon, Aug 31, 2015 at 3:34 PM Yaw Anokwa wrote:

And you just stick the HTML inline? You support all tags? Do you wrap
everything in CDATA tags?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Mon, Aug 31, 2015 at 3:28 PM, Christopher Robert crobert@surveycto.com wrote:

Well, now that we have one HTML implementation and one markdown
implementation, I think that adding another into the mix (BBCode) seems
like
it only creates more work.

Our about-to-be-released web forms already support HTML (because we
didn't
do anything to stop it), and I guess we hadn't seen any reason not to. So
adding even limited HTML support to Collect would instantly improve the
compatibility of forms between our web and Android UI's.

Our only hesitation is performance: if the HTML renderer saps
performance in
Collect -- or takes too much memory -- we might think twice about
supporting
it. But users ask for the ability to customize labels all the time, so it
would be a hugely popular addition.

I guess that means that we'd lean toward HTML -- until/unless Martijn
convinces us that we're somehow going to regret (lazily) supporting HTML
in
our web UI.

Best,

Chris

On Mon, Aug 31, 2015 at 3:16 PM Yaw Anokwa yanokwa@nafundi.com wrote:

Moving to the developer list and adding Dimagi, SurveyCTO, and Ona
folks.

To summarize, Nafundi has added HTML support to ODK Collect (see
attached) because our clients need inline color and font sizing. We
support a handful of tags
(http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html).

Martijn would prefer Markdown (Enketo already has some limited support
for Markdown already). Markdown does allow and encourage mixing HTML
and Markdown, but that will require Enketo to process HTML which
Martijn isn't excited about because of increased complexity. He also
argues that inline sizing is not needed and per-word coloring is not
important (he suggests coloring the entire label).

I’m looking for a solution that is reasonable for everyone going
forward. For example, what if we switch to BBCode
(https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to
the XML and the form renderers can render it as they choose.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer tino.kreutzer@kobotoolbox.org wrote:

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be
extremely
useful to a lot of people, and since it's been around in Enketo notes
for a
while, it would expand compatibility instead of introducing a separate
way.
Since Html.fromHtml() includes so many allowed tags it could easily
make
the form illegible, keeping it restricted with md is probably the
better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.)
the
only
extension needed would be to include a custom syntax for coloring,
say,
[color=red]red[/color] for a bbcode syntax - assuming your use case is
coloring individual words within a label rather than all labels as
Martijn
suggested.

Tino

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support since 2013 before we all
agreed to start collaborating better on these major additions to the
form
spec (for performance reasons it has only been enabled in
notes/readonly
questions, but I just got funding to solve that and expand it across
all
labels). It would be nice if all those forms using markdown started
working
in ODK Collect as well. But of course the key is here is to not have
to
explain to users that there are two different ways to format labels.
So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this instead
of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it
becomes
very complex if you start supporting more complex tags with
attributes
such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use #,
##,

tags. I question the need to change font sizes in the middle of a

sentence.

Is it important to be able to change colors of individual words?
Maybe
the
color requirement can be met by changing the color of the whole
label,
using
an appearance? I like this much better as we separate semantics from
style,
in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware of
an
easy way to do this in Markdown, but glad to work with you to find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is
potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a
year...
Would have been nice to match that. Html formatting is insecure in
web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[martijnr]

until/unless Martijn convinces us that we're somehow going to regret
(lazily) supporting HTML in our web UI.

Ok, here is my attempt, in order of importance:

1. Enketo has supported Markdown since 2013
2. Markdown has been documented in the XLSForm spec for a
   while: http://xlsform.org/#styling
3. Markdown is easier for users than HTML or BBCode.
4. Markdown is automatically safe(r) in web clients because it's not HTML.
   Obviously HTML needs to be sanitized. Otherwise you could e.g. create a
   form that steals confidential data from other forms/client data storage
   hosted on the same domain. You could create a form that crashes your app,
   or hogs all the device's resources. In my understanding, you never let
   users enter HTML and then display this in a webpage unsanitized.
5. Markdown is more backwards-compatible with old clients because it is not
   as intrusive. this doesn't look as bad as [span style="text-decoration:
   italic;"]this[/span]

I think the outstanding questions are:
a. Do our users really need to change fonts sizes of individual words
or can font-size support be for headings only? In my opinion, a user
request to change font sizes truly inline is one we should gently push back
against. It will almost definitely lead to a messy looking form (so that
they won't actually end up using it).
b. Do our users really need to change colors of individual words or can
colors be supported only for the whole label/hint?

If we were starting this feature discussion from scratch (which we aren't),
I would put Markdown first, and BBCode second. If styling individual words
is really important, I think the best outcome (since we're *not *starting
from scratch) is to add the required BBCode features in addition to
markdown.

···

On Monday, August 31, 2015 at 1:49:48 PM UTC-6, Christopher Robert wrote: > > No CDATA tags, nothing. We just fail to escape HTML-specific characters > when rendering labels in HTML. Our QC engineer is still working through the > test cases, but I guess that she'll soon enough run into >'s and <'s > behaving poorly, and then she'll push us to sort something out. At that > point, we may need to add some kind of option, perhaps at the form level; > or we have them open and close HTML or CDATA sections. We're still > finalizing this web form support. (Sure: the XML gets encoded, but it gets > un-encoded when displayed in Collect, and we use that same code for our web > forms. So it's un-encoded by the time it goes for rendering.) > > Chris > > > On Mon, Aug 31, 2015 at 3:34 PM Yaw Anokwa <yan...@nafundi.com > wrote: > >> And you just stick the HTML inline? You support all tags? Do you wrap >> everything in CDATA tags? >> >> Yaw >> -- >> Need ODK services? http://nafundi.com provides form design, server >> setup, professional support, and software development for ODK. >> >> On Mon, Aug 31, 2015 at 3:28 PM, Christopher Robert <cro...@surveycto.com > wrote: >> > Well, now that we have one HTML implementation and one markdown >> > implementation, I think that adding another into the mix (BBCode) seems >> like >> > it only creates more work. >> > >> > Our about-to-be-released web forms already support HTML (because we >> didn't >> > do anything to stop it), and I guess we hadn't seen any reason not to. >> So >> > adding even limited HTML support to Collect would instantly improve the >> > compatibility of forms between our web and Android UI's. >> > >> > Our only hesitation is performance: if the HTML renderer saps >> performance in >> > Collect -- or takes too much memory -- we might think twice about >> supporting >> > it. But users ask for the ability to customize labels all the time, so >> it >> > would be a hugely popular addition. >> > >> > I guess that means that we'd lean toward HTML -- until/unless Martijn >> > convinces us that we're somehow going to regret (lazily) supporting >> HTML in >> > our web UI. >> > >> > Best, >> > >> > Chris >> > >> > >> > On Mon, Aug 31, 2015 at 3:16 PM Yaw Anokwa <yan...@nafundi.com > wrote: >> >> >> >> Moving to the developer list and adding Dimagi, SurveyCTO, and Ona >> folks. >> >> >> >> To summarize, Nafundi has added HTML support to ODK Collect (see >> >> attached) because our clients need inline color and font sizing. We >> >> support a handful of tags >> >> (http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html). >> >> >> >> Martijn would prefer Markdown (Enketo already has some limited support >> >> for Markdown already). Markdown does allow and encourage mixing HTML >> >> and Markdown, but that will require Enketo to process HTML which >> >> Martijn isn't excited about because of increased complexity. He also >> >> argues that inline sizing is not needed and per-word coloring is not >> >> important (he suggests coloring the entire label). >> >> >> >> I’m looking for a solution that is reasonable for everyone going >> >> forward. For example, what if we switch to BBCode >> >> (https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to >> >> the XML and the form renderers can render it as they choose. >> >> >> >> Yaw >> >> -- >> >> Need ODK services? http://nafundi.com provides form design, server >> >> setup, professional support, and software development for ODK. >> >> >> >> On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer <tino.k...@kobotoolbox.org > wrote: >> >> > Thanks for the changes, Yaw. >> >> > >> >> > +1 for using markdown instead of raw html tags. This would be >> extremely >> >> > useful to a lot of people, and since it's been around in Enketo notes >> >> > for a >> >> > while, it would expand compatibility instead of introducing a >> separate >> >> > way. >> >> > Since `Html.fromHtml()` includes so many allowed tags it could easily >> >> > make >> >> > the form illegible, keeping it restricted with md is probably the >> better >> >> > option in my opinion. >> >> > >> >> > Since font sizes could be controlled with headers (#, ##, ### etc.) >> the >> >> > only >> >> > extension needed would be to include a custom syntax for coloring, >> say, >> >> > [color=red]red[/color] for a bbcode syntax - assuming your use case >> is >> >> > coloring individual words within a label rather than all labels as >> >> > Martijn >> >> > suggested. >> >> > >> >> > Tino >> >> > >> >> > >> >> > >> >> > On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: >> >> >> >> >> >> Thanks Yaw, >> >> >> >> >> >> Yes, Enketo has had limited markdown support since 2013 before we >> all >> >> >> agreed to start collaborating better on these major additions to the >> >> >> form >> >> >> spec ;) (for performance reasons it has only been enabled in >> >> >> notes/readonly >> >> >> questions, but I just got funding to solve that and expand it across >> >> >> all >> >> >> labels). It would be nice if all those forms using markdown started >> >> >> working >> >> >> in ODK Collect as well. But of course the key is here is to not >> have to >> >> >> explain to users that there are two different ways to format >> labels. So >> >> >> thanks for being willing to look into this further. >> >> >> >> >> >> We chose markdown (back in 2013), because it would be the least >> >> >> problematic in clients that didn't support it, showing *this* >> instead >> >> >> of >> >> >> this. It's also very easy to use. >> >> >> >> >> >> Sure, we could have chosen to sanitize html (back in 2013) but it >> >> >> becomes >> >> >> very complex if you start supporting more complex tags with >> attributes >> >> >> such >> >> >> as links. Needlessly complex (and thus fragile) in my opinion. >> >> >> >> >> >> If font-size can be supported in headings only we could just use #, >> ##, >> >> >> ### tags. I question the need to change font sizes in the middle of >> a >> >> >> sentence. >> >> >> >> >> >> Is it important to be able to change colors of individual words? >> Maybe >> >> >> the >> >> >> color requirement can be met by changing the color of the whole >> label, >> >> >> using >> >> >> an appearance? I like this much better as we separate semantics from >> >> >> style, >> >> >> in the same manner as we already do in XForms. >> >> >> >> >> >> Cheers, >> >> >> Martijn >> >> >> >> >> >> >> >> >> On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote: >> >> >>> >> >> >>> Hi Martijn, >> >> >>> >> >> >>> I didn't know Enketo had Markdown. Regardless, Markdown doesn't >> >> >>> support color and sizing and that's what we need. I'm not aware of >> an >> >> >>> easy way to do this in Markdown, but glad to work with you to find >> a >> >> >>> suitable compromise. Maybe a BBCode-ish format? >> >> >>> >> >> >>> As to security, it's true that raw HTML in web clients is >> potentially >> >> >>> insecure, but Enketo can allow the limited subset of safe tags we >> >> >>> support using a sanitizing library, no? >> >> >>> >> >> >>> Yaw >> >> >>> -- >> >> >>> Need ODK services? http://nafundi.com provides form design, server >> >> >>> setup, professional support, and software development for ODK. >> >> >>> >> >> >>> On Thu, Aug 27, 2015 at 9:21 PM, wrote: >> >> >>> > Html formatting? Enketo has been supporting markdown for over a >> >> >>> > year... >> >> >>> > Would have been nice to match that. Html formatting is insecure >> in >> >> >>> > web >> >> >>> > clients. >> >> >>> > >> >> >>> > -- >> >> >>> > -- >> >> >>> > Post: opend...@googlegroups.com >> >> >>> > Unsubscribe: opendatakit...@googlegroups.com >> >> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >> >> >>> > >> >> >>> > --- >> >> >>> > You received this message because you are subscribed to the >> Google >> >> >>> > Groups "ODK Community" group. >> >> >>> > To unsubscribe from this group and stop receiving emails from it, >> >> >>> > send >> >> >>> > an email to opendatakit...@googlegroups.com. >> >> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> -- >> >> >> Revolutionizing data collection since 2012. >> >> >> >> >> >> Enketo | LinkedIn | GitHub | Twitter | Blog >> >> >> >> >> >> -- >> >> >> -- >> >> >> Post: opend...@googlegroups.com >> >> >> Unsubscribe: opendatakit...@googlegroups.com >> >> >> Options: http://groups.google.com/group/opendatakit?hl=en >> >> >> >> >> >> --- >> >> >> You received this message because you are subscribed to the Google >> >> >> Groups >> >> >> "ODK Community" group. >> >> >> To unsubscribe from this group and stop receiving emails from it, >> send >> >> >> an >> >> >> email to opendatakit...@googlegroups.com . >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> > >> >> > >> >> > -- >> >> > -- >> >> > Post: opend...@googlegroups.com >> >> > Unsubscribe: opendatakit...@googlegroups.com >> >> > Options: http://groups.google.com/group/opendatakit?hl=en >> >> > >> >> > --- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "ODK Community" group. >> >> > To unsubscribe from this group and stop receiving emails from it, >> send >> >> > an >> >> > email to opendatakit...@googlegroups.com . >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "ODK Developers" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an >> >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> > >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >

[Matt_Berg]

I personally like markdown. I agree with Martijn it keeps things simple and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to support markdown and an addition font / div tag but ignore the rest of html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word like WARNING in red. If we get into stuff like tables I begin to worry about formatting and we could just recommend using an image.

[crobert]

Hi Martijn,

I'd like to comment on your following point: "Obviously HTML needs to be
sanitized. Otherwise you could e.g. create a form that steals confidential
data from other forms/client data storage hosted on the same domain."

If sensitive data is stored in any way, shape, or form that can even in
principle be stolen in this kind of way, then I believe that the problem is
with the storage of that data -- not with the ability for hacker form
designers to steal said data. As you know, we stress the importance of data
encryption (with users' own keys so that data is safe even from our
technical staff), and any local storage of data within browser storage
opens up a range of vulnerabilities. The solution here, from my point of
view, is not to have sensitive confidential data stored locally in things
like web browsers.

The question really becomes, in my view, whether we want to allow our users
to create the equivalent of a malicious website hosted with our tools. You
take the position that users should be prevented from creating a malicious
website (including your further point that you "could create a form that
crashes your app, or hogs all the device's resources"). I guess that we
haven't quite decided whether we view it as our responsibility to restrict
our users, to prevent certain types of HTML from executing within their web
forms.

So I guess I'd say that it's not as obvious to me that HTML "needs to be
sanitized." There's some responsibility/paternalism balance to sort out
here, though I respect and appreciate that you seem to have a firm personal
position on all of this.

Best,

Chris

···

On Tue, Sep 1, 2015 at 12:43 PM Martijn van de Rijdt wrote:

until/unless Martijn convinces us that we're somehow going to regret

(lazily) supporting HTML in our web UI.

Ok, here is my attempt, in order of importance:

1. Enketo has supported Markdown since 2013
2. Markdown has been documented in the XLSForm spec for a while:
   http://xlsform.org/#styling
3. Markdown is easier for users than HTML or BBCode.
4. Markdown is automatically safe(r) in web clients because it's not HTML.
   Obviously HTML needs to be sanitized. Otherwise you could e.g. create a
   form that steals confidential data from other forms/client data storage
   hosted on the same domain. You could create a form that crashes your app,
   or hogs all the device's resources. In my understanding, you never let
   users enter HTML and then display this in a webpage unsanitized.
5. Markdown is more backwards-compatible with old clients because it is
   not as intrusive. this doesn't look as bad as [span
   style="text-decoration: italic;"]this[/span]

I think the outstanding questions are:
a. Do our users really need to change fonts sizes of individual words
or can font-size support be for headings only? In my opinion, a user
request to change font sizes truly inline is one we should gently push
back against. It will almost definitely lead to a messy looking form (so
that they won't actually end up using it).
b. Do our users really need to change colors of individual words or
can colors be supported only for the whole label/hint?

If we were starting this feature discussion from scratch (which we
aren't), I would put Markdown first, and BBCode second. If styling
individual words is really important, I think the best outcome (since we're *not
*starting from scratch) is to add the required BBCode features in
addition to markdown.

On Monday, August 31, 2015 at 1:49:48 PM UTC-6, Christopher Robert wrote:

No CDATA tags, nothing. We just fail to escape HTML-specific characters
when rendering labels in HTML. Our QC engineer is still working through the
test cases, but I guess that she'll soon enough run into >'s and <'s
behaving poorly, and then she'll push us to sort something out. At that
point, we may need to add some kind of option, perhaps at the form level;
or we have them open and close HTML or CDATA sections. We're still
finalizing this web form support. (Sure: the XML gets encoded, but it gets
un-encoded when displayed in Collect, and we use that same code for our web
forms. So it's un-encoded by the time it goes for rendering.)

Chris

On Mon, Aug 31, 2015 at 3:34 PM Yaw Anokwa yan...@nafundi.com wrote:

And you just stick the HTML inline? You support all tags? Do you wrap

everything in CDATA tags?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Mon, Aug 31, 2015 at 3:28 PM, Christopher Robert cro...@surveycto.com wrote:

Well, now that we have one HTML implementation and one markdown
implementation, I think that adding another into the mix (BBCode)
seems like
it only creates more work.

Our about-to-be-released web forms already support HTML (because we
didn't
do anything to stop it), and I guess we hadn't seen any reason not to.
So
adding even limited HTML support to Collect would instantly improve the
compatibility of forms between our web and Android UI's.

Our only hesitation is performance: if the HTML renderer saps
performance in
Collect -- or takes too much memory -- we might think twice about
supporting
it. But users ask for the ability to customize labels all the time, so
it
would be a hugely popular addition.

I guess that means that we'd lean toward HTML -- until/unless Martijn
convinces us that we're somehow going to regret (lazily) supporting
HTML in
our web UI.

Best,

Chris

On Mon, Aug 31, 2015 at 3:16 PM Yaw Anokwa yan...@nafundi.com wrote:

Moving to the developer list and adding Dimagi, SurveyCTO, and Ona
folks.

To summarize, Nafundi has added HTML support to ODK Collect (see
attached) because our clients need inline color and font sizing. We
support a handful of tags
(http://daniel-codes.blogspot.ca/2011/04/html-in-textviews.html).

Martijn would prefer Markdown (Enketo already has some limited support
for Markdown already). Markdown does allow and encourage mixing HTML
and Markdown, but that will require Enketo to process HTML which
Martijn isn't excited about because of increased complexity. He also
argues that inline sizing is not needed and per-word coloring is not
important (he suggests coloring the entire label).

I’m looking for a solution that is reasonable for everyone going
forward. For example, what if we switch to BBCode
(https://en.wikipedia.org/wiki/BBCode)? That is, BBCode gets added to
the XML and the form renderers can render it as they choose.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Aug 28, 2015 at 11:20 AM, Tino Kreutzer tino.k...@kobotoolbox.org wrote:

Thanks for the changes, Yaw.

+1 for using markdown instead of raw html tags. This would be
extremely
useful to a lot of people, and since it's been around in Enketo
notes
for a
while, it would expand compatibility instead of introducing a
separate
way.
Since Html.fromHtml() includes so many allowed tags it could
easily
make
the form illegible, keeping it restricted with md is probably the
better
option in my opinion.

Since font sizes could be controlled with headers (#, ##, ### etc.)
the
only
extension needed would be to include a custom syntax for coloring,
say,
[color=red]red[/color] for a bbcode syntax - assuming your use case
is
coloring individual words within a label rather than all labels as
Martijn
suggested.

Tino

On Fri, Aug 28, 2015 at 11:18 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Thanks Yaw,

Yes, Enketo has had limited markdown support since 2013 before we
all
agreed to start collaborating better on these major additions to
the
form
spec (for performance reasons it has only been enabled in
notes/readonly
questions, but I just got funding to solve that and expand it
across
all
labels). It would be nice if all those forms using markdown started
working
in ODK Collect as well. But of course the key is here is to not
have to
explain to users that there are two different ways to format
labels. So
thanks for being willing to look into this further.

We chose markdown (back in 2013), because it would be the least
problematic in clients that didn't support it, showing this
instead
of
this. It's also very easy to use.

Sure, we could have chosen to sanitize html (back in 2013) but it
becomes
very complex if you start supporting more complex tags with
attributes
such
as links. Needlessly complex (and thus fragile) in my opinion.

If font-size can be supported in headings only we could just use
#, ##,

tags. I question the need to change font sizes in the middle

of a

sentence.

Is it important to be able to change colors of individual words?
Maybe
the
color requirement can be met by changing the color of the whole
label,
using
an appearance? I like this much better as we separate semantics
from
style,
in the same manner as we already do in XForms.

Cheers,
Martijn

On Thursday, August 27, 2015 at 7:51:19 PM UTC-6, Yaw Anokwa wrote:

Hi Martijn,

I didn't know Enketo had Markdown. Regardless, Markdown doesn't
support color and sizing and that's what we need. I'm not aware
of an
easy way to do this in Markdown, but glad to work with you to
find a
suitable compromise. Maybe a BBCode-ish format?

As to security, it's true that raw HTML in web clients is
potentially
insecure, but Enketo can allow the limited subset of safe tags we
support using a sanitizing library, no?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.

On Thu, Aug 27, 2015 at 9:21 PM, mri...@gmail.com wrote:

Html formatting? Enketo has been supporting markdown for over a
year...
Would have been nice to match that. Html formatting is insecure
in
web
clients.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the
Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it,
send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

---

You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[crobert]

Where do the ODK 2.0 tools stand on this? Aren't they much more heavily
HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that
it's relevant to understanding the future impact of this decision.)

Chris

···

On Tue, Sep 1, 2015 at 1:03 PM wrote:

I personally like markdown. I agree with Martijn it keeps things simple
and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to support
markdown and an addition font / div tag but ignore the rest of html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word like
WARNING in red. If we get into stuff like tables I begin to worry about
formatting and we could just recommend using an image.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mitch_S]

=========== w.r.t. 1.x tools ===============
(First: thanks for raising this issue and discussing it.)

---- Markdown support ----

Seems like the only feature missing from Markdown vs. the simplified HTML
support in 1.4.7 is font color. I do think this would be useful to add. I
miss having this on GitHub.

The downside of Markdown is it requires code to implement it. Android
provides Html.fromHtml(...) to manipulate HTML markup (
http://developer.android.com/reference/android/text/Html.html )

---- HTML support ----

If we are to allow HTML markup (everywhere), I think this might be
addressed with a tighter specification of what emits.

If we assume the creator of the form is never malicious and knows HTML, the
only thing we need to protect is the user-entered data, which would always
pass through before being injected into a label or hint. If
were guaranteed to always escape the special XML/HTML characters,
then wouldn't that be sufficient?

e.g., escaping similar to this:
https://github.com/janl/mustache.js/blob/master/mustache.js#L60

Currently, when the form is loaded, the JR code replaces the tag
with a ${ref} expression (
https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031
) And then when a label or hint is constructed, this code is used: (
https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878
).

That code could be changed to ensure that the values of the substitution
arguments are properly escaped. This would enable the label or hint to
contain arbitrary HTML.

This would be the minimal necessary JR/ODK Collect code change before the
1.4.7 build can be released.

=====2.0 tools=====
Each 2.0 tool -- Survey and Tables -- takes a different approach to this.
However, in general, it is coder-beware -- app developers (form creators)
need to do the right thing.

In ODK Tables, app developers write their own HTML and javascript. ODK
Tables provides minimal 'control' and 'data' object for getting rows of
data and for invoking ODK Collect or ODK Survey to fill in forms, and for
navigating to other list views / graph views or item views on the same base
table or another base table. It doesn't provide much else.

When creating content, ODK Tables app developers can use the underscore.js
library and its HTML escape function. We see this as a best-practices
documentation issue w.r.t. ODK Tables and its example apps. The function
exists; app creators should use that library and its function.

In ODK Survey, all page content is rendered through handlebars templates (
http://handlebarsjs.com/ ). The display text supplied in the XLSX file is
assumed to contain HTML markup. That markup is preserved via the
triple-mustache:
{{{ display.text }}}
construct. Within that display.text, if the creator of the form wants to
inject a value from the survey data, they would ordinarily use a
double-mustache (which escapes the value):
{{ data.fieldname }}
The ODK Survey code, however, simply accepts whatever the creator
specified. We expect the creator to understand the implications of each.
Again, it is a best-practices documentation issue.

···

On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert wrote:

Where do the ODK 2.0 tools stand on this? Aren't they much more heavily
HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that
it's relevant to understanding the future impact of this decision.)

Chris

On Tue, Sep 1, 2015 at 1:03 PM mberg@ona.io wrote:

I personally like markdown. I agree with Martijn it keeps things simple
and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to support
markdown and an addition font / div tag but ignore the rest of html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word like
WARNING in red. If we get into stuff like tables I begin to worry about
formatting and we could just recommend using an image.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

[martijnr]

Thanks. Okay, color changing of sections within a label seems valuable.

I've been trying to find out which HTML tags are allowed in markdown (and
in which markdown 'spec'). I haven't found a definitive answer (this
https://github.com/jch/html-pipeline/blob/master/lib/html/pipeline/sanitization_filter.rb
is the filter GitHub uses but this contains a strict and less-strict
whitelist).

I think we won't be able to find a library that supports the exact same
subset for both Android and web (and iOS and ?) clients. However, if we are
very strict about what we support, the # of lines of code required could be
very limited (fwiw, this
https://github.com/enketo/enketo-core/blob/master/src/js/plugins.js#L74-L104
is the current code in Enketo - you could maybe even use this and apply
Html.fromHtml() on the result ;)).

I think span elements are maybe safe enough (in terms of malicious intent,
stability, performance, accidentally breaking the DOM). So if supporting
span elements in addition to the pure markdown (* _ * __ link # ## ###
####) and two types of lists is a solution everybody can accept, I'd be
happy with that compromise. You'd be able to use Html.fromHtml() for just
the span elements perhaps? Would that cover the style attribute with all
the css text styling options or just a subset of css values?

I agree that user-entered data displayed in outputs should indeed not be
formattable by the value (and escaped). Formatting could be done in the
label like "The value you entered previously was: ${value}".

···

On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote: > > =========== w.r.t. 1.x tools =============== > (First: thanks for raising this issue and discussing it.) > > ---- Markdown support ---- > > Seems like the only feature missing from Markdown vs. the simplified HTML > support in 1.4.7 is font color. I do think this would be useful to add. I > miss having this on GitHub. > > The downside of Markdown is it requires code to implement it. Android > provides Html.fromHtml(...) to manipulate HTML markup ( > http://developer.android.com/reference/android/text/Html.html ) > > ---- HTML support ---- > > If we are to allow HTML markup (everywhere), I think this might be > addressed with a tighter specification of what emits. > > If we assume the creator of the form is never malicious and knows HTML, > the only thing we need to protect is the user-entered data, which would > always pass through before being injected into a label or hint. If > were guaranteed to always escape the special XML/HTML characters, > then wouldn't that be sufficient? > > e.g., escaping similar to this: > https://github.com/janl/mustache.js/blob/master/mustache.js#L60 > > Currently, when the form is loaded, the JR code replaces the tag > with a ${ref} expression ( > https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031 > ) And then when a label or hint is constructed, this code is used: ( > https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878 > ). > > That code could be changed to ensure that the values of the substitution > arguments are properly escaped. This would enable the label or hint to > contain arbitrary HTML. > > This would be the minimal necessary JR/ODK Collect code change before the > 1.4.7 build can be released. > > =====2.0 tools===== > Each 2.0 tool -- Survey and Tables -- takes a different approach to this. > However, in general, it is coder-beware -- app developers (form creators) > need to do the right thing. > > In ODK Tables, app developers write their own HTML and javascript. ODK > Tables provides minimal 'control' and 'data' object for getting rows of > data and for invoking ODK Collect or ODK Survey to fill in forms, and for > navigating to other list views / graph views or item views on the same base > table or another base table. It doesn't provide much else. > > When creating content, ODK Tables app developers can use the underscore.js > library and its HTML escape function. We see this as a best-practices > documentation issue w.r.t. ODK Tables and its example apps. The function > exists; app creators should use that library and its function. > > In ODK Survey, all page content is rendered through handlebars templates ( > http://handlebarsjs.com/ ). The display text supplied in the XLSX file is > assumed to contain HTML markup. That markup is preserved via the > triple-mustache: > {{{ display.text }}} > construct. Within that display.text, if the creator of the form wants to > inject a value from the survey data, they would ordinarily use a > double-mustache (which escapes the value): > {{ data.fieldname }} > The ODK Survey code, however, simply accepts whatever the creator > specified. We expect the creator to understand the implications of each. > Again, it is a best-practices documentation issue. > > > On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert <cro...@surveycto.com > wrote: > >> Where do the ODK 2.0 tools stand on this? Aren't they much more heavily >> HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that >> it's relevant to understanding the future impact of this decision.) >> >> Chris >> >> On Tue, Sep 1, 2015 at 1:03 PM <mb...@ona.io > wrote: >> >>> I personally like markdown. I agree with Martijn it keeps things simple >>> and avoids the risk that html can create. >>> >>> I realize it's a bit of a hack but one approach might be to support >>> markdown and an addition font / div tag but ignore the rest of html. >>> >>> >>> http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words >>> >>> Limited support for html where you support >>> * b, i and ul/li and font tags is the other option I guess. >>> >>> The main use case I see is people wanting to color a single word like >>> WARNING in red. If we get into stuff like tables I begin to worry about >>> formatting and we could just recommend using an image. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to opendatakit-developers+unsubscribe@googlegroups.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

[Mitch_S]

Using a Java implementation of Enketo's markdown-to-html would be a slick
way of supporting markdown within ODK Collect. Very nice.

XLSForm.org should specify exactly what is supported in either/both. No
opinions on what limits there should be, but generally agree with Martijn's
points re: usable stylings.

···

On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt wrote:

Thanks. Okay, color changing of sections within a label seems valuable.

I've been trying to find out which HTML tags are allowed in markdown (and
in which markdown 'spec'). I haven't found a definitive answer (this
https://github.com/jch/html-pipeline/blob/master/lib/html/pipeline/sanitization_filter.rb
is the filter GitHub uses but this contains a strict and less-strict
whitelist).

I think we won't be able to find a library that supports the exact same
subset for both Android and web (and iOS and ?) clients. However, if we are
very strict about what we support, the # of lines of code required could be
very limited (fwiw, this
https://github.com/enketo/enketo-core/blob/master/src/js/plugins.js#L74-L104
is the current code in Enketo - you could maybe even use this and apply
Html.fromHtml() on the result ;)).

I think span elements are maybe safe enough (in terms of malicious intent,
stability, performance, accidentally breaking the DOM). So if supporting
span elements in addition to the pure markdown (* _ * __ link # ## ###
####) and two types of lists is a solution everybody can accept, I'd be
happy with that compromise. You'd be able to use Html.fromHtml() for just
the span elements perhaps? Would that cover the style attribute with all
the css text styling options or just a subset of css values?

I agree that user-entered data displayed in outputs should indeed not be
formattable by the value (and escaped). Formatting could be done in the
label like "The value you entered previously was: ${value}".

On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote:

=========== w.r.t. 1.x tools ===============
(First: thanks for raising this issue and discussing it.)

---- Markdown support ----

Seems like the only feature missing from Markdown vs. the simplified HTML
support in 1.4.7 is font color. I do think this would be useful to add. I
miss having this on GitHub.

The downside of Markdown is it requires code to implement it. Android
provides Html.fromHtml(...) to manipulate HTML markup (
http://developer.android.com/reference/android/text/Html.html )

---- HTML support ----

If we are to allow HTML markup (everywhere), I think this might be
addressed with a tighter specification of what emits.

If we assume the creator of the form is never malicious and knows HTML,
the only thing we need to protect is the user-entered data, which would
always pass through before being injected into a label or hint. If
were guaranteed to always escape the special XML/HTML characters,
then wouldn't that be sufficient?

e.g., escaping similar to this:
https://github.com/janl/mustache.js/blob/master/mustache.js#L60

Currently, when the form is loaded, the JR code replaces the tag
with a ${ref} expression (
https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031
) And then when a label or hint is constructed, this code is used: (
https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878
).

That code could be changed to ensure that the values of the substitution
arguments are properly escaped. This would enable the label or hint to
contain arbitrary HTML.

This would be the minimal necessary JR/ODK Collect code change before the
1.4.7 build can be released.

=====2.0 tools=====
Each 2.0 tool -- Survey and Tables -- takes a different approach to
this. However, in general, it is coder-beware -- app developers (form
creators) need to do the right thing.

In ODK Tables, app developers write their own HTML and javascript. ODK
Tables provides minimal 'control' and 'data' object for getting rows of
data and for invoking ODK Collect or ODK Survey to fill in forms, and for
navigating to other list views / graph views or item views on the same base
table or another base table. It doesn't provide much else.

When creating content, ODK Tables app developers can use the
underscore.js library and its HTML escape function. We see this as a
best-practices documentation issue w.r.t. ODK Tables and its example apps.
The function exists; app creators should use that library and its function.

In ODK Survey, all page content is rendered through handlebars templates
( http://handlebarsjs.com/ ). The display text supplied in the XLSX file
is assumed to contain HTML markup. That markup is preserved via the
triple-mustache:
{{{ display.text }}}
construct. Within that display.text, if the creator of the form wants to
inject a value from the survey data, they would ordinarily use a
double-mustache (which escapes the value):
{{ data.fieldname }}
The ODK Survey code, however, simply accepts whatever the creator
specified. We expect the creator to understand the implications of each.
Again, it is a best-practices documentation issue.

On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert <cro...@surveycto.com wrote:

Where do the ODK 2.0 tools stand on this? Aren't they much more heavily
HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that
it's relevant to understanding the future impact of this decision.)

Chris

On Tue, Sep 1, 2015 at 1:03 PM mb...@ona.io wrote:

I personally like markdown. I agree with Martijn it keeps things
simple and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to support
markdown and an addition font / div tag but ignore the rest of html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word like
WARNING in red. If we get into stuff like tables I begin to worry about
formatting and we could just recommend using an image.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

[martijnr]

Great. I am planning to work on adding the lists (and now also span, and
headings if we're all okay with this) support next week. I could share the
link to the updated code and also to the test in this thread (it will move
to a different location, to the server). Will try to keep using easily
java-port-able regex replace functions. Will create an issue in xlsform.org
to update the docs when ready.

···

On Tuesday, September 1, 2015 at 6:47:33 PM UTC-6, Mitch wrote: > > Using a Java implementation of Enketo's markdown-to-html would be a slick > way of supporting markdown within ODK Collect. Very nice. > > XLSForm.org should specify exactly what is supported in either/both. No > opinions on what limits there should be, but generally agree with Martijn's > points re: usable stylings. > > > On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Thanks. Okay, color changing of sections within a label seems valuable. >> >> I've been trying to find out which HTML tags are allowed in markdown (and >> in which markdown 'spec'). I haven't found a definitive answer (this >> >> is the filter GitHub uses but this contains a strict and less-strict >> whitelist). >> >> I think we won't be able to find a library that supports the exact same >> subset for both Android and web (and iOS and ?) clients. However, if we are >> very strict about what we support, the # of lines of code required could be >> very limited (fwiw, this >> >> is the current code in Enketo - you could maybe even use this and apply >> Html.fromHtml() on the result ;)). >> >> I think span elements are maybe safe enough (in terms of malicious >> intent, stability, performance, accidentally breaking the DOM). So if >> supporting span elements in addition to the pure markdown (* _ * __ >> [link]() # ## ### ####) and two types of lists is a solution everybody can >> accept, I'd be happy with that compromise. You'd be able to use >> Html.fromHtml() for just the span elements perhaps? Would that cover the >> style attribute with all the css text styling options or just a subset of >> css values? >> >> I agree that user-entered data displayed in outputs should indeed not be >> formattable by the value (and escaped). Formatting could be done in the >> label like "The value you entered previously was: **${value}**". >> >> >> On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote: >>> >>> =========== w.r.t. 1.x tools =============== >>> (First: thanks for raising this issue and discussing it.) >>> >>> ---- Markdown support ---- >>> >>> Seems like the only feature missing from Markdown vs. the simplified >>> HTML support in 1.4.7 is font color. I do think this would be useful to >>> add. I miss having this on GitHub. >>> >>> The downside of Markdown is it requires code to implement it. Android >>> provides Html.fromHtml(...) to manipulate HTML markup ( >>> http://developer.android.com/reference/android/text/Html.html ) >>> >>> ---- HTML support ---- >>> >>> If we are to allow HTML markup (everywhere), I think this might be >>> addressed with a tighter specification of what emits. >>> >>> If we assume the creator of the form is never malicious and knows HTML, >>> the only thing we need to protect is the user-entered data, which would >>> always pass through before being injected into a label or hint. If >>> were guaranteed to always escape the special XML/HTML characters, >>> then wouldn't that be sufficient? >>> >>> e.g., escaping similar to this: >>> https://github.com/janl/mustache.js/blob/master/mustache.js#L60 >>> >>> Currently, when the form is loaded, the JR code replaces the >>> tag with a ${ref} expression ( >>> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031 >>> ) And then when a label or hint is constructed, this code is used: ( >>> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878 >>> ). >>> >>> That code could be changed to ensure that the values of the substitution >>> arguments are properly escaped. This would enable the label or hint to >>> contain arbitrary HTML. >>> >>> This would be the minimal necessary JR/ODK Collect code change before >>> the 1.4.7 build can be released. >>> >>> =====2.0 tools===== >>> Each 2.0 tool -- Survey and Tables -- takes a different approach to >>> this. However, in general, it is coder-beware -- app developers (form >>> creators) need to do the right thing. >>> >>> In ODK Tables, app developers write their own HTML and javascript. ODK >>> Tables provides minimal 'control' and 'data' object for getting rows of >>> data and for invoking ODK Collect or ODK Survey to fill in forms, and for >>> navigating to other list views / graph views or item views on the same base >>> table or another base table. It doesn't provide much else. >>> >>> When creating content, ODK Tables app developers can use the >>> underscore.js library and its HTML escape function. We see this as a >>> best-practices documentation issue w.r.t. ODK Tables and its example apps. >>> The function exists; app creators should use that library and its function. >>> >>> In ODK Survey, all page content is rendered through handlebars templates >>> ( http://handlebarsjs.com/ ). The display text supplied in the XLSX >>> file is assumed to contain HTML markup. That markup is preserved via the >>> triple-mustache: >>> {{{ display.text }}} >>> construct. Within that display.text, if the creator of the form wants to >>> inject a value from the survey data, they would ordinarily use a >>> double-mustache (which escapes the value): >>> {{ data.fieldname }} >>> The ODK Survey code, however, simply accepts whatever the creator >>> specified. We expect the creator to understand the implications of each. >>> Again, it is a best-practices documentation issue. >>> >>> >>> On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert < cro...@surveycto.com> wrote: >>> >>>> Where do the ODK 2.0 tools stand on this? Aren't they much more heavily >>>> HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that >>>> it's relevant to understanding the future impact of this decision.) >>>> >>>> Chris >>>> >>>> On Tue, Sep 1, 2015 at 1:03 PM wrote: >>>> >>>>> I personally like markdown. I agree with Martijn it keeps things >>>>> simple and avoids the risk that html can create. >>>>> >>>>> I realize it's a bit of a hack but one approach might be to support >>>>> markdown and an addition font / div tag but ignore the rest of html. >>>>> >>>>> >>>>> http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words >>>>> >>>>> Limited support for html where you support >>>>> * b, i and ul/li and font tags is the other option I guess. >>>>> >>>>> The main use case I see is people wanting to color a single word like >>>>> WARNING in red. If we get into stuff like tables I begin to worry about >>>>> formatting and we could just recommend using an image. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ODK Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >> >> -- >> *Revolutionizing data collection since 2012.* >> >> Enketo | LinkedIn >> | GitHub >> | Twitter >> | Blog >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

[yanokwa]

On our end, I'll look into what it'll take to add Markdown support.
Should know more in a few days.

Chris: Any chance you will want to support this in addition to HTML?

Matt: Can the XLSForm team add passthrough support for HTML tags like
span if we add them to Collect?

···

On Wed, Sep 2, 2015 at 1:07 PM, Martijn van de Rijdt wrote: > Great. I am planning to work on adding the lists (and now also span, and > headings if we're all okay with this) support next week. I could share the > link to the updated code and also to the test in this thread (it will move > to a different location, to the server). Will try to keep using easily > java-port-able regex replace functions. Will create an issue in xlsform.org > to update the docs when ready. > > On Tuesday, September 1, 2015 at 6:47:33 PM UTC-6, Mitch wrote: >> >> Using a Java implementation of Enketo's markdown-to-html would be a slick >> way of supporting markdown within ODK Collect. Very nice. >> >> XLSForm.org should specify exactly what is supported in either/both. No >> opinions on what limits there should be, but generally agree with Martijn's >> points re: usable stylings. >> >> >> On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt wrote: >>> >>> Thanks. Okay, color changing of sections within a label seems valuable. >>> >>> I've been trying to find out which HTML tags are allowed in markdown (and >>> in which markdown 'spec'). I haven't found a definitive answer (this is the >>> filter GitHub uses but this contains a strict and less-strict whitelist). >>> >>> I think we won't be able to find a library that supports the exact same >>> subset for both Android and web (and iOS and ?) clients. However, if we are >>> very strict about what we support, the # of lines of code required could be >>> very limited (fwiw, this is the current code in Enketo - you could maybe >>> even use this and apply Html.fromHtml() on the result ;)). >>> >>> I think span elements are maybe safe enough (in terms of malicious >>> intent, stability, performance, accidentally breaking the DOM). So if >>> supporting span elements in addition to the pure markdown (* _ * __ [link]() >>> # ## ### ####) and two types of lists is a solution everybody can accept, >>> I'd be happy with that compromise. You'd be able to use Html.fromHtml() for >>> just the span elements perhaps? Would that cover the style attribute with >>> all the css text styling options or just a subset of css values? >>> >>> I agree that user-entered data displayed in outputs should indeed not be >>> formattable by the value (and escaped). Formatting could be done in the >>> label like "The value you entered previously was: **${value}**". >>> >>> >>> On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote: >>>> >>>> =========== w.r.t. 1.x tools =============== >>>> (First: thanks for raising this issue and discussing it.) >>>> >>>> ---- Markdown support ---- >>>> >>>> Seems like the only feature missing from Markdown vs. the simplified >>>> HTML support in 1.4.7 is font color. I do think this would be useful to add. >>>> I miss having this on GitHub. >>>> >>>> The downside of Markdown is it requires code to implement it. Android >>>> provides Html.fromHtml(...) to manipulate HTML markup ( >>>> http://developer.android.com/reference/android/text/Html.html ) >>>> >>>> ---- HTML support ---- >>>> >>>> If we are to allow HTML markup (everywhere), I think this might be >>>> addressed with a tighter specification of what emits. >>>> >>>> If we assume the creator of the form is never malicious and knows HTML, >>>> the only thing we need to protect is the user-entered data, which would >>>> always pass through before being injected into a label or hint. If >>>> were guaranteed to always escape the special XML/HTML characters, >>>> then wouldn't that be sufficient? >>>> >>>> e.g., escaping similar to this: >>>> https://github.com/janl/mustache.js/blob/master/mustache.js#L60 >>>> >>>> Currently, when the form is loaded, the JR code replaces the >>>> tag with a ${ref} expression ( >>>> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031 >>>> ) And then when a label or hint is constructed, this code is used: ( >>>> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878 >>>> ). >>>> >>>> That code could be changed to ensure that the values of the substitution >>>> arguments are properly escaped. This would enable the label or hint to >>>> contain arbitrary HTML. >>>> >>>> This would be the minimal necessary JR/ODK Collect code change before >>>> the 1.4.7 build can be released. >>>> >>>> =====2.0 tools===== >>>> Each 2.0 tool -- Survey and Tables -- takes a different approach to >>>> this. However, in general, it is coder-beware -- app developers (form >>>> creators) need to do the right thing. >>>> >>>> In ODK Tables, app developers write their own HTML and javascript. ODK >>>> Tables provides minimal 'control' and 'data' object for getting rows of data >>>> and for invoking ODK Collect or ODK Survey to fill in forms, and for >>>> navigating to other list views / graph views or item views on the same base >>>> table or another base table. It doesn't provide much else. >>>> >>>> When creating content, ODK Tables app developers can use the >>>> underscore.js library and its HTML escape function. We see this as a >>>> best-practices documentation issue w.r.t. ODK Tables and its example apps. >>>> The function exists; app creators should use that library and its function. >>>> >>>> In ODK Survey, all page content is rendered through handlebars templates >>>> ( http://handlebarsjs.com/ ). The display text supplied in the XLSX file is >>>> assumed to contain HTML markup. That markup is preserved via the >>>> triple-mustache: >>>> {{{ display.text }}} >>>> construct. Within that display.text, if the creator of the form wants to >>>> inject a value from the survey data, they would ordinarily use a >>>> double-mustache (which escapes the value): >>>> {{ data.fieldname }} >>>> The ODK Survey code, however, simply accepts whatever the creator >>>> specified. We expect the creator to understand the implications of each. >>>> Again, it is a best-practices documentation issue. >>>> >>>> >>>> On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert wrote: >>>>> >>>>> Where do the ODK 2.0 tools stand on this? Aren't they much more heavily >>>>> HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I think that >>>>> it's relevant to understanding the future impact of this decision.) >>>>> >>>>> Chris >>>>> >>>>> On Tue, Sep 1, 2015 at 1:03 PM wrote: >>>>>> >>>>>> I personally like markdown. I agree with Martijn it keeps things >>>>>> simple and avoids the risk that html can create. >>>>>> >>>>>> I realize it's a bit of a hack but one approach might be to support >>>>>> markdown and an addition font / div tag but ignore the rest of html. >>>>>> >>>>>> >>>>>> http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words >>>>>> >>>>>> Limited support for html where you support >>>>>> * b, i and ul/li and font tags is the other option I guess. >>>>>> >>>>>> The main use case I see is people wanting to color a single word like >>>>>> WARNING in red. If we get into stuff like tables I begin to worry about >>>>>> formatting and we could just recommend using an image. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ODK Developers" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ODK Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>>> >>>> -- >>>> Mitch Sundt >>>> Software Engineer >>>> University of Washington >>>> mitche...@gmail.com >>> >>> >>> -- >>> Revolutionizing data collection since 2012. >>> >>> Enketo | LinkedIn | GitHub | Twitter | Blog >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitche...@gmail.com > > > -- > Revolutionizing data collection since 2012. > > Enketo | LinkedIn | GitHub | Twitter | Blog > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

[crobert]

We don't have the bandwidth to implement markdown support in our upcoming
2.0 release and, frankly, haven't had much user demand for this. We can try
to squeeze it into our 2.1 release if that's the consensus for the ODK
family moving forward.

Thanks,

Chris

···

On Mon, Sep 7, 2015 at 11:43 AM Yaw Anokwa wrote:

On our end, I'll look into what it'll take to add Markdown support.
Should know more in a few days.

Chris: Any chance you will want to support this in addition to HTML?

Matt: Can the XLSForm team add passthrough support for HTML tags like
span if we add them to Collect?

On Wed, Sep 2, 2015 at 1:07 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Great. I am planning to work on adding the lists (and now also span, and
headings if we're all okay with this) support next week. I could share
the
link to the updated code and also to the test in this thread (it will
move
to a different location, to the server). Will try to keep using easily
java-port-able regex replace functions. Will create an issue in
xlsform.org
to update the docs when ready.

On Tuesday, September 1, 2015 at 6:47:33 PM UTC-6, Mitch wrote:

Using a Java implementation of Enketo's markdown-to-html would be a
slick
way of supporting markdown within ODK Collect. Very nice.

XLSForm.org should specify exactly what is supported in either/both. No
opinions on what limits there should be, but generally agree with
Martijn's
points re: usable stylings.

On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt <mar...@enketo.org wrote:

Thanks. Okay, color changing of sections within a label seems valuable.

I've been trying to find out which HTML tags are allowed in markdown
(and
in which markdown 'spec'). I haven't found a definitive answer (this
is the
filter GitHub uses but this contains a strict and less-strict
whitelist).

I think we won't be able to find a library that supports the exact same
subset for both Android and web (and iOS and ?) clients. However, if
we are
very strict about what we support, the # of lines of code required
could be
very limited (fwiw, this is the current code in Enketo - you could
maybe
even use this and apply Html.fromHtml() on the result ;)).

I think span elements are maybe safe enough (in terms of malicious
intent, stability, performance, accidentally breaking the DOM). So if
supporting span elements in addition to the pure markdown (* _ * __
link

## ### ####) and two types of lists is a solution everybody can

accept,

I'd be happy with that compromise. You'd be able to use
Html.fromHtml() for
just the span elements perhaps? Would that cover the style attribute
with
all the css text styling options or just a subset of css values?

I agree that user-entered data displayed in outputs should indeed not
be
formattable by the value (and escaped). Formatting could be done in the
label like "The value you entered previously was: ${value}".

On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote:

=========== w.r.t. 1.x tools ===============
(First: thanks for raising this issue and discussing it.)

---- Markdown support ----

Seems like the only feature missing from Markdown vs. the simplified
HTML support in 1.4.7 is font color. I do think this would be useful
to add.
I miss having this on GitHub.

The downside of Markdown is it requires code to implement it. Android
provides Html.fromHtml(...) to manipulate HTML markup (
http://developer.android.com/reference/android/text/Html.html )

---- HTML support ----

If we are to allow HTML markup (everywhere), I think this might be
addressed with a tighter specification of what emits.

If we assume the creator of the form is never malicious and knows
HTML,
the only thing we need to protect is the user-entered data, which
would
always pass through before being injected into a label or
hint. If
were guaranteed to always escape the special XML/HTML
characters,
then wouldn't that be sufficient?

e.g., escaping similar to this:
https://github.com/janl/mustache.js/blob/master/mustache.js#L60

Currently, when the form is loaded, the JR code replaces the
tag with a ${ref} expression (

https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031

) And then when a label or hint is constructed, this code is used: (

https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878

).

That code could be changed to ensure that the values of the
substitution
arguments are properly escaped. This would enable the label or hint to
contain arbitrary HTML.

This would be the minimal necessary JR/ODK Collect code change before
the 1.4.7 build can be released.

=====2.0 tools=====
Each 2.0 tool -- Survey and Tables -- takes a different approach to
this. However, in general, it is coder-beware -- app developers (form
creators) need to do the right thing.

In ODK Tables, app developers write their own HTML and javascript.
ODK
Tables provides minimal 'control' and 'data' object for getting rows
of data
and for invoking ODK Collect or ODK Survey to fill in forms, and for
navigating to other list views / graph views or item views on the
same base
table or another base table. It doesn't provide much else.

When creating content, ODK Tables app developers can use the
underscore.js library and its HTML escape function. We see this as a
best-practices documentation issue w.r.t. ODK Tables and its example
apps.
The function exists; app creators should use that library and its
function.

In ODK Survey, all page content is rendered through handlebars
templates
( http://handlebarsjs.com/ ). The display text supplied in the XLSX
file is
assumed to contain HTML markup. That markup is preserved via the
triple-mustache:
{{{ display.text }}}
construct. Within that display.text, if the creator of the form wants
to
inject a value from the survey data, they would ordinarily use a
double-mustache (which escapes the value):
{{ data.fieldname }}
The ODK Survey code, however, simply accepts whatever the creator
specified. We expect the creator to understand the implications of
each.
Again, it is a best-practices documentation issue.

On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert cro...@surveycto.com wrote:

Where do the ODK 2.0 tools stand on this? Aren't they much more
heavily
HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I
think that
it's relevant to understanding the future impact of this decision.)

Chris

On Tue, Sep 1, 2015 at 1:03 PM mb...@ona.io wrote:

I personally like markdown. I agree with Martijn it keeps things
simple and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to support
markdown and an addition font / div tag but ignore the rest of html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word
like
WARNING in red. If we get into stuff like tables I begin to worry
about
formatting and we could just recommend using an image.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[martijnr]

I've added the additional markdown support to Enketo.

• This is the code
  https://github.com/enketo/enketo-transformer/blob/master/src/markdown.js (easier
  to port than the previous code)
• These are the tests
  https://github.com/enketo/enketo-transformer/blob/master/test/markdown.spec.js#L13-L82
  .
• This is a somewhat useful test XLSForm
  https://docs.google.com/spreadsheets/d/1Yl5vVVTn-_rNQLd4JanJQlVgiUdpt6MJgozEa4YLFSg/edit?usp=sharing

With these regex replacements no changes in Pyxform are required to
pass-through span elements with a style attribute. They will convert
<span style=""> span (as well as ). Any non-style
attributes are stripped from the span elements (some attributes would allow
js to run).

The code will probably be tweaked a bit in the next week while testing it
further. I hope it is of use.

Does this subset of markdown make sense?

···

On Monday, September 7, 2015 at 10:00:44 AM UTC-6, Christopher Robert wrote: > > We don't have the bandwidth to implement markdown support in our upcoming > 2.0 release and, frankly, haven't had much user demand for this. We can try > to squeeze it into our 2.1 release if that's the consensus for the ODK > family moving forward. > > Thanks, > > Chris > > > On Mon, Sep 7, 2015 at 11:43 AM Yaw Anokwa <yan...@nafundi.com > wrote: > >> On our end, I'll look into what it'll take to add Markdown support. >> Should know more in a few days. >> >> Chris: Any chance you will want to support this in addition to HTML? >> >> Matt: Can the XLSForm team add passthrough support for HTML tags like >> span if we add them to Collect? >> >> On Wed, Sep 2, 2015 at 1:07 PM, Martijn van de Rijdt <mar...@enketo.org > wrote: >> > Great. I am planning to work on adding the lists (and now also span, and >> > headings if we're all okay with this) support next week. I could share >> the >> > link to the updated code and also to the test in this thread (it will >> move >> > to a different location, to the server). Will try to keep using easily >> > java-port-able regex replace functions. Will create an issue in >> xlsform.org >> > to update the docs when ready. >> > >> > On Tuesday, September 1, 2015 at 6:47:33 PM UTC-6, Mitch wrote: >> >> >> >> Using a Java implementation of Enketo's markdown-to-html would be a >> slick >> >> way of supporting markdown within ODK Collect. Very nice. >> >> >> >> XLSForm.org should specify exactly what is supported in either/both. No >> >> opinions on what limits there should be, but generally agree with >> Martijn's >> >> points re: usable stylings. >> >> >> >> >> >> On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt < mar...@enketo.org> wrote: >> >>> >> >>> Thanks. Okay, color changing of sections within a label seems >> valuable. >> >>> >> >>> I've been trying to find out which HTML tags are allowed in markdown >> (and >> >>> in which markdown 'spec'). I haven't found a definitive answer (this >> is the >> >>> filter GitHub uses but this contains a strict and less-strict >> whitelist). >> >>> >> >>> I think we won't be able to find a library that supports the exact >> same >> >>> subset for both Android and web (and iOS and ?) clients. However, if >> we are >> >>> very strict about what we support, the # of lines of code required >> could be >> >>> very limited (fwiw, this is the current code in Enketo - you could >> maybe >> >>> even use this and apply Html.fromHtml() on the result ;)). >> >>> >> >>> I think span elements are maybe safe enough (in terms of malicious >> >>> intent, stability, performance, accidentally breaking the DOM). So if >> >>> supporting span elements in addition to the pure markdown (* _ * __ >> [link]() >> >>> # ## ### ####) and two types of lists is a solution everybody can >> accept, >> >>> I'd be happy with that compromise. You'd be able to use >> Html.fromHtml() for >> >>> just the span elements perhaps? Would that cover the style attribute >> with >> >>> all the css text styling options or just a subset of css values? >> >>> >> >>> I agree that user-entered data displayed in outputs should indeed not >> be >> >>> formattable by the value (and escaped). Formatting could be done in >> the >> >>> label like "The value you entered previously was: **${value}**". >> >>> >> >>> >> >>> On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote: >> >>>> >> >>>> =========== w.r.t. 1.x tools =============== >> >>>> (First: thanks for raising this issue and discussing it.) >> >>>> >> >>>> ---- Markdown support ---- >> >>>> >> >>>> Seems like the only feature missing from Markdown vs. the simplified >> >>>> HTML support in 1.4.7 is font color. I do think this would be useful >> to add. >> >>>> I miss having this on GitHub. >> >>>> >> >>>> The downside of Markdown is it requires code to implement it. Android >> >>>> provides Html.fromHtml(...) to manipulate HTML markup ( >> >>>> http://developer.android.com/reference/android/text/Html.html ) >> >>>> >> >>>> ---- HTML support ---- >> >>>> >> >>>> If we are to allow HTML markup (everywhere), I think this might be >> >>>> addressed with a tighter specification of what emits. >> >>>> >> >>>> If we assume the creator of the form is never malicious and knows >> HTML, >> >>>> the only thing we need to protect is the user-entered data, which >> would >> >>>> always pass through before being injected into a label or >> hint. If >> >>>> were guaranteed to always escape the special XML/HTML >> characters, >> >>>> then wouldn't that be sufficient? >> >>>> >> >>>> e.g., escaping similar to this: >> >>>> https://github.com/janl/mustache.js/blob/master/mustache.js#L60 >> >>>> >> >>>> Currently, when the form is loaded, the JR code replaces the >> >>>> tag with a ${ref} expression ( >> >>>> >> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031 >> >>>> ) And then when a label or hint is constructed, this code is used: ( >> >>>> >> https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878 >> >>>> ). >> >>>> >> >>>> That code could be changed to ensure that the values of the >> substitution >> >>>> arguments are properly escaped. This would enable the label or hint >> to >> >>>> contain arbitrary HTML. >> >>>> >> >>>> This would be the minimal necessary JR/ODK Collect code change before >> >>>> the 1.4.7 build can be released. >> >>>> >> >>>> =====2.0 tools===== >> >>>> Each 2.0 tool -- Survey and Tables -- takes a different approach to >> >>>> this. However, in general, it is coder-beware -- app developers >> (form >> >>>> creators) need to do the right thing. >> >>>> >> >>>> In ODK Tables, app developers write their own HTML and javascript. >> ODK >> >>>> Tables provides minimal 'control' and 'data' object for getting rows >> of data >> >>>> and for invoking ODK Collect or ODK Survey to fill in forms, and for >> >>>> navigating to other list views / graph views or item views on the >> same base >> >>>> table or another base table. It doesn't provide much else. >> >>>> >> >>>> When creating content, ODK Tables app developers can use the >> >>>> underscore.js library and its HTML escape function. We see this as a >> >>>> best-practices documentation issue w.r.t. ODK Tables and its example >> apps. >> >>>> The function exists; app creators should use that library and its >> function. >> >>>> >> >>>> In ODK Survey, all page content is rendered through handlebars >> templates >> >>>> ( http://handlebarsjs.com/ ). The display text supplied in the XLSX >> file is >> >>>> assumed to contain HTML markup. That markup is preserved via the >> >>>> triple-mustache: >> >>>> {{{ display.text }}} >> >>>> construct. Within that display.text, if the creator of the form >> wants to >> >>>> inject a value from the survey data, they would ordinarily use a >> >>>> double-mustache (which escapes the value): >> >>>> {{ data.fieldname }} >> >>>> The ODK Survey code, however, simply accepts whatever the creator >> >>>> specified. We expect the creator to understand the implications of >> each. >> >>>> Again, it is a best-practices documentation issue. >> >>>> >> >>>> >> >>>> On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert wrote: >> >>>>> >> >>>>> Where do the ODK 2.0 tools stand on this? Aren't they much more >> heavily >> >>>>> HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I >> think that >> >>>>> it's relevant to understanding the future impact of this decision.) >> >>>>> >> >>>>> Chris >> >>>>> >> >>>>> On Tue, Sep 1, 2015 at 1:03 PM wrote: >> >>>>>> >> >>>>>> I personally like markdown. I agree with Martijn it keeps things >> >>>>>> simple and avoids the risk that html can create. >> >>>>>> >> >>>>>> I realize it's a bit of a hack but one approach might be to support >> >>>>>> markdown and an addition font / div tag but ignore the rest of >> html. >> >>>>>> >> >>>>>> >> >>>>>> >> http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words >> >>>>>> >> >>>>>> Limited support for html where you support >> >>>>>> * b, i and ul/li and font tags is the other option I guess. >> >>>>>> >> >>>>>> The main use case I see is people wanting to color a single word >> like >> >>>>>> WARNING in red. If we get into stuff like tables I begin to worry >> about >> >>>>>> formatting and we could just recommend using an image. >> >>>>>> >> >>>>>> -- >> >>>>>> You received this message because you are subscribed to the Google >> >>>>>> Groups "ODK Developers" group. >> >>>>>> To unsubscribe from this group and stop receiving emails from it, >> send >> >>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> >>>>>> For more options, visit https://groups.google.com/d/optout. >> >>>>> >> >>>>> -- >> >>>>> You received this message because you are subscribed to the Google >> >>>>> Groups "ODK Developers" group. >> >>>>> To unsubscribe from this group and stop receiving emails from it, >> send >> >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> >>>>> For more options, visit https://groups.google.com/d/optout. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Mitch Sundt >> >>>> Software Engineer >> >>>> University of Washington >> >>>> mitche...@gmail.com >> >>> >> >>> >> >>> -- >> >>> Revolutionizing data collection since 2012. >> >>> >> >>> Enketo | LinkedIn | GitHub | Twitter | Blog >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups >> >>> "ODK Developers" group. >> >>> To unsubscribe from this group and stop receiving emails from it, >> send an >> >>> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> >> -- >> >> Mitch Sundt >> >> Software Engineer >> >> University of Washington >> >> mitche...@gmail.com >> > >> > >> > -- >> > Revolutionizing data collection since 2012. >> > >> > Enketo | LinkedIn | GitHub | Twitter | Blog >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >

[yanokwa]

Hi all,

Markdown support is now ready for code review and testing at
https://github.com/opendatakit/collect/pull/7. The pull request
enables strong, emphasis, links, headers, paragraphs, and spans. Can
the folks who wanted it (cc'ed) please test?

Thanks,

Yaw

···

-- Need ODK consultants? https://nafundi.com provides form design, server setup, in-field training, and software development for ODK.

On Wed, Sep 9, 2015 at 6:55 AM, Martijn van de Rijdt martijn@enketo.org wrote:

I've added the additional markdown support to Enketo.

This is the code (easier to port than the previous code)
These are the tests.
This is a somewhat useful test XLSForm

With these regex replacements no changes in Pyxform are required to
pass-through span elements with a style attribute. They will convert
<span style=""> span (as well as ). Any non-style
attributes are stripped from the span elements (some attributes would allow
js to run).

The code will probably be tweaked a bit in the next week while testing it
further. I hope it is of use.

Does this subset of markdown make sense?

On Monday, September 7, 2015 at 10:00:44 AM UTC-6, Christopher Robert wrote:

We don't have the bandwidth to implement markdown support in our upcoming
2.0 release and, frankly, haven't had much user demand for this. We can try
to squeeze it into our 2.1 release if that's the consensus for the ODK
family moving forward.

Thanks,

Chris

On Mon, Sep 7, 2015 at 11:43 AM Yaw Anokwa yan...@nafundi.com wrote:

On our end, I'll look into what it'll take to add Markdown support.
Should know more in a few days.

Chris: Any chance you will want to support this in addition to HTML?

Matt: Can the XLSForm team add passthrough support for HTML tags like
span if we add them to Collect?

On Wed, Sep 2, 2015 at 1:07 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Great. I am planning to work on adding the lists (and now also span,
and
headings if we're all okay with this) support next week. I could share
the
link to the updated code and also to the test in this thread (it will
move
to a different location, to the server). Will try to keep using easily
java-port-able regex replace functions. Will create an issue in
xlsform.org
to update the docs when ready.

On Tuesday, September 1, 2015 at 6:47:33 PM UTC-6, Mitch wrote:

Using a Java implementation of Enketo's markdown-to-html would be a
slick
way of supporting markdown within ODK Collect. Very nice.

XLSForm.org should specify exactly what is supported in either/both.
No
opinions on what limits there should be, but generally agree with
Martijn's
points re: usable stylings.

On Tue, Sep 1, 2015 at 4:12 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Thanks. Okay, color changing of sections within a label seems
valuable.

I've been trying to find out which HTML tags are allowed in markdown
(and
in which markdown 'spec'). I haven't found a definitive answer (this
is the
filter GitHub uses but this contains a strict and less-strict
whitelist).

I think we won't be able to find a library that supports the exact
same
subset for both Android and web (and iOS and ?) clients. However, if
we are
very strict about what we support, the # of lines of code required
could be
very limited (fwiw, this is the current code in Enketo - you could
maybe
even use this and apply Html.fromHtml() on the result ;)).

I think span elements are maybe safe enough (in terms of malicious
intent, stability, performance, accidentally breaking the DOM). So if
supporting span elements in addition to the pure markdown (* _ * __
link

## ### ####) and two types of lists is a solution everybody can

accept,
I'd be happy with that compromise. You'd be able to use
Html.fromHtml() for
just the span elements perhaps? Would that cover the style attribute
with
all the css text styling options or just a subset of css values?

I agree that user-entered data displayed in outputs should indeed not
be
formattable by the value (and escaped). Formatting could be done in
the
label like "The value you entered previously was: ${value}".

On Tuesday, September 1, 2015 at 1:25:21 PM UTC-6, Mitch wrote:

=========== w.r.t. 1.x tools ===============
(First: thanks for raising this issue and discussing it.)

---- Markdown support ----

Seems like the only feature missing from Markdown vs. the simplified
HTML support in 1.4.7 is font color. I do think this would be useful
to add.
I miss having this on GitHub.

The downside of Markdown is it requires code to implement it.
Android
provides Html.fromHtml(...) to manipulate HTML markup (
http://developer.android.com/reference/android/text/Html.html )

---- HTML support ----

If we are to allow HTML markup (everywhere), I think this might be
addressed with a tighter specification of what emits.

If we assume the creator of the form is never malicious and knows
HTML,
the only thing we need to protect is the user-entered data, which
would
always pass through before being injected into a label or
hint. If
were guaranteed to always escape the special XML/HTML
characters,
then wouldn't that be sufficient?

e.g., escaping similar to this:
https://github.com/janl/mustache.js/blob/master/mustache.js#L60

Currently, when the form is loaded, the JR code replaces the

tag with a ${ref} expression (

https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/xform/parse/XFormParser.java?at=default#XFormParser.java-1031
) And then when a label or hint is constructed, this code is used: (

https://bitbucket.org/m.sundt/javarosa/src/a7674dd36979a53ae4e85aac3aa4e6d8ce5a83e0/core/src/org/javarosa/core/model/FormDef.java?at=default#FormDef.java-878
).

That code could be changed to ensure that the values of the
substitution
arguments are properly escaped. This would enable the label or hint
to
contain arbitrary HTML.

This would be the minimal necessary JR/ODK Collect code change
before
the 1.4.7 build can be released.

=====2.0 tools=====
Each 2.0 tool -- Survey and Tables -- takes a different approach to
this. However, in general, it is coder-beware -- app developers
(form
creators) need to do the right thing.

In ODK Tables, app developers write their own HTML and javascript.
ODK
Tables provides minimal 'control' and 'data' object for getting rows
of data
and for invoking ODK Collect or ODK Survey to fill in forms, and for
navigating to other list views / graph views or item views on the
same base
table or another base table. It doesn't provide much else.

When creating content, ODK Tables app developers can use the
underscore.js library and its HTML escape function. We see this as a
best-practices documentation issue w.r.t. ODK Tables and its example
apps.
The function exists; app creators should use that library and its
function.

In ODK Survey, all page content is rendered through handlebars
templates
( http://handlebarsjs.com/ ). The display text supplied in the XLSX
file is
assumed to contain HTML markup. That markup is preserved via the
triple-mustache:
{{{ display.text }}}
construct. Within that display.text, if the creator of the form
wants to
inject a value from the survey data, they would ordinarily use a
double-mustache (which escapes the value):
{{ data.fieldname }}
The ODK Survey code, however, simply accepts whatever the creator
specified. We expect the creator to understand the implications of
each.
Again, it is a best-practices documentation issue.

On Tue, Sep 1, 2015 at 10:05 AM, Christopher Robert cro...@surveycto.com wrote:

Where do the ODK 2.0 tools stand on this? Aren't they much more
heavily
HTML+JS-based? (Obviously ODK 2.0 support isn't decisive, but I
think that
it's relevant to understanding the future impact of this decision.)

Chris

On Tue, Sep 1, 2015 at 1:03 PM mb...@ona.io wrote:

I personally like markdown. I agree with Martijn it keeps things
simple and avoids the risk that html can create.

I realize it's a bit of a hack but one approach might be to
support
markdown and an addition font / div tag but ignore the rest of
html.

http://answers.squarespace.com/questions/31631/how-to-change-font-type-and-colour-for-a-few-words

Limited support for html where you support

• b, i and ul/li and font tags is the other option I guess.

The main use case I see is people wanting to color a single word
like
WARNING in red. If we get into stuff like tables I begin to worry
about
formatting and we could just recommend using an image.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.