<iref> in <table> not supported

[ietf-svn-bot]

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/section581394b850b8186c0bd36f7dddcae5d3ba5371e4/section5f1f8b9ced72dea365b98717219bbeadc86cce74/table/iref

---

Issue migrated from trac:378 at 2022-02-05 12:46:36 +0000

[ietf-svn-bot]

@henrik@levkowetz.com 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

[ietf-svn-bot]

@julian.reschke@gmx.de 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.

[ietf-svn-bot]

@henrik@levkowetz.com 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?

[ietf-svn-bot]

@henrik@levkowetz.com changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@julian.reschke@gmx.de commented

---

It's really a matter of taste.

I like the enclosing model when it's used for the user-specified anchor.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Ok, thanks Julian.

[ietf-svn-bot]

@henrik@levkowetz.com changed status from new to closed

[ietf-svn-bot]

@henrik@levkowetz.com changed resolution from `` to fixed

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Fixed in ecb73cb:

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.