Closed hassanakbar4 closed 2 years ago
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
This is intentional. Could be wrong, of course. The reason is as given here:
https://zin.tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-06#section-3.1.7
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
I agree that there's a spec problem. However, that needs to be fixed on them HTML level. FWIW, RFC 7992 tries to specify all kinds of things without having to, and this leads to problems like these.
rfc2629.xslt generates:
<div class="tt">
<div id="rfc.iref.b.1"/>
<table class="tt tcenter">
<thead>
<tr>
<th>Column 1</th>
<th>Column 2</th>
</tr>
</thead>
<tbody>
<tr>
<td>Value 1</td>
<td>Value 2</td>
</tr>
</tbody>
</table>
</div>
So the table is enclosed in a div anyway, and that allows div child elements that can be used as targets for the references. There are more ways to do this, though, and I believe RFC 7992 shouldn't mandate a specific way to do it.
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed _comment0 which not transferred by tractive
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
Yes, in many places in the html renderer I use enclosing divs in order to have something for an ID to be attached to. In some cases, such as link targets for caption text links, I use spans inserted immediately in front of a table or figure. In this case, the idiocy of the specification and the extent of the special-casing needed in the code made me choose a different path.
Doing something else isn't hard, it's just a bother to work out what to do when the specification leads to invalid html. Is there any fundamental reason to prefer enclosing divs as opposed to sibling spans when in an inline rendering context?
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
It's really a matter of taste.
I like the enclosing model when it's used for the user-specified anchor.
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
Ok, thanks Julian.
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed status from new
to closed
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed resolution from ` to
fixed`
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
Fixed in [2750]:
Added back the ability to place
component_Version_3_cli_txt
resolution_fixed
type_defect
| by julian.reschke@gmx.deThe following construct:
fails with:
Error: Did not expect element iref there, at /rfc/middle/section[10]/section[1]/table/iref
Issue migrated from trac:378 at 2021-10-20 18:30:16 +0500