Handle target-*

[liZe]

Replaces #572.

[liZe]

@Tontyna As said in #572, I've merged your PR in a branch and cleaned many things, including:

• more pythonic code and docstrings,
• don't use a global target collector,
• removed debugging info.

Looks like tests pass 😄.

Thanks a lot for your work, that was really useful with good ideas and a clean global logic!

There's a lot of work to do before merging:

• Some functions get an optional target_collector because some boxes can't be anchors. I'm pretty sure that I've missed some parts of the code when it's needed (yes, we'll probably need to add this target_collector parameter in even more functions).
• The target_collectorcan probably be used in / instead of _gather_links_and_bookmarks (not sure about this, I have to check again but I'm really tired right now 😉).
• We have to follow the specs more carefully about the content property, attr() and other CSS functions. The tricky part is to discard erratic functions sometimes during validation and sometimes during values computation. Moreover, there are subtle syntax changes in attr() and new values in content.
• And of course, we have to write some serious tests 😉.

[liZe]

I've just realized my explanations are probably not clear at all, and that you probably need to update your fork with the latest git commits of this target-collector branch. Here's how to update your GitHub fork, that'll hopefully be useful!

[liZe]

My next job is to move the computing part from build.py into computed_values.py

I've already done half of the work, pushing in the next days.

[liZe]

@Tontyna I'm happy with the current state of this branch, I only miss tests of bad syntaxes for target-* functions (the good ones are tested). I'll merge it soon.

[Tontyna]

Sorry for being absent so long -- had holidays, a flu and then a pile of undone jobs...
The list of commit messages looks promising. Will explore the branch this weekend and give feedback.

[Tontyna]

I only miss tests of bad syntaxes

I can imagine thousands of *bad syntaxes". But I'm not good at writing unit-tests. Actually I parsed a lot of rather ugly html snippets -- WeasyPrint bravely handled the valid rules and discarded the invalid ones and of course the not-yet-supported, too.

Think the only missing test for content would be a css to cover the spec's comma separated URI list and the text for speech, something like content: url(xxx), url(yyy), <content-list> / "alternate text". And a style containing leader(). Just to prove that WeasyPrint eats them up / as a starting point for future implementation...
And maybe a test for string-set setting multiple strings.

All in all: I consider this PR is ready to merge.

[liZe]

All in all: I consider this PR is ready to merge.

Well, you're right, tests can come later.

Thanks a lot for this PR, that was a lot of fun!

[Tontyna]

That was the first step to solve #23.

Next step should be: Make the page and pages (and probably other) counters of the @page context available in the document context . That's tricky. The target_collector could be extended to monitor the requested counters... already have a few ideas how to do that, #93 is on my mind, too. Will PR when something useful emerges.

[liZe]

Next step should be: Make the page and pages (and probably other) counters of the @page context available in the document context . That's tricky.

Oh yeah.