-
-
Notifications
You must be signed in to change notification settings - Fork 711
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
Add support for concatenating var() functions in 'content' declarations #1165
Add support for concatenating var() functions in 'content' declarations #1165
Conversation
Checks fail in Python 3.5 due to some unexpected syntax in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this pull request.
I think that there’s something wrong in the way var()
is handled in properties with multiple values, not just content
. Having workarounds for compute
and the validator make your test pass (and I really appreciate tests 😄), but I feel that there’s something wrong.
I need some time to dive deep into this bug and find what’s wrong. If you can find a clean way to solve it before me, I’d be happy too 😉.
Isort doesn’t support Python 3.5 anymore, and WeasyPrint could follow it for the next release. We can safely ignore this error for now. |
var_function = check_var_function(token) | ||
if var_function: | ||
return ((name, var_function),) | ||
if name not in MULTIVAL_PROPERTIES: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is necessary because a content
declaration is a special case since its property handler returns a list, as opposed to every other property. Currently if one of the rules in content
is a variable function, it would only parse that variable function and return it from the function here, without processing the other rules. This is why I have added a special case condition here.
I cleaned it up by declaring the content property as a multi values property.
@@ -699,6 +699,11 @@ def get_content_list_token(token, base_url): | |||
if string is not None: | |||
return string | |||
|
|||
# <var> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here a variable function in a content declaration is acknowledged and returned accordingly.
|
||
if not isinstance(value, list): | ||
converted_to_list = True | ||
value = [value] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multi values properties (for now only content property classifies as such) return a list that possibly includes variable functions among their declaration values. Therefore, isinstance(value, tuple) and value[0] == 'var()'
would never be true for that situation.
I fixed this by looping over all the values and compute the variables when there are variable functions. I temporarily convert non-list declaration values to a list to do this elegantly.
already_computed_value = name not in INITIAL_NOT_COMPUTED | ||
value = INITIAL_VALUES[name] | ||
elif isinstance(new_value, list): | ||
value, = new_value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The content
property handler always returns a list regardless of input. In this case, the handler will only ever get a computed variable declaration, and thus I unpack the computed value again after getting it back from the handler.
@liZe I've replied to your comments in my newest commit. I have also cleaned up a whole bit. Thanks for your review and feedback! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my newest comments.
@liZe You're probably busy, but did you have time to look at this? |
I’m busy, as I’m… on holidays 😄. Thanks a lot for your changes, I’ll have the time to review them this week or next week. |
Hope you had a good holiday @liZe. If there's anything I can do to improve the PR, let me know :-) |
I’m late, I’m really sorry… It’s currently complicated for me to find the time for a good review. I’ll do my best… |
All good! Hope you'll be able to look at it soon. Weasyprint has been extremely useful in my projects and I am happy to continuously contribute to improve it. |
Hi @liZe, just checking in to see if you had any chance to review this PR any time soon? I'm depending on this fix currently, and I need to use a fork of this repository until the PR has been merged. Hope I can revert to upstream soon! |
Thanks again for your patience. I’ve found the time to read your pull request, and I have mixed feelings about it. Your code definitely goes in the right direction, I will merge it, and I’ll add a couple of minor changes (for example, to add all the properties returning iterables). The main problem with this PR is not your code 😄. The main problem is that this PR shows how much the current implementation is wrong. I already knew that a lot of CSS values are stored in random Python structures, and passed from function to function where they’re randomly detected and randomly computed. It’s been bad for a long time, but it now reaches dangerous limits, and I don’t want to go beyond. Let’s say this PR is the last one before a large rewrite. If we want to have |
Thanks so much. If there's anything I can do to help you cleaning up, let me know. |
Thanks again, it’s finally merged.
Most of the properties returning iterables use the We’ll rewrite this sooner or later, to get a clean support of |
@liZe thanks! |
Concatenation of
var()
functions in content declarations does not work. Currently, a variable in content declaration gets resolved correctly, however it disregards the remaining value of a content declaration. E.g.:resolves
p:before
toParagraph
, and not to as you would expect;Paragraph: 1
.This bug is fixed in the changes in this PR.
Linked to my comment in #898.