79,231
edits
Progress Continues
We've already had 21646 updates since Dolphin 5.0. Keep up with Dolphin's continuing progress through the Dolphin Blog: February, March, and April 2024 Dolphin Progress Report. |
The Dolphin Emulator Wiki needs your help! Dolphin can play thousands of games, and changes are happening all the time. Help us keep up! Join in and help us make this the best resource for Dolphin. |
Line 221: | Line 221: | ||
::Will respond in a few bullets bellow... [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:54, 12 July 2016 (CEST) | ::Will respond in a few bullets bellow... [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:54, 12 July 2016 (CEST) | ||
*I believe the "Rating text on top: white bar to be in its full width" is related to the current revision no longer consuming 100% of the width. | *I believe the "Rating text on top: white bar to be in its full width" is related to the current revision no longer consuming 100% of the width. Instead there is as odd gap between the last revision shown and the edge of the chart. I remain a bit unclear why that would be necessary, I'd think the header/footer rows would be be styled to allow for overlapping other content avoiding forcing odd offsets, but I haven't had time to look closely at why the gap has been added. | ||
*Can you or Major be more clear about oppositions to revisions to account for overlapping revision text? The current revision seems to significantly improve on displaying close revisions. Do we not feel there enough CSS3 compliant browsers that support angled text? Neither you or Major have described why you are opposed to the current revisions to account for such? We had considered some additional revisions to offset close revisions further (i.e. allow even closely set diagonal text to not overlap), but wanted to avoid some of the complexities of that for now. In any case I want to have a clearer understanding of the opposition of pulling the change revision indicators into the header, and offsetting them diagonally to allow close set revisions to be legible. | *Can you or Major be more clear about oppositions to revisions to account for overlapping revision text? The current revision seems to significantly improve on displaying close revisions. Do we not feel there enough CSS3 compliant browsers that support angled text? Neither you or Major have described why you are opposed to the current revisions to account for such? We had considered some additional revisions to offset close revisions further (i.e. allow even closely set diagonal text to not overlap), but wanted to avoid some of the complexities of that for now. In any case I want to have a clearer understanding of the opposition of pulling the change revision indicators into the header, and offsetting them diagonally to allow close set revisions to be legible. | ||
*I think the eventual goal regarding the baseline revision point will be to make it be set arbitrarily based on whatever revision we have the earliest report on. If we have no reports earlier than 4.0 then there is no reason to clutter the graph with earlier revisions. However, where we have reports from prior to 2.0 I'd like the chart to display them. My vote would be to display all available data and work out some reasonable display when no data is available. | *I think the eventual goal regarding the baseline revision point will be to make it be set arbitrarily based on whatever revision we have the earliest report on. If we have no reports earlier than 4.0 then there is no reason to clutter the graph with earlier revisions. However, where we have reports from prior to 2.0 I'd like the chart to display them. My vote would be to display all available data and work out some reasonable display when no data is available. |