-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support banners/headers #350
Comments
It would be better if the JSON from stumptown-content contained just the data, not the HTML, and the renderer decided how to present that data to the user. This is in line with how we do it for other things we treat as data, like BCD (where we provide the JSON, not the rendered table) or specifications (where we provide the spec link and don't say how to present it. That also makes it easier for other potential users of stumptown-content to use the content. If it's important to the render to provide the content in a way the follows the order of items in the body, then the stumptown-content JSON could include an item like: {
"type": "status",
"value": [
"non-standard", "deprecated"
]
} |
I'm cool with that. I can write an ingredient that does what |
Perhaps @kenrick95 would be interested? The macro https://github.com/mdn/kumascript/blob/master/macros/ObsoleteGeneric.ejs combined with https://github.com/mdn/kumascript/blob/master/macros/Obsolete_Header.ejs should be the inspiration. Together with https://github.com/mdn/kumascript/blob/master/macros/Non-standardGeneric.ejs for If you do get a chance @kenrick95 avoid localization and just go for plain English. We'll make these React ingredients localized some other day. |
I think it's still up for discussion exactly how this will look in the JSON (see mdn/stumptown-content#306, where this would get sorted out) but a couple of things:
|
Now moot. |
* wrong redirect in local server Part of #350 * end-to-end tests
* wrong redirect in local server Part of #350 * end-to-end tests
* wrong redirect in local server Part of #350 * end-to-end tests
There's a class of KS macros that we call "banners" or "headers".
They create a block element across the page warning that the item is (for example) deprecated. See e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Expression_closures for a nice pile of these things.
At the moment, in Kuma, the fact that a method is deprecated is maintained in two (or more) places: the BCD for the item (under the
status
key) and the macro call itself. This makes our content hard to maintain.We would like to maintain this info only in BCD, and have the stumptown-renderer automatically add the relevant banner(s) based on the BCD.
Since stumptown-renderer already gets BCD for each item, it can do this with no changes to stumptown-content. We might anyway choose to represent status more explicitly in the built JSON, via a top-level
status
property, say. Then there would be a small change to stumptown-content to add this.Acceptance criteria
The text was updated successfully, but these errors were encountered: