Disable cs:text attributes for macros?
#417
Comments
|
Hmm, I would expect any specified attributes on higher-level elements to override the lower-level ones. But I guess I would expect non-default attributes specified on lower-level elements to still apply if no values are specified on the higher-level elements. I'm guessing that poses an issue. I could imagine a scenario where a style could benefit from being able to say, control bold or italics or quotes at the What behavior does citeproc-js have? Are there any relevant tests in the test suite? @denismaier Could you do a search and see how common it is for text attributes other than affixes to be specified on |
I haven't tested myself, but in the linked thread Bastien says pandoc's citeproc privileges higher level attributes while citeproc-js does the opposite. |
Yep. What should happen if you have italics on a lower level, and now call the macro with bold? Will this result in bold or on bold italics? |
|
Yes, given the way we have defined default behavior, I don't see a solution for interpreting this as bold-italic. It's even ambiguous what just a lower-level italic and nothing on the macro call would mean. The default is roman, so does that mean that that default should apply, overriding the lower italic? Does pandoc only apply font formatting to |
|
Ok, some results: rg -c "text macro=.+ (text|font|vertical|quotes)" | wc -l=> 538 styles rg -n "text macro=.+ (text|font|vertical|quotes)" --heading --line-number > results.txt |
|
Hmm, that's a fair number, but could reasonably edit those I think. What do you think @adam3smith? |
|
FWIW, I think the right logic within CSL is to have the lowest level element determine formatting: that's how rules for attributes on One question I have about removing the option to style macros is how this affects formatting of affixes: would not, so these aren't equivalent. Given the existing logic for inheritable name options, I'm not sure I understand the strong case against allowing formatting on macros that'd justify the effort of going through 540 styles and updating the strict validation. |
Yes, that was my initial impulse again. But while the specification is explicit about name attributes, the expected behaviour for other attributes is not specified.
That's a good point. I still think styling should be done in macro calls, but rather inside macros, but this is of course a valid concern. What about this then: Let's just make this explicit in the specification? |
|
So, font formatting on I'm good with that in spec |
|
A couple of examples: <macro name="title">
<text variable="title" font-style="italic"/>
</macro>
<bibliography>
<text macro="title"/>
</bibliography>=> <macro name="title">
<text variable="title" font-style="italic"/>
</macro>
<bibliography>
<text macro="title" font-style="italic"/>
</bibliography>=> italic. <macro name="title">
<text variable="title" font-style="italic"/>
</macro>
<bibliography>
<text macro="title" font-style="normal"/>
</bibliography>=> italic <macro name="title">
<text variable="title" font-style="normal"/>
</macro>
<bibliography>
<text macro="title" font-style="italic"/>
</bibliography>=> normal <macro name="title">
<text variable="title"/>
</macro>
<bibliography>
<text macro="title" font-style="italic"/>
</bibliography>=> italic @bwiernik Is that what you've meant with:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This thread on pandoc-discuss mentions that the spec is currently not clear about rules of precedence in cases such as this one:
What should happen in this case? I'd say the attribute on the lowest level should override the attribute on higher level.
Generally, I'm not sure allowing all
cs:textattributes for macros makes a ton of sense. Affixes ok, but the rest? I'd assume that format attributes should be set on the lower level, i.e., insidecs:macrooncs:text, but not when a macro gets called. Format attributes on a macro call runs somewhat against the idea of macros, or am I missing something?The text was updated successfully, but these errors were encountered: