Just like in Kartographer, we need a frame (left/right/...) and an optional caption added to the graph result.
|Resolved||CKoerner_WMF||T144512 Support Discovery Q2 Goal: Increase maps and graphs usage on Wikipedia|
|Declined||None||T149462 Announce graph frames to the community|
|Open||None||T149833 Update graph docs about the frame|
|Open||None||T21719 HTML5 features (tracking)|
|Open||Arlolra||T51097 Use figure and figcaption HTML5 elements when possible|
|Declined||None||T147184 <mapframe>: Remove empty div with thumbcaption class|
|Open||None||T155375 Extract thumbframe etc from parser into EmbeddedContentRenderer|
|Open||• Jseddon||T147768 Add a frame and caption text to <graph>|
|Open||None||T174766 Update graph ext to Vega 2.6.5|
- Mentioned In
- T174766: Update graph ext to Vega 2.6.5
T133085: Graphs are broken by MobileFrontend's lazy loading image transformer
T148706: RFC: <maplink> support for link text vs fullscreen caption text
T151703: <mapframe> with "text" and "frameless" parameters should not show frame
T150063: Maps "align" attribute definitions, review and fix
T149833: Update graph docs about the frame
T149462: Announce graph frames to the community
- Mentioned Here
- T165118: Support Vega 3.0+ and Vega Lite 2.0+
T174766: Update graph ext to Vega 2.6.5
T154077: Backgrounds of framed images should be white, not grey
T149462: Announce graph frames to the community
@JGirault @MaxSem - the frame looks good, but I was not expecting the background color change. Do we want that? The graphs are drawn on a transparent canvas (unless graph sets a color). The frame does not appear as a "frame", but rather as a "canvas" of a gray color, so all graphs will now look different by default. I am not sure if this is a bad or good thing in itself, just a bit unexpected. Had we only added a thin frame, most of the graphs would have looked almost identical. I would love to either make background transparent (draw a thin frame line instead), or have some UI feedback on this before we announce it.
|Option 1: With thumb background, + white background fallback||Option 2: With transparent background for the whole frame|
In both cases, this is how it renders on mobile:
|Mobile style is to have no borders and transparent background|
I'd prefer option 1 because it looks more like normal pictures and we would not need to establish a new "type of embeds" which looks differently which could lead to complicated community debates.
@T.seppelt, thanks for your opinion
To add a little technical note to this, I am reusing the same .thumb and .thumbinner CSS classes from picture thumbs, for both option 1 and option 2.
So even though these implementations look very different on screen, in terms of code, the visual difference between the two only consists in a couple of lines of CSS overrides.
I hope we will receive more feedback
@JGirault, what will happen if the graph is added in the middle of this page?
P.S. assuming the graph itself does not set its background - thus it is transparent
|Option 1: Frame||Option 2: Frame|
- For the frameless mode, they currently look the same, but we can implement same white background fallback for option 1. I attached screenshots.
|Option 1: Frameless||Option 2: Frameless|
|Note that we could also fallback to a white background here, in which case will render as below:|
@JGirault thanks for the great pics! I keep thinking that we should have the combination of the first and second (framed) - We should have two lines with darker gray fill in between like in the option1, but with the transparent background of the option 2. I don't think we should break user's expectation that transparent graph is really transparent, not white.
Well, it's the end of the day here, so I may not see it correctly., but it sounds impossible at the moment.
Let me explain: if the graph is transparent, the background color becomes the parent's background color, i.e. grey (the frame), instead of blue (the frame's parent).
It requires the graph's parent element (the frame) to also be transparent, to retrieve the frame's parent blue background.
@JGirault Are you saying there is no way for a transparent html element to have a complex non-transparent border with two lines and dark gray in between? I don't know much about styling frames. Perhaps three nested objects, one with dark gray 1px frame, next is lighter gray 5px frame, and next one with dark gray 1px frame again, while each has transparent content?
The caption text needs to be in the grey area, which I guess it can with a grey background applied on .thumbcaption. It feels a little hacky at first sight, but it may work, I'll give it a try !
As for the behavior:
- I think we should be consistent with <mapframe text="..."> instead of caption=
Lastly, we need to decide - to break or not to break:
- default: align=left, frameless
- if text=is set, use align=right by default
- default: align=right
With latest revision :
- Framed vs Frameless rule:
- Graphs are framed by default.
- Add frameless attribute to prevent the graph from being framed.
- Alignment: align attribute
- Extra information with text attributes
- "caption" = specifies extra information about a graph, displayed below the graph, Later this text could be shown in the footer of a full screen dialog, similar as how Maps render in a full screen dialog.
- "alt" = provides alternative information for a graph snapshot, if a user for some reason cannot view it.
- If "alt" is not specified but "caption" is, the alternative text will be created automatically from "caption".
- "title" = specifies extra information about a graph, displayed on hover when the graph is still static.
- If "title" is not specified but "caption" is, the title text will be created automatically from "caption".
- Deprecated in favor of "caption".
While we are on this topic, @JGirault et al, what do you think about citations and source links in graphs? We are getting closer to cross-wiki data support, like these multilingual examples. It would be good for the graph to show a link to its data sources, so that community can instantly see where data for the graph comes from (e.g. tabular data on Commons or a WDQS). Should we allocate some visual space for this as part of our graph frame work?
Someone from Design should review this before the changes go live. Pinging @Nirzar.
<bikeshedding>Personally, I think the new default appearance is a bad idea. Putting the graph in a grey box by default is so 2000s. We might as well go back to Monobook while we're at it ;) What's wrong with the current default appearance?</bikeshedding>
@kaldari the way we restructured the graph is so that it uses transparent background. So it is really up to the div element to set any color it wants. There are cases, like frwiki talk pages, which have complex striped background to indicate each level of conversation. I think the striped background would be bad, but it would be good to use whichever poster's comment's background happened to be.
@kaldari I think the most relevant images are in T147768#2770637 and T147768#2773162.
I just deployed the latest version of this patch to http://data.wmflabs.org/wiki/Dimpvis_-_Fertility_vs_Life_Expectancy -- and it seems we still have some issues to resolve:
- graph draws over caption
- graph is smaller than needed (possibly a Vega related issue)
@Yurik: So the chart now has a frame around it no matter what? That seems even worse. The frame should be an option just like it is for images, not the default. Most of the time I would not want a frame around a chart, but it would be good to have as an option for cases where you just want to have a thumbnail version.
@Yurik: Personally, I think having it (roughly) match the behavior of images would be preferable, but I'm glad to hear there is at least an option to make it frameless. I also feel like it still needs support for a title element (separate from a caption). Should I create a separate ticket for that?
@MaxSem: I was originally referring to the older screenshot, which was a different style. I'm fine with it just re-using the image styles.
Quite a few users have been requesting this. The Vega graphs already support this boxing mode, it just requires an extra param in the spec. @JGirault, what would happen if the actual image is bigger than the size you auto-detect? Will it autogrow? I think the best way to give this option to the users (literally two people asked me about it last night), is to make it optional instead of on by default. This way graph template authors can easily use this functionality when they design graphs in a way that will work with it.