Parsing of columnspan/rowspan

[fred-wang]

From https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd

columnspan/rowspan are said to have the same syntax and semantics as HTML.

In https://html.spec.whatwg.org/multipage/tables.html#attributes-common-to-td-and-th-elements some limits are given for colspan/rowspan and the table model link leads to https://html.spec.whatwg.org/multipage/tables.html#algorithm-for-processing-rows which indicates how to handle parse the values (including out-of-range or invalid values):

8. If the current cell has a colspan attribute, then parse that attribute's value, and let colspan be the result.

• If parsing that value failed, or returned zero, or if the attribute is absent, then let colspan be 1, instead.
• If colspan is greater than 1000, let it be 1000 instead.

9. If the current cell has a rowspan attribute, then parse that attribute's value, and let rowspan be the result.

• If parsing that value failed or if the attribute is absent, then let rowspan be 1, instead.
• If rowspan is greater than 65534, let it be 65534 instead.

I wonder if we need to state this more clearly in MathML Core's normative text? or maybe just add a note about that?

(Note: we don't have an IDL for columspan/rowspan, see #166 )

[NSoiffer]

Just like we do with CSS color names, etc., I think it is best to point out to the HTML spec for the details. That way we don't have out of sync specs if they change some detail.

On a slightly different note: I don't know why MathML uses columnspan instead of colspan. Regardless, maybe with an eye towards unifying MathML tables more with HTML tables, we should consider accepting both colspan and columnspan. Or maybe even go a step further and deprecate it/change it's name in full (and not even use it in core). I don't think columspan is used much in MathML, but if someone has access to data, that would be good to check. If not used much, perhaps we can just change the name and introduce a trivial polyfill that changes the name for legacy documents.

[fred-wang]

Just like we do with CSS color names, etc., I think it is best to point out to the HTML spec for the details. That way we don't have out of sync specs if they change some detail.

I agree. Except that saying "the same syntax and semantics as HTML" and linking to the definitions at https://html.spec.whatwg.org/multipage/tables.html#attributes-common-to-td-and-th-elements (as it is currently done) makes the thing not obvious for the ranges...

Basically the paragraph provides the accepted ranges but not how to handle out-of-range values unless you dig into the details of https://html.spec.whatwg.org/multipage/tables.html#algorithm-for-processing-rows

Also for other attributes, we explain how invalid/absent values are handled or how attributes mapped to CSS (so we can just defer to the CSS parser) but AFAIK, there is not any equivalent CSS property for colspan/rowspan.

So I'd prefer we add something in the line of "attributes are parsed as in 8 'algorithm for processing rows'". This can be an extra note the one of https://w3c.github.io/mathml-core/#html-and-svg or in the normative text.

On a slightly different note: I don't know why MathML uses columnspan instead of colspan. Regardless, maybe with an eye towards unifying MathML tables more with HTML tables, we should consider accepting both colspan and columnspan. Or maybe even go a step further and deprecate it/change it's name in full (and not even use it in core). I don't think columspan is used much in MathML, but if someone has access to data, that would be good to check. If not used much, perhaps we can just change the name and introduce a trivial polyfill that changes the name for legacy documents.

I guess accepting colspan and remove columnspan from MathML Core would be best to avoid confusion by web developers and "remap to colspan" everywhere in the spec. One of the specific example is the IDL discussed in #166

Note that columnspan/rowspan are the two missing Chromium features in BCD listed on https://people.igalia.com/fwang/blink-on-17/#/20 (scriptlevel is the one missing from Safari). It would be good to agree whether we want them, or rowspan/colspan, or remove them from L1 for now before going ahead with https://chromium-review.googlesource.com/c/chromium/src/+/4061476

Note: We also don't have WPT tests for columnspan/rowspan, which is what the patch above is doing too. But the out-of-range is a bit trickier to test without the IDL @bkardell suggested. This is what I was experimenting the other day:

<!DOCTYPE html>
<math>
  <mtable id="largeColumnSpan">
    <mtr><mtd></mtd></mtr>
    <mtr></mtr>
  </mtable>
</math>
<math>
  <mtable id="largeRowSpan">
    <mtr><mtd></mtd></mtr>
  </mtable>
</math>
<script>
  const mathmlNamespace = 'http://www.w3.org/1998/Math/MathML';
  function createCell() {
    let mtd = document.createElementNS(mathmlNamespace, 'mtd');
    let mspace = document.createElementNS(mathmlNamespace, 'mspace');
    mspace.setAttribute('width', '10px');
    mspace.setAttribute('height', '10px');
    mtd.appendChild(mspace);
    return mtd;  
  }

  /* Testing columnspan */
  const maxColumnSpan = 1000;
  let mtd1 = largeColumnSpan.children[0].firstElementChild;
  mtd1.setAttribute("columnspan", `${maxColumnSpan+1}`);
  for (let i = 0; i < maxColumnSpan+1; i++) {
      largeColumnSpan.children[1].appendChild(createCell());
  }
  let mtd2 = largeColumnSpan.children[1].lastElementChild.previousElementSibling;
  console.error(mtd1.getBoundingClientRect().right);
  console.error(mtd2.getBoundingClientRect().right);

  /* Testing rowspan */
  const maxRowSpan = 65534;
  let mtr1 = largeRowSpan.children[0];
  mtr1.firstElementChild.setAttribute("rowspan", `${maxRowSpan+1}`);
  let mtr2 = mtr1;
  mtr2.appendChild(createCell())
  for (let i = 0; i < maxRowSpan; i++) {
      mtr2 = document.createElementNS(mathmlNamespace, 'mtr');
      mtr2.appendChild(createCell());
      largeRowSpan.appendChild(mtr2);
  }
  console.error(mtr1.firstElementChild.getBoundingClientRect().bottom);
  console.error(mtr2.previousElementSibling.lastElementChild.getBoundingClientRect().bottom);
</script>

[NSoiffer]

So I'd prefer we add something in the line of "attributes are parsed as in 8 'algorithm for processing rows'". This can be an extra note the one of https://w3c.github.io/mathml-core/#html-and-svg or in the normative text.

I think the normative text makes more sense if the text is aimed at developers. That way a developer working on those attrs will spot it when reading about them. Maybe something along the lines of [text about being the same as HTML] followed by "Like HTML, values over 1000 should be treated as being 1000 and that illegal values, including 0, should be treated as 1".

I'll bring up changing columnspan to colspan at the next MathML meeting. Your mention of the IDL is another compelling reason to make the change to core now. Deprecating/switching in full would then make sense too, but maybe someone will have a good reason not to do the change.

[NSoiffer]

I'm a little behind on this, but at the Dec 15 MathML Full meeting we discussed colspan and columnspan. The consensus was to ask implementors (i.e., @fred-wang ) about their feelings of just supporting colspan vs supporting both names? It was brought up that MathML table have a number of other names that use "column": columnalign, columnspacing, columnlines, and equalcolumns.

None of these attrs are in core and it is likely that alignment, spacing, and lines will be handled by CSS in core. Does CSS have a way to handle making all the columns have the same (minimal) width? If all of them can be handled by CSS, then compatibility with MathML Full's use of them is not that important.

[fred-wang]

I would go with colspan/rowspan in MathML Core and implemented in all browsers (Gecko/WebKit can keep a deprecated columnspan for backward compatibility in the meantime).

About the other attributes, someone would need to check the details. Some of this stuff can probably be handled by CSS but maybe not all. In any case, MathML 3 allows complicated attributes (whose values are array of properties) that won't be mappable to a single CSS property on an element. My preference is not to add any of these attributes to MathML Core for now and see how existing use cases can be handled with CSS and whether new CSS properties would need to be introduced for CSS tables to cover missing use cases.

[dginev]

I would go with colspan/rowspan in MathML Core and implemented in all browsers (Gecko/WebKit can keep a deprecated columnspan for backward compatibility in the meantime).

@fred-wang just to be clear on this point, since it was my preference in our last Full meeting - as an implementer you would be comfortable with keeping both naming variants (colspan + columnspan) supported in practice, until a removal of columnspan from MathML Full, which ought to be no earlier than MathML 5.

Does that sound right?

[fred-wang]

@dginev the idea is to have only colspan in all browsers ; but Firefox/WebKit would keep legacy support for columnspan and can remove it in the future. I don't have idea about the time, but I guess it would be independent of MathML Full, more about existing usage reported by use counters.

[fred-wang]

I'm curious what's the status of this? Do we agree rename it to colspan in MathML Core?

[NSoiffer]

That's what I think we should do. We will have a core meeting next Monday, so that's a good time to resolve it.

[NSoiffer]

2023/01/30 meeting agreed to change to colspan. But we need to sync with other engines which use columnspan so that we avoid one engine only recognizing colspan and the others only recognizing columnspan. The spec can change now.

@dginev: needs to know when the implementation is going change so he and others can change the generated output for ar5iv to minimize breakage.

[dginev]

Just as an FYI:
There are 13,001 documents in ar5iv that currently rely on columnspan (that is 0.67% of arXiv). So it is relatively low impact - but still noticeable if you land on one of the articles (Eq 7 in 2006.13154 is a good example to compare in FF and Chrome). I can rebuild them in a day, once I have a clear path to getting support in all browsers.

I joked that we can generate both "colspan" and "columnspan" in LaTeXML, for a limited time, but hopefully that won't be the best path forward.

[fred-wang]

Spec has been updated.
WPT tests and Chromium changes are at https://chromium-review.googlesource.com/c/chromium/src/+/4061476
No WPT parsing tests are written for now, I'm moving this task to #166

Firefox and WebKit bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1814346
https://bugs.webkit.org/show_bug.cgi?id=251489

[fred-wang]

Mozilla positioned negatively regarding this change: mozilla/standards-positions#743

[NSoiffer]

Given Mozilla's stance, how do we proceed? Not change the names?

[fred-wang]

@NSoiffer I guess that's the way to go... we will have to do some extra wording to explain that "colspan is interpreted as columnspan" in the HTML spec. And think about which name to use in #166

[fred-wang]

Going over the minutes, I understand the resolutin is to revert to columnspan. So will do it.

[fred-wang]

OK I edited the spec to rename to columnspan.

Regarding the original issue, the text now reads

The columnspan (respectively rowspan) attribute has the same syntax and semantics as the colspan (respectively rowspan) attribute on the element from [HTML]. In particular, the parsing of these attributes is handled as described in the algorithm for processing rows, always reading "colspan" as "columnspan".

which I guess is enough for implementers to understand how to parse.

(note: I also rebased https://chromium-review.googlesource.com/c/chromium/src/+/4061476 and will send the intent-to-ship)