<iref> in <table> not supported

[hassanakbar4]

component_Version_3_cli_txt resolution_fixed type_defect | by julian.reschke@gmx.de

---

The following construct:

        <table>
          <iref item="Bare Table"/>
          <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>

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

[hassanakbar4]

@{"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

[hassanakbar4]

@{"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.

[hassanakbar4]

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed _comment0 which not transferred by tractive

[hassanakbar4]

@{"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?

[hassanakbar4]

@{"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.

[hassanakbar4]

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

---

Ok, thanks Julian.

[hassanakbar4]

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed status from new to closed

[hassanakbar4]

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} changed resolution from ` tofixed`

[hassanakbar4]

@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented

---

Fixed in [2750]:

Added back the ability to place elements in locations where they will translate to invalid HTML. Avoided invalid HTML by pushing the span up one level, as a previous sibling, when needed. Fixes issue #378.