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:
- Enketo has supported Markdown since 2013
- Markdown has been documented in the XLSForm spec for a
while: http://xlsform.org/#styling
- Markdown is easier for users than HTML or BBCode.
- 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.
- 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.
>>
>