665229 - Deploy compatibilityTableAggregator template

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Editing, defect)

Description

[Janet Swisher]

What do we need to do to start using this on mainstream content pages?

Comment 1

[Eric Shepherd [:sheppy]]

It probably needs to be updated to look at the column headers and make sure it gets things in the right order; right now it assumes the order of the columns is what it expects. After that's done, I say we pick an area and try it out. Maybe the CSS reference, whose index page is a mess.

Comment 2

[Eric Shepherd [:sheppy]]

Also, we should use background color to make each element stand out better, since they can each use multiple table rows.

Comment 3

[Christian Sonne [:cers]]

(In reply to comment #0)
> What do we need to do to start using this on mainstream content pages?

A few things - here is a list of some of the issues I am currently working on:

1) Right now it's a bit locked to HTML, as it prefixes and postfixes <> to the tag names - that should obviously be configurable (sometimes we might want something else there?)

2) Browser names should be repeated every once in a while, so you don't have to remember the order when looking somewhere in the middle of the table

3) header columns should use thead elements (currently, they are inside tbody)

4) Some pages (at least in the javascript docs) don't use the header "Compatibility", so the template fails to pick up on them. We should either standardize the naming of this section, or extract the table in a more robust fashion (perhaps by not limiting the include to a specific section)

5) (wishlist) would be nice to be able to figure out if an element/* is deprecated or obsolete from the list - not sure how easy that will be to figure out.

(In reply to comment #1)
> It probably needs to be updated to look at the column headers and make sure
> it gets things in the right order; right now it assumes the order of the
> columns is what it expects. After that's done, I say we pick an area and try
> it out. Maybe the CSS reference, whose index page is a mess.

It's using the decided upon "correct" order (alphabetical) - anything not using it should be changed (and I've created a template (though not uploaded it to MDN) that generates the header, so people don't have to remember. I haven't done the one for mobile browsers yet though.

When I get an hour or two to spare, I will go through all the HTML elements, and swap them over to using this template - but I know there are some CSS/JS pages that currently use an incorrect order.

(In reply to comment #2)
> Also, we should use background color to make each element stand out better,
> since they can each use multiple table rows.

Not a bad idea - switching between two colors on every new tag or something shouldn't be too hard.

Comment 4

[Christian Sonne [:cers]]

(In reply to comment #3)
> (In reply to comment #0)
> > What do we need to do to start using this on mainstream content pages?
> 
> A few things - here is a list of some of the issues I am currently working
> on:
> 
> 1) Right now it's a bit locked to HTML, as it prefixes and postfixes <> to
> the tag names - that should obviously be configurable (sometimes we might
> want something else there?)
> 

I've changed it so it has a switch on the type, and "Element" triggers the <>'s. Default is no pre-/postfix, but it can be added to the switch if needed.

> 2) Browser names should be repeated every once in a while, so you don't have
> to remember the order when looking somewhere in the middle of the table
> 

It now repeats the name header every time it witches letter (not counting empty letters)

> 3) header columns should use thead elements (currently, they are inside
> tbody)
>

I can't seem to get this to work - DekiScript keeps complaining about missing }'s or invalid XmlNodes. Perhaps Sheppy can take a look at that?
 
> 4) Some pages (at least in the javascript docs) don't use the header
> "Compatibility", so the template fails to pick up on them. We should either
> standardize the naming of this section, or extract the table in a more
> robust fashion (perhaps by not limiting the include to a specific section)

This is still a problem

> 
> 5) (wishlist) would be nice to be able to figure out if an element/* is
> deprecated or obsolete from the list - not sure how easy that will be to
> figure out.
> 
> (In reply to comment #1)
> > It probably needs to be updated to look at the column headers and make sure
> > it gets things in the right order; right now it assumes the order of the
> > columns is what it expects. After that's done, I say we pick an area and try
> > it out. Maybe the CSS reference, whose index page is a mess.
> 
> It's using the decided upon "correct" order (alphabetical) - anything not
> using it should be changed (and I've created a template (though not uploaded
> it to MDN) that generates the header, so people don't have to remember. I
> haven't done the one for mobile browsers yet though.
> 
> When I get an hour or two to spare, I will go through all the HTML elements,
> and swap them over to using this template - but I know there are some CSS/JS
> pages that currently use an incorrect order.
> 

This still needs to be done too

> (In reply to comment #2)
> > Also, we should use background color to make each element stand out better,
> > since they can each use multiple table rows.
> 
> Not a bad idea - switching between two colors on every new tag or something
> shouldn't be too hard.

Done - though the color seems to be the same as the default for table headers. If anyone has a better idea, it's easy to change in the top of the template.

Comment 5

[Christian Sonne [:cers]]

(In reply to comment #1)
> [snip] After that's done, I say we pick an area and try
> it out. Maybe the CSS reference, whose index page is a mess.

After making some adjustments to the templates to make it more technology neutral, I've tried it out on CSS, but it just returns "Service unavailable"; https://developer.mozilla.org/User:FreakCERS/CSS

The page contains: {{compatibilityTableAggregatorNoCache("en/CSS", "Property")}}

I'm assuming this is caused by a timeout or some such, but other than actually fetching all subpages, I don't think I'm doing anything that should take time...

Comment 6

[John Karahalis [:openjck]]

Been a while since this was updated. Janet, is this still relevant with Kuma?

Comment 7

[Janet Swisher]

Yes, though the template would need to be converted from DekiScript to KumaScript. We might want to reconsider whether there's a better approach under Kuma for aggregating compat tables.

Comment 8

[Jean-Yves Perrier [:teoli]]

I think this is no more relevant and will be superseded by the current Compatibility Table Projects.