[css-tables] New table specification in development, what the goals for this spec are

Hey everyone,

I've had a few people contact me in regards to what the goal of this table specification is and what new things have been added to it since it is a L3 of specification and has recently been edited. So I wanted to summarize here what I said when presenting the specification to the CSS Working Group in the Sydney face-to-face for anyone interested in what we're trying to accomplish with this endeavor.

Interop, Interop, Interop!
-----------------------------------------------------------------------

Our interop work on Microsoft Edge is no secret as can be seen in this post "Looking back: Microsoft Edge for developers in 2015"[1] where we document that we want the web that exists to simply work for web developers. This resulted in needing to fix numerous bugs in the platform and align our Edge engine with other browsers focusing our efforts on web compatibility bugs or missing features the web depends on (notice we're referring to live sites here, not hypothetical scenarios).

This is where the table spec comes in, during this bug fixing we found numerous bugs where "fixing" our browser would make the live site in question work, but would cause one of the two following issues:
                * While building out a full test suite for the change it would become apparent that our "bug" was actually an edge case bug in the other browser that the site was depending on, and us implementing this UA's bug would ensure that this bug couldn't be fixed by the offending UA (example of one such bug[2])
                * The change would break more sites than it fixed, leaving us skeptical about the best approach to take

Ultimately, while working on these bugs decided it best to put a moratorium, of sorts, on addressing table bugs in Edge until we had a specification that filled in all of the "undefined" sections of the 2.1 spec and allowed all UAs to adjust their implementations to match that spec as though it were a new feature.

This _will_ undoubtedly break content as we saw while working on trying to fix bugs, but currently this leaves implementations in a quandary where we play whack-a-mole with table bugs and even change back to behaviors we previously had due to new sites expecting that behavior.

What we will, and won't be doing in L3 of the spec:
-----------------------------------------------------------------------

Documenting what happens **NOW** in UAs, primarily focused on browser vendors. While we're completely aware that there other UAs that support and render CSS, the purpose of picking up this spec is to allow browser vendors to achieve interop due to the current web environment stated above. Additionally, focusing on interop means that we need to focus on issues used on the web today, not hypothetical ideas because the goal for this is web compatibility while trying to achieve as sane a table layout as possible. To paraphrase David Baron, "I wish we would have all implemented the IE6 table layout, because that at least made sense." Unfortunately, that ship has sailed, and as much as we want to say 2+2=4; the web unfortunately is, at times, depending on it equaling 5, and others 6000 (see width and height calculation and unit resolution as an example of this). Because of that...

**NO NEW FEATURES WILL BE ADDED!!!**
I cannot repeat this enough, the goal of this effort is to make it so that web developers can code against the features that **already exist** in an interoperable manner, we don't need to be adding new features or functionality as this **will** only make this harder on ourselves. If you do see the potential for improvements to tables, feel free to suggest them but please understand they will be going into L4 of tables as L3 is purely designed to provide an interoperable foundation on which to build upon.

How will you be making the decision on which engine to match?
-------------------------------------------------------------------------------------

We have begun adding some of the reductions of bugs[3] that we have internally to the specification and we want to be able to tie those onto sections of the spec and hopefully, by 2017, be able to fix, with **confidence**, 50% of those bugs.

So you may be wondering, how are we going to fill in the "undefined" sections of the table spec? I'm glad you asked, here is the process that Francois and I have been taking:
* Find a hole in the spec
* Write a bunch of tests and test them in Firefox, Chrome, Safari and Microsoft Edge to see what the various browsers do (these will ultimately become some of our tests for REC)
* If there is consensus document that as the standard
* If there is not consensus but the majority match, make this the standard
* If there is an even split, document the one that makes the most sense and get working group consensus
                + This may be changed in the future, as the sane result may not be the most web compatible

I hope this clears up any questions that anyone may have in regards as to our goal for L3 with the table spec.

Thank you,
Greg

[1] https://blogs.windows.com/msedgedev/2016/01/21/microsoft-edge-2015-in-review/
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=465419&can=1&q=gwhit%40microsoft.com&colspec=ID Pri M Stars ReleaseBlock Component Status Owner Summary OS Modified#
[3] https://drafts.csswg.org/css-tables-3/#bug-list