Il est possible que cela fonctionne, mais cela pourrait s'avérer un peu gênant à un moment donné dans le futur (sinon immédiatement).
<style>
tbody td span {display: inline-block;
width: 10em; /* this is the nuisance part, as you'll have to define a particular width, and I assume -without testing- that any percent widths would be relative to the containing `<td>`, not the `<tr>` or `<table>` */
overflow: hidden;
white-space: nowrap; }
</style>
...
<table>
<thead>...</thead>
<tfoot>...</tfoot>
<tbody>
<tr>
<td><span title="some text">some text</span></td> <td><span title="some more text">some more text</span></td> <td><span title="yet more text">yet more text</span></td>
</tr>
</tbody>
</table>
La raison d'être de la spanest que, comme l'ont souligné d'autres, a <td>se développera généralement pour s'adapter au contenu, alors que a <span>peut être donné - et devrait conserver - une largeur définie; le overflow: hiddenest destiné à masquer, mais ne pourrait pas, ce qui causerait autrement<td> expansion du.
Je recommanderais d'utiliser la titlepropriété de la durée pour afficher le texte présent (ou découpé) dans la cellule visuelle, afin que le texte soit toujours disponible (et si vous ne voulez pas / avez besoin que les gens le voient, alors pourquoi l'avoir en premier lieu, je suppose ...).
De plus, si vous définissez une largeur pour que td {...}le td s'agrandisse (ou se contracte potentiellement, mais j'en doute) pour remplir sa largeur implicite (comme je le vois cela semble être table-width/number-of-cells), une largeur de table spécifiée ne semble pas créer le même problème.
L'inconvénient est un balisage supplémentaire utilisé pour la présentation.