wikimedia/mediawiki-extensions-TemplateData
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/TemplateData synced 2024-12-24 05:33:40 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Templa.../modules/ext.templateData/templateData.css

53 lines
1.1 KiB
CSS
Raw Normal View History

Fix CSS styling of the HTML rendering broken since 2016 Some time ago there was a little bit of custom CSS applied to the HTML table rendering. This is broken since patch I74214ea from 2016. This patch renamed all CSS classes but forgot to update the PHP code accordingly. I decided to not change the HTML rendering because these class names might already be used in custom per-wiki or per-user CSS. Instead I partly revert I74214ea. Unfortunately, some of the styles are quite dramatic, don't look good or just don't work. I decided to remove some. The argument is that the HTML rendering looks the same for 6 years now. I don't see a good reason to change it now. In detail: * Suggested values are not aliases and should not be rendered in gray. * The message "no description" is rendered in gray and italics. But this was applied to the wrong DOM element and made everything else gray and italic as well. * The color #777 is not readable, violating WCAG rules. While it's ok to dim aliases and such, it must be at least #555 or darker. * The "nowrap" destroys the table the moment one of the parameters does have a longer name or alias. Let the browser handle this, as it did for 6 years now. * Same for rendering aliases as individual, indented blocks. This makes the table unnecessarily big when there are many aliases, and just doesn't look right. Again, let's stick to what we had for 6 years. Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
2022-08-08 09:01:35 +00:00
.mw-templatedata-doc-params tbody > tr > th {
TemplateDataBlob: Implement 'type' and 'label' InterfaceText now defaults to null instead of {en:""} which was awkward to deal with in the frontend. As specified: - label is InterfaceText - type is a string and must be a one of the recognized types Updated example for the hypothetical variant of Template:Unsigned and removed other no longer needed example. HTML output has been revised per conversation with Trevor, James and Timo: - Not sortable. - Add label to html output. - Aliases in the main parameter column (one per line), but muted in styling. - Add type to html output. The css module styles content from the server, not content generated by javascript. Moved module to position => top to fix flash of unstyled content. Change-Id: I16d3f9e460c5513935b9b55fe4cec0092b38e6c2
2013-05-08 23:56:57 +00:00
text-align: left;
font-weight: normal;
Initial TemplateData commit Registers a parser tag <templatedata> that should have a JSON blob as content. The blob is then validated and normalised when MediaWiki parses the page (e.g. during save and preview). If there are validation errors, the save is aborted from the extension hook and an error is displayed. If all goes well, the normalised blob is stored in the database (which can be retrieved through the API). And an HTML representation of the template parameters is returned to the wikitext parser to show where the <templatedata> was in the page. The blob format is specified in spec.templatedata.json and is validated in TemplateDataBlob::parse. Bug: 44444 Change-Id: Icf305892a9512545a63f5a5280cc0d340c61585f
2013-02-22 18:50:54 +00:00
}
Fix CSS styling of the HTML rendering broken since 2016 Some time ago there was a little bit of custom CSS applied to the HTML table rendering. This is broken since patch I74214ea from 2016. This patch renamed all CSS classes but forgot to update the PHP code accordingly. I decided to not change the HTML rendering because these class names might already be used in custom per-wiki or per-user CSS. Instead I partly revert I74214ea. Unfortunately, some of the styles are quite dramatic, don't look good or just don't work. I decided to remove some. The argument is that the HTML rendering looks the same for 6 years now. I don't see a good reason to change it now. In detail: * Suggested values are not aliases and should not be rendered in gray. * The message "no description" is rendered in gray and italics. But this was applied to the wrong DOM element and made everything else gray and italic as well. * The color #777 is not readable, violating WCAG rules. While it's ok to dim aliases and such, it must be at least #555 or darker. * The "nowrap" destroys the table the moment one of the parameters does have a longer name or alias. Let the browser handle this, as it did for 6 years now. * Same for rendering aliases as individual, indented blocks. This makes the table unnecessarily big when there are many aliases, and just doesn't look right. Again, let's stick to what we had for 6 years. Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
2022-08-08 09:01:35 +00:00
.mw-templatedata-doc-param-alias {
color: #555; /* required to pass WCAG AAA */
Initial TemplateData commit Registers a parser tag <templatedata> that should have a JSON blob as content. The blob is then validated and normalised when MediaWiki parses the page (e.g. during save and preview). If there are validation errors, the save is aborted from the extension hook and an error is displayed. If all goes well, the normalised blob is stored in the database (which can be retrieved through the API). And an HTML representation of the template parameters is returned to the wikitext parser to show where the <templatedata> was in the page. The blob format is specified in spec.templatedata.json and is validated in TemplateDataBlob::parse. Bug: 44444 Change-Id: Icf305892a9512545a63f5a5280cc0d340c61585f
2013-02-22 18:50:54 +00:00
}
Fix CSS styling of the HTML rendering broken since 2016 Some time ago there was a little bit of custom CSS applied to the HTML table rendering. This is broken since patch I74214ea from 2016. This patch renamed all CSS classes but forgot to update the PHP code accordingly. I decided to not change the HTML rendering because these class names might already be used in custom per-wiki or per-user CSS. Instead I partly revert I74214ea. Unfortunately, some of the styles are quite dramatic, don't look good or just don't work. I decided to remove some. The argument is that the HTML rendering looks the same for 6 years now. I don't see a good reason to change it now. In detail: * Suggested values are not aliases and should not be rendered in gray. * The message "no description" is rendered in gray and italics. But this was applied to the wrong DOM element and made everything else gray and italic as well. * The color #777 is not readable, violating WCAG rules. While it's ok to dim aliases and such, it must be at least #555 or darker. * The "nowrap" destroys the table the moment one of the parameters does have a longer name or alias. Let the browser handle this, as it did for 6 years now. * Same for rendering aliases as individual, indented blocks. This makes the table unnecessarily big when there are many aliases, and just doesn't look right. Again, let's stick to what we had for 6 years. Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
2022-08-08 09:01:35 +00:00
.mw-templatedata-doc-muted {
TemplateDataBlob: Implement 'type' and 'label' InterfaceText now defaults to null instead of {en:""} which was awkward to deal with in the frontend. As specified: - label is InterfaceText - type is a string and must be a one of the recognized types Updated example for the hypothetical variant of Template:Unsigned and removed other no longer needed example. HTML output has been revised per conversation with Trevor, James and Timo: - Not sortable. - Add label to html output. - Aliases in the main parameter column (one per line), but muted in styling. - Add type to html output. The css module styles content from the server, not content generated by javascript. Moved module to position => top to fix flash of unstyled content. Change-Id: I16d3f9e460c5513935b9b55fe4cec0092b38e6c2
2013-05-08 23:56:57 +00:00
font-style: italic;
Fix CSS styling of the HTML rendering broken since 2016 Some time ago there was a little bit of custom CSS applied to the HTML table rendering. This is broken since patch I74214ea from 2016. This patch renamed all CSS classes but forgot to update the PHP code accordingly. I decided to not change the HTML rendering because these class names might already be used in custom per-wiki or per-user CSS. Instead I partly revert I74214ea. Unfortunately, some of the styles are quite dramatic, don't look good or just don't work. I decided to remove some. The argument is that the HTML rendering looks the same for 6 years now. I don't see a good reason to change it now. In detail: * Suggested values are not aliases and should not be rendered in gray. * The message "no description" is rendered in gray and italics. But this was applied to the wrong DOM element and made everything else gray and italic as well. * The color #777 is not readable, violating WCAG rules. While it's ok to dim aliases and such, it must be at least #555 or darker. * The "nowrap" destroys the table the moment one of the parameters does have a longer name or alias. Let the browser handle this, as it did for 6 years now. * Same for rendering aliases as individual, indented blocks. This makes the table unnecessarily big when there are many aliases, and just doesn't look right. Again, let's stick to what we had for 6 years. Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
2022-08-08 09:01:35 +00:00
color: #555; /* required to pass WCAG AAA */
Initial TemplateData commit Registers a parser tag <templatedata> that should have a JSON blob as content. The blob is then validated and normalised when MediaWiki parses the page (e.g. during save and preview). If there are validation errors, the save is aborted from the extension hook and an error is displayed. If all goes well, the normalised blob is stored in the database (which can be retrieved through the API). And an HTML representation of the template parameters is returned to the wikitext parser to show where the <templatedata> was in the page. The blob format is specified in spec.templatedata.json and is validated in TemplateDataBlob::parse. Bug: 44444 Change-Id: Icf305892a9512545a63f5a5280cc0d340c61585f
2013-02-22 18:50:54 +00:00
}
Make 'required' bold in the TD documentation block Bug: T104674 Change-Id: Ie3bb75a3e1df9096f911615ecf362fe16625d8ed
2016-02-21 01:59:03 +00:00
.mw-templatedata-doc-param-status-required {
font-weight: bold;
}
Fix CSS styling of the HTML rendering broken since 2016 Some time ago there was a little bit of custom CSS applied to the HTML table rendering. This is broken since patch I74214ea from 2016. This patch renamed all CSS classes but forgot to update the PHP code accordingly. I decided to not change the HTML rendering because these class names might already be used in custom per-wiki or per-user CSS. Instead I partly revert I74214ea. Unfortunately, some of the styles are quite dramatic, don't look good or just don't work. I decided to remove some. The argument is that the HTML rendering looks the same for 6 years now. I don't see a good reason to change it now. In detail: * Suggested values are not aliases and should not be rendered in gray. * The message "no description" is rendered in gray and italics. But this was applied to the wrong DOM element and made everything else gray and italic as well. * The color #777 is not readable, violating WCAG rules. While it's ok to dim aliases and such, it must be at least #555 or darker. * The "nowrap" destroys the table the moment one of the parameters does have a longer name or alias. Let the browser handle this, as it did for 6 years now. * Same for rendering aliases as individual, indented blocks. This makes the table unnecessarily big when there are many aliases, and just doesn't look right. Again, let's stick to what we had for 6 years. Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
2022-08-08 09:01:35 +00:00
.mw-templatedata-format {
Display format icon and message inside parameters table caption Change-Id: Id9d6620ed766645384d31c63aacd7c8167c1ce19
2015-11-13 20:35:07 +00:00
font-weight: normal;
font-size: 0.85em;
}
Allow different maps to be edited separately Seperate different maps of maps-object into different panels that contains text-area to edit the map, delete button to delete the map, and can be navigated through using a side-bar, that also have "Add new map" button at the top to add a new map. Bug: T258820 Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
2020-08-07 18:27:18 +00:00
.mw-templateData-maps-panel-button {
Create initial UI for maps panel in TemplateData GUI Adding maps object to TemplateData GUI. By adding mapPanelButton to the main panel and creating the map panel which contains multiline input widget to show and insert the map info. Bug: T254478 Change-Id: Iacff86812cbc448fcdbae24e7eeffb0384781dd5
2020-06-11 15:33:52 +00:00
margin-bottom: 0.5em;
}
Allow different maps to be edited separately Seperate different maps of maps-object into different panels that contains text-area to edit the map, delete button to delete the map, and can be navigated through using a side-bar, that also have "Add new map" button at the top to add a new map. Bug: T258820 Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
2020-08-07 18:27:18 +00:00
.mw-templateData-template-map-list-menu-panel {
border-right: 1px solid #c8ccd1;
}
.mw-templateData-template-remove-map-button {
margin-bottom: 0.8em;
}
.oo-ui-menuLayout.oo-ui-menuLayout-showMenu.oo-ui-menuLayout-top > .oo-ui-menuLayout-menu {
Avoid fit-content, not supported by all browsers Bug: T282285 Change-Id: I59e4f5aaa3f4bdd1d97d90fcb671454b00777922
2021-06-03 20:53:40 +00:00
height: 4em;
Allow different maps to be edited separately Seperate different maps of maps-object into different panels that contains text-area to edit the map, delete button to delete the map, and can be navigated through using a side-bar, that also have "Add new map" button at the top to add a new map. Bug: T258820 Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
2020-08-07 18:27:18 +00:00
text-align: center;
box-shadow: 0 5px 16px -8px #0000001f;
}
Avoid fit-content, not supported by all browsers Bug: T282285 Change-Id: I59e4f5aaa3f4bdd1d97d90fcb671454b00777922
2021-06-03 20:53:40 +00:00
.tdg-templateDataDialog-addingNewMap .oo-ui-menuLayout.oo-ui-menuLayout-showMenu.oo-ui-menuLayout-top > .oo-ui-menuLayout-menu {
height: 6.6em;
}
Allow different maps to be edited separately Seperate different maps of maps-object into different panels that contains text-area to edit the map, delete button to delete the map, and can be navigated through using a side-bar, that also have "Add new map" button at the top to add a new map. Bug: T258820 Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
2020-08-07 18:27:18 +00:00
.tdg-templateDataDialog-editMapsPanel .oo-ui-menuLayout > .oo-ui-menuLayout-content {
Avoid fit-content, not supported by all browsers Bug: T282285 Change-Id: I59e4f5aaa3f4bdd1d97d90fcb671454b00777922
2021-06-03 20:53:40 +00:00
top: 4em;
Allow different maps to be edited separately Seperate different maps of maps-object into different panels that contains text-area to edit the map, delete button to delete the map, and can be navigated through using a side-bar, that also have "Add new map" button at the top to add a new map. Bug: T258820 Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
2020-08-07 18:27:18 +00:00
}
.tdg-templateDataDialog-addingNewMap .oo-ui-menuLayout > .oo-ui-menuLayout-content {
top: 6.6em;
}
Reference in a new issue Copy permalink