I placed some test code on the server yesterday, well to test!
I've noticed that there are times when you click "new" or go to a linked liked / mentioned message, you don't end up at the right spot on the page, usually overshooting the proper message. I don't know if it was just me seeing that behavior or if others have seen that as well.
In the past this was somewhat caused by the editor in the quick reply grabbing focus and messing things up. But thinking about it some more it may be caused by the code blocks we use. After a page loads the JS kicks in and makes the code blocks collapse to fit the code or set to a fixed height if there is a large code block. This moves the page about but the named link in the url (that #new or #msg1234) has already been navigated to.
So the testing code is some JS that runs a scrollTo after (and if) the code collapse code has triggered. Probably the full fix would be to prevent the browser default action (not sure you can) then add a scrollTo event as some promise from the code collapse, right now It just adds an on load event if the code code is run.
Anyway if you notice anything improved, unchanged or worse let me know.
No GH link for the test code, just something I quickly put together and put in place to test.
No idea on the JS TBH, maybe its not needed any longer but was when we first began work on 1.0?. We could try new CSS and see if it works or not without the need for the JS swap.
ETA: Looks like this may have been an old ie8 issue with max heights and overflow auto ... bet we can drop all of that now
Changed the site CSS and turned off the JS code stuff ... so lets see how that works :D
Oh yeah, one of IE8's fun bugs was something along the lines of max-height combined with overflow:auto causing a page to appear completely blank.
There's actually a CSS-only workaround, see http://stackoverflow.com/a/881597/2470572
/*
SUPER nasty IE8 hack to deal with this bug
*/
pre
{
max-height: none\9
}
NB I'm not saying to stick that in. Let IE8 rot, lol
Anyway, love the new script-less experience. Much better. :P
For 1.1 we finally don't have to worry about ie8 :happy dance:
One side effect that I see of CSS only fix (which seems to work well) is that the resize handle does not allow the code block to be greater than max-height. I think only
@emanuele would complain about that though :) If we want to be able to expand a larger block of code, then some JS may need to be attached to that handle.
No, I complain about that too now that you mention it. :P (Or more to the point, I think the default max-height is too small and should be doubled or maybe even tripled. I'm less interested in dragging that thing around as such.)
Where does the handle come from? Is it added by prettify.js?
Ah, thanks! I wasn't aware of that new property. I thought it was just a thing browsers (thankfully!) did these days, but I didn't know it was by implementing a new CSS property and changing the default stylesheet.
Yeah, that does drastically reduce the usefulness of the thing.
So load with max-height, CSS is much quicker than JS.
then on DOMContentLoaded go:
height = computedStyle height
max-height = auto
that'll prevent any bouncing.
Um, that oddness above after the footnote was not typed by me. Input:
stylesheet.[footnote]Yeah, yeah, new as in '09/'10-ish I'm sure. :P[/footnote]
Yeah, that does drastically reduce the usefulness of the thing.
output:
stylesheet.[1]>Yeah, that does drastically reduce the usefulness of the thing.
And... what about dropping the handle and add a button "expand" that shows the entire block instead?
I guess most of the times it's "show me everything or just the snippet", it's kind of unusual that halfway from the max-height and "everything" is very helpful (at least to me :P).
Yup I was thinking along the same lines .. leave the css for the page load and proper named link locations. Then with JS do something like
function elk_codefix()
{
$('.bbc_code').each(function()
{
var $this = $(this);
if ($this.get(0).scrollHeight > $this.innerHeight()) {
$this.css('height', $this.height());
$this.css('max-height', 'none');
}
else {
$this.css('resize', 'none');
}
});
}
Which should remove the max-height constraints on any code blocks that have a scroll bar and remove the resize handle on those that do not.
Could also do as you suggested which should be
function elk_codefix()
{
$('.bbc_code').each(function()
{
var $this = $(this);
$this.css('height', $this.height());
$this.css('max-height', 'none');
});
}
Either should prevent the page jumpiness and allow for the resize:vertical css to work as expected.
Not sure whats going on there either ... something else to look at.
Thats feature creep :P ... Could do that as well and it make sense
nods .... Although one could get surprised how much stuff can be placed in a code block O:-)
ETA: JS "fix" enabled on the site
Maybe it would be better to feature creep into the profile settings? For example, in my DnD add-on I've got this:
if (!$user_info['is_guest'])
{
loadMemberData($user_info['id']);
if (!empty($user_profile[$user_info['id']]['options']['cust_fontsi']))
{
$context['html_headers'] .= '<style>html {font-size:'.$user_profile[$context['user']['id']]['options']['cust_fontsi'].'}</style>';
}
}
Thats not a bad idea at all ... amazing amount of churn over the font size on a site (or as its perceived on ones device)
These are the custom field settings, btw.
Font size
Choose your preferred font size. Examples of valid input are "14px" and "100%".
/^[0-9]{1,3}(\.[0-9]{1,2})?(em|pt|px|%)$/
To me it'd be more efficient and much more powerful to just have a custom CSS field, but this way it's easy to understand for everyone.
Another thing in there is some beloved (by one member in any case :P) SMF bb codes:
public static function bbc_codes(&$codes, &$no_autolink_tags, &$itemcodes)
{
$codes[] = array(
'tag' => 'glow',
'type' => 'unparsed_commas',
'test' => '[#0-9a-zA-Z\-]',
'before' => '<span style="text-shadow: $1 0 0 4px">',
'after' => '</span>',
);
$codes[] = array(
'tag' => 'shadow',
'type' => 'unparsed_commas',
'test' => '[#0-9a-zA-Z\-]{3,12},(left|right|top|bottom|[0123]\d{0,2})\]',
'before' => '<span style="text-shadow: $1 $2">',
'after' => '</span>',
'validate' => function(&$tag, &$data, $disabled)
{
if ($data[1] == 'top' || (is_numeric($data[1]) && $data[1] < 50))
$data[1] = '0 -2px 1px';
elseif ($data[1] == 'right' || (is_numeric($data[1]) && $data[1] < 100))
$data[1] = '2px 0 1px';
elseif ($data[1] == 'bottom' || (is_numeric($data[1]) && $data[1] < 190))
$data[1] = '0 2px 1px';
elseif ($data[1] == 'left' || (is_numeric($data[1]) && $data[1] < 280))
$data[1] = '-2px 0 1px';
else
$data[1] = '1px 1px 1px';
},
);
}
Of course there's also the pictureFill JS:
// Add Picturefill for DnD logo
addInlineJavascript('
// Picture element HTML5 shiv
document.createElement(\'picture\');', true);
loadJavascriptFile('picturefill.min.js', array('async' => true));
And besides some other minor adjustments to $context['html_headers'] and $forum_copyright, one ultimate edit through integrate_buffer. That way the source files are all vanilla Elk, which I love 'cause that way I don't have to worry about anything. :)
Right, sorry, totally off topic. But Elk rocks! :D
Duh-oh ... something going on with the quotes!
hmm... guess so. :P
Yeah its how I pulled out message stub for the parser, its having some problems with those nested quote blocks ... will think on it some.
I've applied a quick "fix", lets see if it has any bad side effects.