search

snaekobbi / pipeline-mod-braille

ARCHIVED. Please don't make any new issues or pull requests in this repo.
0 stars 0 forks source link

dtbook-to-pef: "stylesheet" option should be a sequence of CSS-files instead of a string #61

Open josteinaj opened 8 years ago

josteinaj commented 8 years ago

This would allow the user to pick CSS files using the correct widget.

bertfrees commented 8 years ago

What would this mean in practice?

Currently the option is defined as followed:

CSS style sheets to apply. Space separated list of absolute or relative URIs. Applied prior to any style sheets linked from or embedded in the source document.

In other words, it can reference a file in the context (relative URI) or a stylesheet defined in the system (absolute URI).

josteinaj commented 8 years ago

Yes. In practice you would no longer be able to reference absolute URIs, but referencing relative URIs would be simpler (no typing, no typos).

bertfrees commented 8 years ago

Hmm, I don't know. This would seriously limit the possibilities of the option.

Isn't this essentially a user interface problem? Or rather, the problem of not being able to express what the option means? The user interface doesn't know that the option can be a file or a list of files. We can solve this by adding a px:input attribute but that is not correct either because it would indeed mean absolute URIs are not allowed anymore.

What if we make up a new data-type which is an extension of the choice element which we already have, but we allow alternating the value elements with data elements and we treat some predefined types such as px:input specially:

<choice id="css:stylesheet">
  <data datatypeLibrary="http://www.daisy.org/ns/pipeline/xproc" type="input"/>
  <value>http://www.nlb.no/pipeline/modules/braille/default.css</value>
  <value>http://www.sbs.ch/pipeline/modules/braille/default.css</value>
</choice>

Or, more correct would be (using even more RNG syntax):

<oneOrMore id="css:stylesheet">
  <choice>
    <data datatypeLibrary="http://www.daisy.org/ns/pipeline/xproc" type="input"/>
    <value>http://www.nlb.no/pipeline/modules/braille/default.css</value>
    <value>http://www.sbs.ch/pipeline/modules/braille/default.css</value>
  </choice>
</oneOrMore>
bertfrees commented 8 years ago

This would mean you would have to change your multiple file selection widget a bit of course. I also have to add px:media-type="text/css" so that the option can be prefilled automatically.

josteinaj commented 8 years ago

Yes, changing the script should be relatively straight forward. Add px:type="anyFileURI" to make the option a file input, and px:media-type="text/css" to make it suggest CSS files automatically.

Since the file widget would be automatically filled, we may need to handle the case where the CSS file is already referenced from the DTBook/HTML, and in that case probably don't add an additional import of the CSS. Or maybe the behavior in the web ui should be so that file widgets that represent optional arguments are not automatically filled; that might be better.

We could use oneOrMore but it would serve the same purpose as <p:option px:sequence="..." >. I don't know how best to handle that. Maybe clients that understand the Relax NG syntax could simply ignore px:sequence.

I think I like your suggestions. Maybe the <data type="..."> should be aligned with <p:option px:type="...">, and thus be anyFileURI instead of input?

bertfrees commented 8 years ago

Since the file widget would be automatically filled, we may need to handle the case where the CSS file is already referenced from the DTBook/HTML

Ah yes, good point. Not automatically filling optional arguments is maybe the best, yes.

Regarding px:input and oneOrMore: yes your suggestions are better, I was confused because we have px:output and forgot that we have px:sequence.

Besided I think px:type should be deprecated in favor of px:data-type (or the other way around), because having both doesn't make much sense.