I think I owe my readers, visitors, and fans, an explanation as to why a lot of the articles I publish on my site always seem to have a frame sizing error when they’re first published.
The first thing you’ll be asking me is
Do you read my pages and posts a lot when they’re first published? If you do you’ll have seen it and you’ll know what I’m on about. If not then let me explain.
I didn’t want to make this a geek-post but I’m going to have to get at least slightly geeky – so bear with…
The theme that I’m using was originally built by the WordPress Team:
It used to be Twenty Fifteen, but I’ve geeked and customised the heck out of it. Most of the original pieces and code of the Twenty Fifteen theme are still there; I’ve just changed/enhanced some of it, and added a lot more to it.
Exactly as with the original Twenty Fifteen theme; my theme is written so that the page adapts to the type of display that it’s viewed on. – It’s a completely different display for a desktop device as compared to a mobile device, but the theme is built to display to size and to shape on them all.
(I didn’t write the code for that: It was designed into the original theme and I’m just using the original code on an Open Source Licence.)
When I write a post or page I usually write it on a somewhat ancient app; that being Windows Live Writer. Windows Live Writer was originally created somewhere around 2006/7 time – back in the days when website security was only for big commercial sites. When a virus infection made your screen display weird messages rather than emptying your bank account and turning your box into a zombie porn relay waiting to be future-activated in order to take part in a massive DDOS attack on a national Government. The days when Windows users thought that Linux usage made the user stupid and the Linux community used to write scripts to bring down the market-domination of Windows XP.
Things have changed a lot since then.
In those days Windows Live Writer was cutting edge, the bees’ knees, the dogs’ balustrade. It would read the user’s blog theme and copy it right there on the page, so that the user could see what they were creating as if it were actually written straight to their blog or website. It’s extremely useful for WYSIWYG text and alignment of illustrations: Just place the cursor where you want to add an image use the settings in the ribbon to align it, set its alt attributes… It was a brilliant piece of software: All credit to Microsoft for creating it.
Windows Live Writer doesn’t do that in my case though. It can’t read my theme because it doesn’t understand how it works. In short it doesn’t have enough intelligence to be able to comprehend it, and so it gives up on reading the theme and uses its default settings instead.
Its default settings are a desktop-display-sized page with full-page spread. Some of you will note that my website’s text area doesn’t even appear like that – with those dimensions – on a desktop or laptop display. – But I have a way of simulating what my article would look like if I were writing it direct to a desktop display. The trick is to use an HTML frame around everything in Windows Live Writer. It’s done like this: –
I start with a blank page or post in Windows Live Writer.
If I just wrote my article on what I’m given by WLW and transferred it to my site as a draft, it would look totally different when I viewed it from my site than the way I’d intended it to look when I wrote it. – Therefore I need to contain it to start with. I need to contain it in something that is about or as near as possible to the size and shape of my text area on my website as displayed on a laptop or desktop display. If I can write it like that then my theme will change it automatically to display properly on other displays.
You may have noticed that most of my articles, when displayed on a desktop or laptop display, appear on a white background with a thin yellow border around them, The white background and the thin yellow border aren’t generated by my theme. They need to be added or else I have to write on a coloured background in gold-coloured default text. – Therefore I have to set the CSS on-page before the start of each article. This is done in the following manner: –
I end the article’s code with a
– But that alone doesn’t properly encapsulate the article and allow the correct pagination. I also need a table of the correct size as an inner border. This is easily accomplished by adding the following code after the above line of code: –
And finishing off by closing the table before the final </div> that I just placed at the end like so: –
You can see an example of this if you view this page’s source.
That gives me a frame in the centre of the full-page-spread in Windows Live Writer in which I can write and design the article almost exactly as it will appear on the page of the website. (WLW doesn’t show the thin yellow outer border as it doesn’t read CSS. – I have an entry in my website’s stylesheet.css which causes it to appear on the site though; so it’s useful to design it in from step 1.)
WLW does show the table border however, and everything I write is within that table border keeping it near the dimensions of how it should appear on my site. – There is a problem though: That inner table is fixed in size at the width of my website’s content display as it appears on a laptop or desktop monitor. If I change it while the article is on WLW, before it is transferred by XMLRPC to my site, then the correct dimensions on WLW will be lost
If, however, that setting in the code goes to my website it’ll fix the size of the display frame to 493 pixels wide. To avoid that happening I need to change that setting in the code sometime between the time that I upload the draft via XMLRPC to the site and the point where I hit the “Publish” button.
Unfortunately I often write these drafts late into the night, and I often forget to change the setting in the code. – I should change
; which my theme will then read as a variable width which is the full width of the display, depending upon the width of the receiving devices’ display screen, and will adjust the height accordingly also…
…The problem is that I often neglect to do so, and I leave the setting at
before hitting “Publish”.
This has the effect of causing the content display on all devices to be 493 pixels wide – wider than a mobile phone/cellphone, and large-looking on a tablet.
And that’s why many of my posts and pages look quite frightful when viewed on a mobile device just after publication.
I always get around to remedying the error shortly afterwards though: I do hope people don’t judge a book by its first cover as it were, lol. – Awesomeness I often do; but perfection I rarely if ever do. – Give a girl a break.
And that’s that. – I haven’t tried to sell you anything either. I will ask you to scroll down below this post and join my emailing list so that we can stay in touch. – Or you could hit this link: Opt in to Sharron-Idol’s mailing list. – I’ll sell you something another time then.
Do have a great day and
Don’t do anything that I wouldn’t do. –
But if you do; don’t get caught.
- 'Simply one more edifying post. - Enjoy.