-
Notifications
You must be signed in to change notification settings - Fork 46
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
Incorrect "wrong syntax" error reported when link to this version has trailing spaces #207
Labels
Comments
Hmm, actually, I was wrong, Anolis only produces the space if there is a similar space in the source text. In practice, Anolis generates the links based from text in the source spec that is in-between |
tidoust
added a commit
to tidoust/presentation-api
that referenced
this issue
Jun 10, 2015
I made a few changes to the raw spec to add the editors IDs, as required by Echidna, to change the way version links are managed and to update the Status of This Document section so that it might be used without modification in a published Working Draft. I also added a "wd" rule to the Makefile to generate a releases/WD.html that can be provided to Echidna for immediate publication. The generated WD.html file is not part of this commit but has been checked with success against Specberus, the new pubrules checker. Note that the Makefile now uses curl, grep and sed to extract the URL of the latest published WD, used to compute the Previous Version link in the generated Working Draft. This is all a bit hacky but should work and can be manually checked and overwritten by someone before committing the new working draft. Also note that Specberus does not like trailing spaces in "href" in the "This version" and other similar links. We have them because of a combinaison of us using Tidy to enforce 80-character-long lines and Anolis that uses a specific syntax based on comments for these links ("<!--begin-link-->" and "<!--end-link-->"). I worked around that using Anolis "[VERSION]" and "[LATEST]" substitution strings that do not get truncated in the source spec and thus do not generate spaces in the end. The issue has been reported to Specberus folks: w3c/specberus#207 I also added what I believe would be the right ECHIDNA manifest file for this setting (need to test it for real by actually publishing the spec). No "continuous integration" in this commit. There does not seem to be a way to trigger Travis CI on particular changes made to a file. We may either use tags, a different branch, or send the right "curl" command to Echidna manually whenever we want to publish a Working Draft.
tidoust
added a commit
to tidoust/presentation-api
that referenced
this issue
Jun 10, 2015
This commit should contain all updates needed to be able to publish working drafts to /TR/ space at W3C on a semi-automated basis. The basic principle is to use a dedicated "TR" branch where we generate the Working Draft to publish. Any push to that branch will trigger Travis CI (provided it is enabled on the repository, obviously) that will, in turn, send a publication request to Echidna at W3C with the right parameters. Actually publishing the spec from a local checkout of the gh-pages branch should look like: git checkout TR git merge gh-pages make wd git add releases/WD.html git commit git push w3c TR Using a separate branch is not stricto senso necessary. I chose that option: 1. to have Working Drafts remain somewhat hidden on GitHub, the gh-pages branch will only contain the Editor's Draft and that sounds a good idea 2. because it is easy to trigger Travis CI on a specific branch but not when a when a specific file is updated. In terms of changes, I updated the raw spec to be publication rules and Echidna compliant, adding the editors IDs, updating the way version links are managed, and the Status of This Document section so that it might be used without modification in a published Working Draft. I also created a "wd" Makefile rule to generate the releases/WD.html file that can be provided to Echidna for immediate publication. The generated WD.html file is not part of this commit but has been checked with success against Specberus, the new pubrules checker. Note that the Makefile now uses "curl", "grep" and "sed" to extract the URL of the latest published WD, used to compute the Previous Version link in the generated Working Draft. This is all a bit hacky but should work fine in most cases, except when publishing the spec more than once in a given day. The "previous version" link can be manually checked and overwritten by some editor before committing the working draft in any case. Also note that Specberus does not like trailing spaces in "href" in the "This version" and other similar links. We have them because of a combinaison of us using Tidy to enforce 80-character-long lines and Anolis that uses a specific syntax based on comments for these links ("<!--begin-link-->" and "<!--end-link-->"). I worked around that using Anolis "[VERSION]" and "[LATEST]" substitution strings that do not get truncated in the source spec and thus do not generate spaces in the end. The issue has been reported to Specberus folks: w3c/specberus#207 I also added what I believe would be the right ECHIDNA manifest file and the right .travis.yml configuration file to automate the publication. This will perhaps need to be adjusted when we try to publish the first working draft.
deniak
added a commit
that referenced
this issue
Aug 13, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the spec to test contains trailing spaces in the
href
attribute of the "This version" and other "Previous version" links, Specberus reports errors such as:Example of markup that triggers the issue:
I don't have an example of an online spec because I'm going to update the version that I was testing. The thing is: Anolis generates this space, which is technically correct although a tad annoying perhaps, so it's not that easy to fix in the generated spec.
In the example, removing the final space before the closing double-quote in the
href
attribute fixes the issue. I suspect the code that would need to be tweaked is inlib/rules/headers/dl.js
:https://github.com/w3c/specberus/blob/master/lib/rules/headers/dl.js#L87
In particular, adding a call to
trim()
should do the trick but note it would have to be done for the latest link and the previous link as well:The text was updated successfully, but these errors were encountered: