global form style

[MartijnR]

To allow form theming, right-align language, other custom form appearance, it would be great to have a form-wide appearance attribute.

Would this be a worthwhile addition to pyxforms? If so, what would be the best way to implement this, perhaps an appearance column in the settings tab and adding the appearance attribute(s) to the <h:body> element?

[MartijnR]

Does this seem worthwhile and do-able? @prabhasp @ukanga @nathanathan

[nathanathan]

I'm no longer working at the uw so it would be best to bring in @mitchellsundt on questions like this. Anyways, here's my 2 cents: I think language.text-align columns on the settings sheet with defaults like you mentioned would be a good way to organize the xlsform. I don't think hiding hints is useful because there's always a chance someone misses something important in one. For other appearance attributes I would suggest letting users specify a css file for enketo to use rather than putting them in the xlsform.

[MartijnR]

Ah didn't know you were no longer there! Thanks for replying.

I was thinking a more general appearance column, that could be used for anything (theming, text-align, anything) would be useful. This could work in the same flexible manner as appearances for form fields (by just accepting everything).

[mitchellsundt]

Eventually, XLSForm needs to be changed to produce a zip file containing the XML and extra CSV files (or it needs a multi-step file-download process) for the new external choice list feature in 1.4.

In that case, it could perhaps emit a css file or other files from the XML.

I have not seen the original post on this thread

On Fri, Sep 6, 2013 at 12:04 PM, Martijn van de Rijdt (reserved account) < notifications@github.com> wrote:

Ah didn't know you were no longer there! Thanks for replying.

I was thinking a more general appearance column, that could be used for anything (theming, text-align, anything) would be useful. This could work in the same flexible manner as appearances for form fields (by just accepting everything).

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-23962184 .

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

[MartijnR]

Thanks Mitch,

This was the OP:

To allow form theming, right-align language, and other global custom form appearance changes. it would be great to have a form-wide appearance attribute.

Would this be a worthwhile addition to pyxforms? If so, what would be the best way to implement this, perhaps an appearance column in the XLS Form settings tab and adding the appearance attribute(s) to the element?

Afterwards, we could agree on some standard values (with comparable behavior in ODK Collect, Enketo and other clients such as 'right-align'), though that it is not an immediate concern.

On Thu, Sep 12, 2013 at 1:41 PM, Mitch Sundt notifications@github.comwrote:

Eventually, XLSForm needs to be changed to produce a zip file containing the XML and extra CSV files (or it needs a multi-step file-download process) for the new external choice list feature in 1.4.

In that case, it could perhaps emit a css file or other files from the XML.

I have not seen the original post on this thread

On Fri, Sep 6, 2013 at 12:04 PM, Martijn van de Rijdt (reserved account) < notifications@github.com> wrote:

Ah didn't know you were no longer there! Thanks for replying.

I was thinking a more general appearance column, that could be used for anything (theming, text-align, anything) would be useful. This could work in the same flexible manner as appearances for form fields (by just accepting everything).

— Reply to this email directly or view it on GitHub< https://github.com/modilabs/pyxform/issues/100#issuecomment-23962184> .

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

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-24349761 .

Enketo https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc | GitHub https://github.com/MartijnR

[MartijnR]

Ah, OK.

Because there is limited customization available in ODK Collect, it might be good to have this be one of a handful of well-known style classes, with specific renderings within ODK Collect. A settings tab style value could be applied to the h:body. Within the survey tab, the style column value could be applied to the respective XML elements.

If users wanted to customize styles, they could have a space-separated list of style classes. For ODK Collect, only the set of well-known style classes would be recognized and applied. The mapping of style classes to rendering attributes would be specified within a separate CSS file. Not sure if JR complains if it gets a element in the HTML or not.

I would expect the ODK Collect styles would be non-overlapping rendering behaviors so you could tell by what style was most specific how to render the given widget.

Mitch

On Thu, Sep 12, 2013 at 2:56 PM, Martijn van de Rijdt martijn@enketo.orgwrote:

Thanks Mitch,

This was the OP:

To allow form theming, right-align language, and other global custom form appearance changes. it would be great to have a form-wide appearance attribute.

Would this be a worthwhile addition to pyxforms? If so, what would be the best way to implement this, perhaps an appearance column in the XLS Form settings tab and adding the appearance attribute(s) to the element?

Afterwards, we could agree on some standard values (with comparable behavior in ODK Collect, Enketo and other clients such as 'right-align'), though that it is not an immediate concern.

On Thu, Sep 12, 2013 at 1:41 PM, Mitch Sundt notifications@github.comwrote:

Eventually, XLSForm needs to be changed to produce a zip file containing the XML and extra CSV files (or it needs a multi-step file-download process) for the new external choice list feature in 1.4.

In that case, it could perhaps emit a css file or other files from the XML.

I have not seen the original post on this thread

On Fri, Sep 6, 2013 at 12:04 PM, Martijn van de Rijdt (reserved account) < notifications@github.com> wrote:

Ah didn't know you were no longer there! Thanks for replying.

I was thinking a more general appearance column, that could be used for anything (theming, text-align, anything) would be useful. This could work in the same flexible manner as appearances for form fields (by just accepting everything).

— Reply to this email directly or view it on GitHub< https://github.com/modilabs/pyxform/issues/100#issuecomment-23962184> .

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

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-24349761 .

Enketo https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc | GitHub https://github.com/MartijnR

Mitch Sundt Software Engineer http://www.OpenDataKit.org http://www.opendatakit.org/ University of Washington mitchellsundt@gmail.com

[MartijnR]

Thanks @mitchellsundt,

Yes, would be great to as far as possible agree on common styles. Indeed, if a style is unknown by a client app, it would simply do nothing special and render the default style.

Don't think we should/need to add a <link> element to the output, although I agree this would perhaps be nice semantically. I would prefer using an appearance="" attribute for this since it's already used within the XForm format for input level styles. Applying it as an Attribute to h:body ( <h:body appearance="mycoolstyle right-align"> would make it global.

That said if you prefer <h:link>, it's fine with me! :)

[mitchellsundt]

I am against having styles be in the appearance attribute.

I think of appearance as defining what widgets are rendered (though that gets blurred with grid layouts with column-count specifications). To my mind that is different than how those widgets are rendered.

It also makes parsing appearance harder.

I've been talking to Christopher Roberts about passing arbitrary values into external intents via an extension of the external app widgets. An example might be:

<input appearance="ex:meletis.test.JOINALL(param1= /externalexample/consent , param2='----', param3=random())" ref="/externalexample/external">

Click launch to see an external-fetched string

    </input>

Here, the argument list to the external intent defines expressions to supply for param1, param2 and param3, in addition to passing the value of the 'external' field to that intent.

If we added rendering styles to this expression, it would become very difficult to figure out how to parse it.

On Fri, Sep 13, 2013 at 7:56 AM, Martijn van de Rijdt < notifications@github.com> wrote:

Thanks @mitchellsundt https://github.com/mitchellsundt,

Yes, would be great to as far as possible agree on common styles. Indeed, if a style is unknown by a client app, it would simply do nothing special and render the default style.

Don't think we should/need to add a element to the output, although I agree this would perhaps be nice semantically. I would prefer using an appearance="" attribute for this since it's already used within the XForm format for input level styles. Applying it as an Attribute to h:body ( would make it global.

That said if you prefer , it's fine with me! :)

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-24400224 .

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

[MartijnR]

@mitchellsundt

Ah, yes, I see where you're coming from. Makes sense and agreed.

So a <h:link rel="stylesheet" tyle="text/css" href="mystyle.css"> inside h:head? (one for each space-separated style from the XLS sheet)

Alternatively, and maybe easier, we could also use a class attribute on the h:body element <h:body class="mystyle right-align">. This may be a bit closer to how it most likely will be implemented in css. (Also less chance for throwing off JR libraries, perhaps?).

Both options would be fine with me and would be no problem to quickly implement with XSLT (used to transform XML to HTML in enketo). In both cases, I think I would add the styles as name-spaced classes to the body element with XSLT.

[mitchellsundt]

Yes, I'm thinking there would be a class="..." attribute emitted that would contain the content of the 'style' column from the survey sheet in the XLS file.

The 'style' value from the settings sheet would become a class="" attribute on the h:body.

I am less certain how or whether to handle declaring and emitting the

entry(ies) in the XLS file and XLSForm. I think that depends upon whether JR ignores them and if it is useful to you to allow people to name their css files (it would be yet another setting in the settings sheet ... e.g., css-filename | blah.css ). Otherwise, it could be a static part of your XLST. If the css file can't be loaded, it is then just a silent failure during the rendering process. On Fri, Sep 13, 2013 at 9:29 AM, Martijn van de Rijdt < notifications@github.com> wrote: > @mitchellsundt https://github.com/mitchellsundt > > Ah, yes, I see where you're coming from. Makes sense and agreed. > > So a inside > h:head? (one for each space-separated style from the XLS sheet) > > Alternatively, and maybe easier, we could also use a class attribute on > the h:body element . This may be a > bit closer to how it most likely will be implemented in css. (Also less > chance for throwing off JR libraries, perhaps?). > > Both options would be fine with me and would be no problem to quickly > implement with XSLT (used to transform XML to HTML in enketo). In both > cases, I think I would add the styles as a or-name-spaced class to the body > element with XSLT. > > — > Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-24406891 > . ## Mitch Sundt Software Engineer University of Washington mitchellsundt@gmail.com

[MartijnR]

Ah I think you're going even further by allowing users to add stylesheet to a client themselves!

I was actually just referring to some pre-defined classes that are built-in to ODK Colllect / Enketo. That makes it a lot easier for us (and avoids ugliness and support headaches ;) )

If a user adds a style name that doesn't exist in the client nothing special happens. Defaults are loaded and no errors.

FYI, the new martijnr/enketo-core repo will make it easy for (css-skilled) designers to create their own themes (and send a pull request which will, once approved, then get incorporated into the app for everybody). Not expecting many pull requests for this though ;).

[mitchellsundt]

Ok. We won't do any entries, just the style element.

On Fri, Sep 13, 2013 at 10:46 AM, Martijn van de Rijdt < notifications@github.com> wrote:

Ah I think you're going even further by allowing users to add stylesheet to a client themselves!

I was actually just referring to some pre-defined classes that are built-in to ODK Colllect / Enketo. That makes it a lot easier for us (and avoids ugliness and support headaches ;) )

If a user adds a style name that doesn't exist in the client nothing special happens. Defaults are loaded and no errors.

FYI, the new martijnr/enketo-core repo will make it easy for (css-skilled) designers to create their own themes (and send a pull request which will, once approved, then get incorporated into the app for everybody). Not expecting many pull requests for this though ;).

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/100#issuecomment-24411922 .

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

[MartijnR]

Sorry for the confusion @larryweya, @ukanga:

style column in XLS Form becomes class attribute on h:body in XForm.

[MartijnR]

done. Thanks!