Parsing of columnspan/rowspan #180

fred-wang · 2022-11-30T10:03:37Z

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):

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.

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 · 2022-12-01T00:26:57Z

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 · 2022-12-02T06:41:56Z

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 · 2022-12-09T01:14:46Z

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 · 2023-01-05T05:04:48Z

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 · 2023-01-05T11:40:55Z

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 · 2023-01-05T14:25:30Z

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 · 2023-01-12T09:03:49Z

@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 · 2023-01-23T11:10:13Z

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

NSoiffer · 2023-01-23T19:45:10Z

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-30T19:32:56Z

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 · 2023-01-31T13:40:22Z

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.

…colspan/rowspan. #180

fred-wang · 2023-02-01T09:46:34Z

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 · 2023-03-27T05:48:50Z

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

NSoiffer · 2023-04-26T17:33:16Z

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

fred-wang · 2023-05-08T06:56:56Z

@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 · 2023-07-12T06:10:20Z

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

See #198 (comment) and issue #180

fred-wang · 2023-07-12T07:41:08Z

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)

fred-wang mentioned this issue Nov 30, 2022

Table related IDL alignments? #166

Open

bkardell mentioned this issue Jan 25, 2023

MathML Core Meeting Jan 30, 2023 #185

Closed

fred-wang added a commit that referenced this issue Feb 1, 2023

Rename columnspace to colspan and explicitly mention HTML parsing of …

b2b93e8

…colspan/rowspan. #180

dginev mentioned this issue Feb 1, 2023

transitional state of columnspan + colspan synonym attributes brucemiller/LaTeXML#2048

Closed

fred-wang mentioned this issue Jun 15, 2023

MathML Core seems to have renamed columnspan to colspan in MathML mtd-element mdn/content#27116

Closed

bkardell mentioned this issue Jun 23, 2023

MathML-Core meeting on Monday, July 26, 2023 #198

Closed

fred-wang added a commit that referenced this issue Jul 12, 2023

Rename colspan back to columnspan.

3a9568a

See #198 (comment) and issue #180

fred-wang closed this as completed Jul 12, 2023

bkardell mentioned this issue Jul 28, 2023

MathML-Core meeting, Monday July 31, 2022 Agenda #200

Closed

bkardell mentioned this issue Sep 26, 2023

Should MathML references be to MathML-Core instead of full? whatwg/html#9795

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Parsing of columnspan/rowspan #180

Parsing of columnspan/rowspan #180

fred-wang commented Nov 30, 2022

NSoiffer commented Dec 1, 2022

fred-wang commented Dec 2, 2022

NSoiffer commented Dec 9, 2022

NSoiffer commented Jan 5, 2023

fred-wang commented Jan 5, 2023

dginev commented Jan 5, 2023 •

edited

fred-wang commented Jan 12, 2023

fred-wang commented Jan 23, 2023

NSoiffer commented Jan 23, 2023

NSoiffer commented Jan 30, 2023

dginev commented Jan 31, 2023

fred-wang commented Feb 1, 2023

fred-wang commented Mar 27, 2023

NSoiffer commented Apr 26, 2023

fred-wang commented May 8, 2023

fred-wang commented Jul 12, 2023

fred-wang commented Jul 12, 2023

Parsing of columnspan/rowspan #180

Parsing of columnspan/rowspan #180

Comments

fred-wang commented Nov 30, 2022

NSoiffer commented Dec 1, 2022

fred-wang commented Dec 2, 2022

NSoiffer commented Dec 9, 2022

NSoiffer commented Jan 5, 2023

fred-wang commented Jan 5, 2023

dginev commented Jan 5, 2023 • edited

fred-wang commented Jan 12, 2023

fred-wang commented Jan 23, 2023

NSoiffer commented Jan 23, 2023

NSoiffer commented Jan 30, 2023

dginev commented Jan 31, 2023

fred-wang commented Feb 1, 2023

fred-wang commented Mar 27, 2023

NSoiffer commented Apr 26, 2023

fred-wang commented May 8, 2023

fred-wang commented Jul 12, 2023

fred-wang commented Jul 12, 2023

dginev commented Jan 5, 2023 •

edited