Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
josteinaj opened this issue Nov 20, 2015 · 6 comments

Comments

@josteinaj
Copy link

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

@josteinaj josteinaj changed the title "stylesheet" option should be a sequence of files instead of a string "stylesheet" option should be a sequence of CSS-files instead of a string Nov 20, 2015
@josteinaj josteinaj changed the title "stylesheet" option should be a sequence of CSS-files instead of a string dtbook-to-pef: "stylesheet" option should be a sequence of CSS-files instead of a string Nov 20, 2015
@bertfrees
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants