Re: RFE: Let XXE react to width of <col> elements
Leif Halvard Silli <[email protected]> Wed, 29 Jul 2026 23:47:43 +0200
| Newsgroups | gmane.editors.xxe.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============4006339309168819197==
Content-Type: multipart/alternative;
boundary="------------HkUU9uHK87YALl0hI9049qqL"
Content-Language: nn-NO
This is a multi-part message in MIME format.
--------------HkUU9uHK87YALl0hI9049qqL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 29.07.2026 16:16, by Hussein Shafie:
> We just wanted to implement the following *basic* facility: when the
> user drags a column separator, the width of the adjacent columns is
> adjusted accordingly. The implementation is quite simple (and we want
> to keep it this way): delete all existing column width information
> found in the table and insert one <colgroup>[*] specifying a width for
> each column of the table.
>
> If you need something more advanced than the above basic facility, if
> you want to have full control over the <colgroup>s and <col>s of a
> table then it's not a good idea to use this very basic "drag column
> separator" facility. Please insert <colgroup>s and <col>s "by hand"
> then edit "by hand" their attributes.
>
> ---
> [*] Why <colgroup> and not just <col>? <col> is exactly the element
> the "drag column separator" facility needs to insert. Not <colgroup>
> which has more elaborate semantics. The answer is that, to our
> surprise, HTML5 does not allow <table>s to directly contain <col>s.
> See "HTML Living Standard — Last Updated 20 July 2026", "4.9.1 The
> table element",
> https://html.spec.whatwg.org/multipage/tables.html#the-table-element
>
> ---
> Content model:
> In this order: optionally a caption element, followed by zero or
> more colgroup elements, followed optionally by a thead element,
> followed by either zero or more tbody elements or one or more tr
> elements, followed optionally by a tfoot element, optionally
> intermixed with one or more script-supporting elements.
> ---
All right: Just keep the current automagical behavior And it is a pity
that the HTML spec does not permit <col> without a <colgroup> wrapper.
However, this is not the real issue here.
The real issue is that XXE seems to trea <col> as a forgotten appendix.
I will give you two reasons for that conclusion. Or, if you wish, two
bugs to fix:
1. XXE does **not react** to styling of the width of the <col> element.
XXE only reacts to the styling of the width of the <colgroup> element.
And XXE’s ignorance with regard to styling of the <col> element, has
nothing to do with what the HTML5 spec says about where <col> can or
cannnot occur (in the DOM)! Or how could I be wrong about that
conclusion?
* It is actually tempting to think that the reason you are
inserting multiple <colgroup> elements rather than a single
<colgroup> with multiple <col> elements as children, is because
it was somehow difficult for you to make XXE render the column
width based on the width of the <col> elements. Or at least, you
have ignored it.
* If this is not difficult to fix, then please make XXE visually
display the column width based on the width of <col>.
But until you fix that, currently, if the XXE user would like to see
– inside XXE – the width of a column, he or she must EITHER use
<colgroup> OR retract to styling the width of the cells of the first
row of the table. He/She cannot use <col>, then.
That is: Unless the author wants to completely rely on previewing
the table in a Web browser. Which is in fact what you advice me to
do, when you tell me to eventually style <col> by hand.
And for that reason (that is: since XXE only reacts to styling of
<colgroup>) it is actually *tempting* to rely on XXE’s automagical
behavior!
So, if you want to keep the automagical behavior as simple as it
currently is, you should make XXE react to styling of <col>, as it
is so much more pleasing and intuitive to style the <col> element if
actually XXE reacts to the styling ...
2. Another <col> issue that ought to be fixed (even if it is less
important than making XXE render the styled with of <col> elements),
is the following bug:
When I edit an attribute of a <col> element, I do the following:
* I click on the <colgroup> element to «open it» and select a
<col> element,
* then I locate the attribute I want to edit,
* then I edit it,
* and finally I press Enter or Return to finalize the attribute
editing.
* EXPECTED: That everything visually stays in place.
* ACTUALLY: XXE (visually) closes the <colgroup> element, so that
I loose (visual) track of which <col> element I was editing.
With the consequence that I must open the <colgroup> again to
visually locate the <col> I was editing. If there are multiple
<col> elements to edit, this becomes quite tedious ... And it
is tempting to sayt that this is just another sign that you did
not look much into how XXE treats the <col> elements.
Finally, your surprise with regard to what the spec allows, ought not to
have been a surprise – it is simply the usual thing: HTML code is
permitted to not contain the tags for certain elements, because Web
browsers auto inserts them when they are lacking. (Or, rather, the DOM
is created without the presence of the tags.) Thus, whenever there is a
<col>, Web browsers will autogenerate a <colgroup> wrapper if there
isn’t one in the code. I guess the HTML spec did this, in order to get
DOM that is as predictable as possibe.
If XXE had been a text/html editor (only), you could have inserted <col>
without a <colgroup> wrapper. But as it is an XML editor, this is not
permitted, since XML parsers do not autogenereate elements that way.
However, there does not necessarily have to be a connection between
XXE’s poor treatment of <col> and what the spec says about <col>, me
think … I hope the only connection is that it, for a while, made you
treat <col> as an ...appendix ...
Leif Halvard Silli
--------------HkUU9uHK87YALl0hI9049qqL
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 29.07.2026 16:16, by Hussein Shafie:</p>
<blockquote type="cite"
cite="mid:[email protected]">We
just wanted to implement the following *basic* facility: when the
user drags a column separator, the width of the adjacent columns
is adjusted accordingly. The implementation is quite simple (and
we want to keep it this way): delete all existing column width
information found in the table and insert one <colgroup>[*]
specifying a width for each column of the table.
<br>
<br>
If you need something more advanced than the above basic facility,
if you want to have full control over the <colgroup>s and
<col>s of a table then it's not a good idea to use this very
basic "drag column separator" facility. Please insert
<colgroup>s and <col>s "by hand" then edit "by hand"
their attributes.
<br>
<br>
---
<br>
[*] Why <colgroup> and not just <col>? <col> is
exactly the element the "drag column separator" facility needs to
insert. Not <colgroup> which has more elaborate semantics.
The answer is that, to our surprise, HTML5 does not allow
<table>s to directly contain <col>s. See "HTML Living
Standard — Last Updated 20 July 2026", "4.9.1 The table element",
<a class="moz-txt-link-freetext" href="https://html.spec.whatwg.org/multipage/tables.html#the-table-element">https://html.spec.whatwg.org/multipage/tables.html#the-table-element</a>
<br>
<br>
---
<br>
Content model:
<br>
In this order: optionally a caption element, followed by zero
or more colgroup elements, followed optionally by a thead element,
followed by either zero or more tbody elements or one or more tr
elements, followed optionally by a tfoot element, optionally
intermixed with one or more script-supporting elements.
<br>
---
<br>
</blockquote>
<p>All right: Just keep the current automagical behavior And it is a
pity that the HTML spec does not permit <col> without a
<colgroup> wrapper. </p>
<p>However, this is not the real issue here. </p>
<p>The real issue is that XXE seems to trea <col> as a
forgotten appendix. </p>
<p>I will give you two reasons for that conclusion. Or, if you wish,
two bugs to fix:</p>
<ol>
<li>XXE does **not react** to styling of the width of the
<col> element. XXE only reacts to the styling of the width
of the <colgroup> element. <br>
<br>
And XXE’s ignorance with regard to styling of the <col>
element, has nothing to do with what the HTML5 spec says about
where <col> can or cannnot occur (in the DOM)! Or how
could I be wrong about that conclusion?<br>
<br>
<ul>
<li>It is actually tempting to think that the reason you are
inserting multiple <colgroup> elements rather than a
single <colgroup> with multiple <col> elements
as children, is because it was somehow difficult for you to
make XXE render the column width based on the width of the
<col> elements. Or at least, you have ignored it.<br>
<br>
</li>
<li>If this is not difficult to fix, then please make XXE
visually display the column width based on the width of
<col>. </li>
</ul>
<br>
But until you fix that, currently, if the XXE user would like to
see – inside XXE – the width of a column, he or she must EITHER
use <colgroup> OR retract to styling the width of the
cells of the first row of the table. He/She cannot use
<col>, then.<br>
<br>
That is: Unless the author wants to completely rely on
previewing the table in a Web browser. Which is in fact what you
advice me to do, when you tell me to eventually style
<col> by hand. <br>
<br>
And for that reason (that is: since XXE only reacts to styling
of <colgroup>) it is actually *tempting* to rely on XXE’s
automagical behavior!<br>
<br>
So, if you want to keep the automagical behavior as simple as it
currently is, you should make XXE react to styling of
<col>, as it is so much more pleasing and intuitive to
style the <col> element if actually XXE reacts to the
styling ...<br>
<br>
</li>
<li>Another <col> issue that ought to be fixed (even if it
is less important than making XXE render the styled with of
<col> elements), is the following bug:<br>
<br>
When I edit an attribute of a <col> element, I do the
following: <br>
</li>
<ul>
<li>I click on the <colgroup> element to «open it» and
select a <col> element, </li>
<li>then I locate the attribute I want to edit, </li>
<li>then I edit it, </li>
<li>and finally I press Enter or Return to finalize the
attribute editing. </li>
<li>EXPECTED: That everything visually stays in place. </li>
<li>ACTUALLY: XXE (visually) closes the <colgroup>
element, so that I loose (visual) track of which <col>
element I was editing. With the consequence that I must open
the <colgroup> again to visually locate the <col>
I was editing. If there are multiple <col> elements to
edit, this becomes quite tedious ... And it is tempting to
sayt that this is just another sign that you did not look much
into how XXE treats the <col> elements.</li>
</ul>
</ol>
<p>Finally, your surprise with regard to what the spec allows, ought
not to have been a surprise – it is simply the usual thing: HTML
code is permitted to not contain the tags for certain elements,
because Web browsers auto inserts them when they are lacking. (Or,
rather, the DOM is created without the presence of the tags.)
Thus, whenever there is a <col>, Web browsers will
autogenerate a <colgroup> wrapper if there isn’t one in the
code. I guess the HTML spec did this, in order to get DOM that is
as predictable as possibe.</p>
<p>If XXE had been a text/html editor (only), you could have
inserted <col> without a <colgroup> wrapper. But as it
is an XML editor, this is not permitted, since XML parsers do not
autogenereate elements that way.</p>
<p>However, there does not necessarily have to be a connection
between XXE’s poor treatment of <col> and what the spec says
about <col>, me think … I hope the only connection is that
it, for a while, made you treat <col> as an ...appendix ...</p>
<p>Leif Halvard Silli</p>
</body>
</html>
--------------HkUU9uHK87YALl0hI9049qqL--
--===============4006339309168819197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
--===============4006339309168819197==--