Showing posts with label Internet Explorer. Show all posts
Showing posts with label Internet Explorer. Show all posts

Saturday, 15 October 2022

Teochew Thunder: Year Eight (Part 2/2)

For this blogging year, the usual features were there - reviews, web tutorials, listicles and so on. I'm glad to report that the popular posts didn't all fall into one category or other. At the very least, it indicates that readers appreciate a variety of blogpost types. Well, except for web tutorials. The readership for those were consistently low.

Viewership for blogposts usually peak at the two-week mark, so they will be judged based on that. The statistics are from LinkedIn and Google.

Top Picks

These are the blogposts that were the cream of the crop. They hit high viewership numbers. Half of them were about current affairs. The rest were made up of a listicle, a review and a dry technical piece.

Crowd-pleasers!

ONE Pass to rule them all was one of my most recent blogposts. I used no profanities in there, but damn, the shade I threw would make an umbrella blush.

The old-fashioned way to skirt the OCBC Phishing Scam was written as a thought piece on something that happened in Singapore last xxx. No surprises there; this was a hot topic on our little island.

Reference Review: The Clean Coder: A Code of Conduct for Professional Programmers
; now, this one was a surprise. My reviews generally haven't had all that much success. Add to the fact that I wasn't excessively complimentary towards Uncle Bob...

Ten Lessons From The Art Of War Applied To Software Development, a fun listicle I put together after attending some rooms on the Clubhouse app.

Discrete And Continuous Data Defined is a headscratcher. This was a dry a piece as I've ever done and honestly I'm not at all sure why it got so popular.

Elon Musk and the Twitter Takeover was an expected hit; after all, it was the topic for a while there regardless of whether or not you were a techie.

Excellent Response

This group encompasses blogposts that got a decent amount of readership, though not enough to propel them to the next tier.

Cleared that bar.

Using Trello outside of the professional workplace was a little geek-out piece of how I used this software in my everyday life.

Software Review: Power BI had a decent enough amount of clicks, which was probably better than I hoped for.

Google moves to 2FA! underperformed, really. Maybe it just wasn't that interesting.

Five Software Development Takeaways From the COP Saga in 2021 was a piece about Singapore politics, though I tied it into tech practices.

Film Review: Black Mirror Series One astonished me because I didn't think people would be interested in a series that premiered so long ago.

Trail of the Catfish was something I wrote about an experience I witnessed and was only peripherally involved in. It had a fair bit of traction on Facebook (because people who use Facebook love that shit) but not so much on LinkedIn.

OK-ish

These posts got a bit of attention, but statistically they got the short end of the stick. Most of them were dry technical blogposts, so no surprise there.

Good reads.

Tech Wizardry in the Beijing Winter Olympics
and Ten Pieces Of African Wisdom In Software Development were pieces I felt deserved more views, but it is what it is.

Functional Terminology, The Different Categories of Data Analytics, Mean, Median and Mode in Python, Thoughts About HTML5, Different Number Types in Datasets and Code indentation reduction using Guard Clauses were wholly technical, nothing exciting here.

Reading Books In Modern Technology
was something whimsical I did. Probably could have written it better.

App Review: Bazooka Boy
was a mediocre review about a mediocre app. Probably got the views it deserved.

Special Mentions

These were blogposts that were especially poignant in the year 2022. They might not have obtained all that much traction, but I'm going to mention them here because they were personally important to me.

Spotlight!

How I became a Married Software Developer chronicles the arduous years leading up to my marriage, and is closely tied to my career as a software developer.

Ten Cheap Shots At Internet Explorer is a glorious, glorious day for me and I refuse to let the lack of views dampen it.

That's all for now!

It has been a pretty decent year, considering this is the eighth straight year I'm doing this. It's not been an outstanding year by any means, but I like to think I at least met a certain standard. If you're reading this, kudos for your continued support!

Thanks for your kind 8-tention!
T___T

Tuesday, 13 September 2022

Five Unpleasant Things About Working With Front-end Technology

In tech, there are several technologies at each layer of the stack. The nuances are usually not covered by tech hiring, and this is usually divided into front-end and back-end. Today, my intention is to examine the two, especially front-end technology. And here are five reasons why you might not want to make front-end technology your career.

1. Rapid evolution

There are several aspects to front-end technology. There's your standard HTML, CSS and JavaScript... and that alone can be a nightmare to keep up with. HTML, if you're up to speed with the most commonly used features of HTML5, not so much. For CSS, the preprocessor packages and CSS3 updates can be slightly more of a pain in the ass.

Multiplying like guppies

But JavaScript? If you elect to go down that rabbit hole, JavaScript is constantly evolving. The core language alone has been through update after update, The jQuery library as well. But all the front-end frameworks - ReactJS, AngularJS, VueJS, just to name a few - are also constantly going through evolution. And new frameworks seem to be coming out of the goddamn woodwork all the time!

And that's only the tech part. The design part is certainly nothing to sniff at. Learning fonts and color schemes is only the tip of the proverbial iceberg. Design patterns and anti-patterns evolve all the time. A typical website in the 90s will look markedly different ten years later, and another ten years after that.

This sounds fun if you're a hobbyist. When you do this shit for a living, not so much.

2. Uncontrollable environment

Front-end code runs on web browsers. Each of which comes with user-controllable functionality a front-end developer may not have catered for.

Yes, you read that right. User-controllable. Not developer-controllable.

Your typical web browser may come with a Dark Mode. There may almost definitely will be controls to increase or decrease font size. This is going to mess with all your layout specifications.

What about Dark Mode?!

Add in the fact that your users may screw with your carefully crafted interface by refreshing the browser insistently, pressing the Back button and using browser functions in all sorts of unruly ways. It's certainly not like a back-end interface where there are limits to input.

3. Testing nightmare

Mobile technology in the past decade has seen a proliferation of different screen sizes - tablets and phones - in addition to the standard screen sizes. In addition, there may be differences in how certain browsers render HTML, CSS and JavaScript. These differences have largely been eliminated with the demise of Internet Explorer, but some remain.

A plethora of different devices.

All of this adds up to an almost untenable amount of user interface testing for the optimal amount of exposure to the market. It is not an enviable position.

Front-end frameworks and libraries such as Twitter Bootstrap, jQuery and such, mitigate much of the insanity. But these issues have remained through the decade and will likely continue to grow the more mobile technology evolves.

4. Vague KPIs

In back-end technology, things are binary. Input is defined, and output is defined. The output is either correct, or it is not. It either is produced quickly enough, or it is not. Things either conform to security standards, or they do not.

Back-end input and
output is simpler.

Front-end technology has all that, true. It also encompasses a whole host of KPIs that are, for the most part, subjective in nature. User experience. Aesthetic beauty. Ease of use. These are guaranteed to vary from user to user and therefore, there is no way to obtain a perfect score.

Imagine being in a situation where you have to live with having less than total success. That is front-end technology.

5. Everyone has an opinion

This is somewhat related to the last point. In back-end technology, laypeople generally have better sense than to ever touch this, because they have little to no understanding of the stack and they have no tech qualifications.

Everyone and their dog.

In front-end technology, however, which is mostly visual, suddenly everybody and their dog has an opinion. Suddenly, everyone feels the need to chime in on how stuff should look and feel like. Nobody is shy about commenting because, well, you don't need tech qualifications to talk about something which is largely visual. It's subjective, so there are no wrong answers.

This makes your work a lot more difficult, when you have to take so much extra feedback into account. And when a sizeable portion of that feedback comes from laypeople, this makes things even more difficult because laypeople don't quite speak the same language techies do, and they may not have a good grasp of what technically makes sense and what doesn't.

In conclusion

Front-end technology is far, far from a bed of roses.

Still, if it still looks intriguing, let nothing deter you from your path. The important thing is not to go in blind, and be aware of all the pitfalls that await you.

Just being up front!
T___T

Saturday, 20 August 2022

Button and Input tags in HTML5

In HTML5, there are two tags that produce visually similar results. They are the button tag and the input tag with the type attribute set to a certain value - button, submit or reset.

Here are examples.

For the input tag, the type attribute is required if the tag is to be rendered as a button.
<input type="button" value="Example"/>




For the button tag, the type attribute is not required for it to render as a button. A value of submit is the default.
<button>Example</button>




Their use cases tend to overlap, but these are distinct tags and there are scenarios when one is more suitable than the other. First, let's take a look at all the possible values for the type attribute, which can apply to the button tag as well.

button - self explanatory. This will cause the input tag to appear as a button, but do nothing for the button tag.
submit - if the button or input tag is inside a form, clicking it will cause the form to submit.
reset - if the button or input tag is inside a form, clicking it will cause the form to reset.

And finally, we have the value image. This is only applicable for input tags, and the src attribute is required as well. The resultant button will have an image and act as a Submit button.

For this, we will use the image below.
1_0.jpg

<input type="image" src="http://www.teochewthunder.com/posts/2022/8/1_0.jpg"/>




For button tags, HTML is allowed between the opening and closing tags, so we could do this.
<button><img src="http://www.teochewthunder.com/posts/2022/8/1_0.jpg"></button>




Which is better?

As always, that really depends on context. In most contexts, the functionality of the input and button tags are interchangeable.

However, again, in most contexts, the button tag is semantically more obvious. And since we don't have to bother with Internet Explorer any more (the button tag had an issue there) we can just use the button tag for most cases. Also, remember that it is possible to embed HTML within the button tag. This makes it infinitely more useful from a design perspective. Sure, we could apply CSS on the input tag the same way as a button tag, but why complicate matters?

One use case for the input tag does stand out, though. Consider this code. In here, we dynamically change the type of the input tag upon clicking, which would not be possible for the button tag.
<input type="button" value="Click me for a magic trick!" onclick="this.type = (this.type == 'button' ? 'checkbox' : 'button')" />


Click on it, see what happens!


Cool parlor trick, eh? Unfortunately, that is also a very niche case... and quite frankly, plainly ridiculous.

Conclusion

The button tag is coolness exemplified, and with the advent of HTML5, on firm ground. There are still uses for the input tag, though perhaps not as a button anymore.

On to more pressing issues!
T___T

Wednesday, 15 June 2022

Ten Cheap Shots At Internet Explorer

It's happening today. 15th June 2022. This is when Internet Explorer stops being supported by Microsoft. It started back in 2015, when I celebrated the impending demise of Internet Explorer, so I won't rehash just how much I hate this botched abortion of a web browser.

Suffice to say, my life as a web developer has been improved immeasurably by no longer having to support Internet Explorer. I know I'm not alone in this, if the proliferation of memes making fun of Internet Explorer is any indication. To commemorate the great event this month, here are a few of my favorites.

1. Keep calm and...?


Yikes, so ugly.

This is a dig at Internet Explorer's butt-ugly interface for missing images. Though, back in the days when its main competition was Netscape Navigator, this was already a marked improvement. By today's standards, though, bleh.

2. No bugs!

Don't open the browser.

Technically, that's true. Kind of like saying shit doesn't stink if you don't sniff it, but you get the idea.

3. The perfect user


Turtle power!

Probably sums up Internet Explorer's speed issues.

4. Still faster


#foreveralone

Yep another cheap shot at Internet Explorer's speed.

5. Browsers!


We all know a
guy like that.

And yet another one.

6. Internet Explorer is useful for one thing...


Yep!


That's an often-used joke, that the best use of Internet Explorer is to download other browsers.

7. Ask her out


Grow some IE-sized balls.

Internet Explorer asking to be your main browser. The audacity!

8. Guns


Shoot yourself.

This one made me choke on my morning coffee. It's so, so apt.

9. Hidden folder hack


This is genius.

Brilliant. No one would touch that, ever.

10. Last and not least...


The worst!

Yep. Just fucking die already, Internet Explorer.

Death to Internet Explorer!

Yep. Go to hell, you bloated misbegotten excuse for software. You won't be missed!

Rest in pieces,
T___T

Saturday, 24 July 2021

Actual Requirements For Tech Expertise

Companies say they need tech experts. And I have no doubt that this is what they truly think. They write all sorts of fancy job descriptions that sound deliciously complex, only for you to realize, during the interview - or worse, during the first week at work - that their needs are far more basic.

What causes this phenomenon? I submit that this is largely found outside of the tech sector. Companies dealing in food, logistics, healthcare and the like, that find themselves in the position of having to undergo some kind of digital transformation.

In other words, get with the times. Keep up with the Joneses. Move with the world before it moves on without you.

This is what I think is happening. Companies that are largely traditional (with very traditional salary ranges) are finding, to their consternation, that the average techie earns significantly more than their average senior executive - even those techies that don't get hired by banks or Big Tech. In order to hire your run-of-the-mill tech grunt in-house, they'd have to fork out amounts they're not accustomed to.

So what do they do? They raise the price a little more, and ask for a tech expert. After all, if they're going to pay that kind of money, they might as well make it worth the price, eh? That's consumer mentality for you. No, I'm not mocking these companies. Not exactly. That's a perfectly reasonable line of thought if your business is outside of the tech sector.

Hiring the cream of the crop.

But the uncomfortable truth is, these companies don't need experts. They don't need geniuses who can invert a binary tree on the spot, or wax lyrical about recursion. They don't need database specialists who can perform Relational Algebra, or extremely experienced rock-star devs who can name you all the best working practices in tech, in the last decade.

And even in the extremely unlikely scenario that they did need someone like that, chances are such a prodigy would prefer to be climbing the ranks within the tech sector itself, not outside of it.

You see, the main obstacle isn't money, or even the willingness to spend it. The obstacles are both cultural and structural.

Companies that are used to doing things the low-tech way are going to have to get used to doing things at a higher level. It's not just a matter of hiring the tech expert; the company, as a collective whole, needs to up their game. And that is the main sticking point. Techies within the tech industry are used to having their methods accepted. They're certainly rarely in the position where they actually have to justify the merits of technology to their bosses, or aggressively push new ways of doing things. Because in the tech sector, change is practically a way of life.

Outside of the tech sector? Not so much.

Case in point...

An ex-colleague was recently showing me the advances that the company had made in technology. Instead of using a physical punch-card system, now they use a biometric facial recognition system.

As outdated as this machine.

Oh, wow.

Using advanced technology to carry out the antiquated practice of clocking in and out of your workplace, as opposed to using an equally antiquated method of doing so? The technology had changed; the culture hadn't.

I mean, what's the difference here? Whether you're killing trees for paper or merely consuming bandwidth and electricity, you're still satisfying HR's need to have everybody conform to the same work timings. It's still a pig; you're merely putting lipstick on it.

What do these companies need, if not an expert?

Well, just to be clear, I'm not saying that experts aren't useful. I'm saying that were they to be hired by these companies, they would be criminally underused. And that's not the company's fault, exactly. After all, if you're not a tech company and therefore are not accustomed to the way tech companies do things, then a reckless wholesale overhaul of processes has the potential to be a disaster of horrendous proportions. Tech companies do things a certain way because it makes sense to do them a certain way. Other companies, within their own industries, have practices that are a requirement of industry-specific standards. Copying blindly helps absolutely nobody. Useful practices can and should be adopted; the trick is figuring which practices are useful.

But for a start, hiring experts when you have no real need to, and probably can't afford to give them the time and autonomy required for them to make a real difference, simply isn't ideal. Companies convince themselves that they need experts, but that's only because they don't fully grasp just what technology is capable of, and what those experts could accomplish as opposed to the relatively basic nature of the company's operations.

Really, do you need experts to set up a biometric facial recognition system for the purpose of making sure your employees clock in and out on time? That seems extraordinarily petty.

So what do companies actually need to bring up the next technological rung? Well, for starters, someone more well-versed in technology than the average employee would do. And if we're going to be honest, that might not actually mean an expert.

To a layperson, tech
is like witchcraft.

Simply put, some companies are at a technological level where the concept of MS Excel pivot tables is a cause for a Wow response. The tech expert, at this point, is the modern-day equivalent of Hank Morgan appearing to ignorant Englishmen as a powerful sorcerer. What techies do (even the experts) isn't magic, but if you're sufficiently backward in mindset and technology, it may as well be.

A Story

Last year, I was hired by an organization on the recommendation of one of my ex-bosses. He told the Director that what the organization needed at this point wasn't a specialist or an expert, but a generalist. I wasn't sure what this meant at the time, but it wouldn't take me long to find out.

Out of the blue, an issue came up. Apparently, the employees operating the end-of-day sales report module at all the outlets were having trouble opening the report, which was in MS Excel format. They did not want to use the Office 365 web-based interface to open the report, as this would require one extra step, and worse, would actually require them to learn something new. As MS Excel licenses were in short supply, the Infrastructure Manager proposed that I rewrite the report in PDF format (which would open in any browser) while he installed Adobe Acrobat Reader on all the machines, and trained the personnel to use it.

Just use tables.

I did him one better. They just needed the damn report to open up right away without any extra steps? All they needed were HTML tables. Even if they were using bloody Internet Explorer, it would still work. The Infrastructure Manager wouldn't have to go through the nightmarish task of installing software on all machines at all outlets across the island, and no extra training was required.

They thought it would take a week, or at least a few days. I took all of twenty minutes to write the code, and presented it in the morning. The outlet staff were satisfied, and the Infrastructure Manager was off the hook.

Duplicitous of me? Very. But at one fell swoop, I had scored a few goals. One; I'd met the objectives of the outlet staff in a way that inconvenienced them the least. Two; I had saved the Infrastructure Manager a shit-ton of labor.

But I digress; the point of this wasn't to tell you what a sneaky SOB I can be, but rather to illustrate that this would not have been possible had I been a tech expert. A tech expert would have found it unacceptable that staff weren't willing to pick up new technologies (and bear in mind that at this point, cloud-based software isn't exactly new) and refused to enable it. No, I was a run-of-the-mill techie with a healthy respect for best practices in tech, but also a willingness to disregard them when the situation called for it.

The fact that I had years of experience in Desktop Support and already learned (the hard way) about people who refuse to learn new ways of doing things, certainly didn't hurt.

In Summary

For companies outside of the tech sector, hiring tech experts is difficult, and in some cases, sub-optimal. Context is everything. Hiring has to be done in accordance to actual needs and not a wish-list.

Your non-expert,
T___T

Wednesday, 18 September 2019

Spot The Bug: Internet Explorer Strikes Again!

Hey guys, the Spot The Bug wagon just rolled back into town, and it's time to kick some bug butt!

Die, bugs, die!

Cross-browser compatibility can be a nightmare. And every once in a while, I'm forcibly reminded of that fact.

So here I was, using a jQuery AJAX call to populate a table. The endpoint led to a PHP file (named, imaginatively, getdata.php) which was grabbing data from a MYSQL database.

index.html
        <script>
            $(document).ready
            (
                $.ajax
                (
                    {
                        url: "getdata.php?type=quotes",
                        type: "GET",
                        success: function(result)
                        {
                            var data = JSON.parse(result);

                            $(data.quotes).each
                            (
                                function(i, x)
                                {
                                    $("#tblQuotes").append("<tr><td style='text-align:right'><b>" + x.person + "</b></td><td><i>" + x.quote + "</i></td></tr>");                                                      
                                }
                            )
                        }
                    }
                )
            );
        </script>


All was fine and dandy, until I detected a typo around the last row, and fixed it in the database. See that I spelled "Linus" wrongly? It's an easy mistake to make, given that "s" and "x" are just about right nest next to each other and he did create Linux. Anyways...


I ran the code again in Chrome, everything seemed fine. But once I tried to do the same in Internet Explorer, the typo came back!

What went wrong

It certainly wasn't the PHP. I ran the file directly in the browser, and even in Internet Explorer, it produced the correct results. This was what it was sending back to the AJAX call. Or was it?

getdata.php
$result = array("quotes" => $techQuotes);
echo json_encode($result);




It seemed a little suspicious that this was only happening in Internet Explorer. And since the PHP wasn't at fault, the next moving part was the AJAX call. Which meant that it was a front-end problem, which in turn gelled with the fact that it was only happening in Internet Explorer.

Why it went wrong

Apparently, Internet Explorer caches all GET requests by default. Therefore, since the endpoint was the same, it simply recycled the previous data! Nice going, Microsoft!

How I fixed it

I just explicitly set caching to off, right there.

index.html
                $.ajax
                (
                    {
                        url: "getdata.php?type=quotes",
                        type: "GET",
                        cache: false,
                        success: function(result)
                        {
                            var data = JSON.parse(result);

                            $(data.quotes).each
                            (
                                function(i, x)
                                {
                                    $("#tblQuotes").append("<tr><td style='text-align:right'><b>" + x.person + "</b></td><td><i>" + x.quote + "</i></td></tr>");                                                      
                                }
                            )
                        }
                    }
                )


And presto! That was how it looked in both Chrome and Internet Explorer now.

Conclusion

You know in this day and age it's so easy to forget that web developers are at the mercy of the browsers of the end-users, and what an utter pain it is to ensure cross-browser compatibility. You think using jQuery will solve all your problems, and surprise, surprise, it really doesn't. Sometimes it introduces new ones.

Cache you later!
T___T

Monday, 19 March 2018

Web Tutorial: The Pie Chart, Safari Edition

Safari, Safari, how do I detest thee? Probably not as much as I hate Internet Explorer, but Safari just needs to keep this up and it'll be a really strong contender. That aside, today we'll be revisiting The Pie Chart we did back in January. It never ran on Safari, and we'll fix that today. Before we begin, let's see what the current code produces on Safari.

Holy cow, that won't do at all. The old rounded corner div with overflow trimmed off trick, just doesn't work here.


We're just going to have to overlay the damn thing. First, shift the graph_container div downwards a hundred pixels, like so.
            #graph_container
            {
                height: 400px;
                width: 400px;
                margin: 100px auto 0 auto;
            }


Easy does it...


Now just after the graph_container div, add a div with an id of safari_wrapper. Then put a div inside that with an id of safari_mask.
        <div id="graph_container">
            <div id="label_wrapper">
                <div id="label_quad_wrapper">

                </div>
            </div>

            <div id="pie_container">
                <div id="quad_wrapper_left" class="quad_wrapper">

                </div>

                <div id="quad_wrapper_right" class="quad_wrapper">

                </div>
            </div>
        </div>

        <div id="safari_wrapper">
            <div id="safari_mask">

            </div>
        </div>

        <div id="legend_container">

        </div>


Now we'll style safari_wrapper. It'll go right over graph_container, so it should have the exact height. But we want it to fit the full width of the screen. And since it's an overlay, the position property needs to be set to absolute. We'll generously give it a z-index of 2500 to ensure it goes right over everything. Making sure top and left properties are 0 will place the overlay in the top left corner of the screen.

And then we temporarily set the background color to a translucent orange so you can see what's going on.
            #quad_wrapper_left .pie_quad
            {
                margin-left: 100%;
            }

            #safari_wrapper
            {
                height: 400px;
                width: 100%;
                top: 0px;
                left: 0px;
                position: absolute;
                z-index: 2500;
                background-color: rgba(255,100,0,0.5);
            }

            #label_wrapper
            {
                height: 100%;
                width: 100%;
                margin-right: -100%;
                float: left;
                position: relative;
                z-index: 2000;
            }


Oh wait, it doesn't fit exactly over graph_container. That's because we shifted graph_container downwards by 100 pixels, remember? No biggie. All is going as planned.


Let's style safari_mask next. We give it a lovely cyan border for now. Width and height are the same as graph_container. The margin property has been set to align the div horizontally center of its parent, safari_wrapper. The border-radius property at 50% makes it circular.
            #safari_wrapper
            {
                height: 400px;
                width: 100%;
                top: 0px;
                left: 0px;
                position: absolute;
                z-index: 2500;
                background-color: rgba(255,100,0,0.5);
            }

            #safari_mask
            {
                height: 400px;
                width: 400px;
                margin: 0 auto 0 auto;
                position: relative;
                border-radius: 50%;
                border: 1px solid #00FFFF;
            }

            #label_wrapper
            {
                height: 100%;
                width: 100%;
                margin-right: -100%;
                float: left;
                position: relative;
                z-index: 2000;
            }


You may notice that the circle is a little thin, and it's not aligned with the chart. No problemo.


How much did we adjust graph_container's position by? 100 pixels? Let's give safari_mask a 100 pixel thick border!
            #safari_mask
            {
                height: 400px;
                width: 400px;
                margin: 0 auto 0 auto;
                position: relative;
                border-radius: 50%;
                border: 100px solid #00FFFF;
            }


Now isn't that just all sorts of nice?


Get rid of the background color.
            #safari_wrapper
            {
                height: 400px;
                width: 100%;
                top: 0px;
                left: 0px;
                position: absolute;
                z-index: 2500;
                /*background-color: rgba(255,100,0,0.5);*/
            }


Ah, we're getting there.


Make the border of safari_mask white!
            #safari_mask
            {
                height: 400px;
                width: 400px;
                margin: 0 auto 0 auto;
                position: relative;
                border-radius: 50%;
                border: 100px solid #FFFFFF;
            }


And we're golden!


Cheap tricks!

Yeah I know. This ain't the most elegant solution in the world. What can I say? Fuck Safari.

Now, wasn't that ins-pie-ring? Heh heh.
T___T

Saturday, 23 April 2016

Web Tutorial: Wheel of Fortune, Safari Edition

It appears that my Wheel of Fortune web tutorial met some... misfortune.

Sometime after I had released the code, I happened to test it on Safari. And this is what I got.


Oh, the horror.

Despite the fact that I had conscientiously written WebKit equivalents of the CSS classes and specifications, Safari has this bug where the overflow property does not play nice with the border-radius property. And that sucks because there are some truly interesting effects to be enjoyed when these properties are combined.

That said, I can only blame myself for not checking that the code works on Safari and Opera. Most of the time, it's Firefox and Chrome. I don't test on Internet Explorer because, well, fuck IE.

What's the Safari fix, then?

Well, I'm sure given enough time and effort, one could find a way to break through this wall. But a good developer also entertains the notion of going around this wall. Which is precisely what we're going to do today.

First, add the CSS specification for safari_fix.
            #wheel_wrapper
            {
                width:500px;
                height:500px;
                position:relative;
                margin:0px auto 400px auto;
            }

            #safari_fix
            {
                width:500px;
                height:500px;
                position:absolute;
                z-index:100;
                margin-left:-120px;
                margin-top:-120px;
                border:120px solid #000000;
                border-radius:50%;
            }


Here are what the properties do...
- width:500px, height:500px, border-radius:50%; to create a circular div the same size as the wheel_wrapper div.
- position:absolute, z-index:100 because we want to overlap wheel_wrapper.
- border: 120px solid #00000 to create a very thick black border around the div. Why black? That's so you can see it better.
- margin-left and margin-top properties have been set to -120px in order to offset the positioning effects of having a 120 pixel-wide border.

Now create a div with the id safari_fix and put in inside wheel_wrapper.
        <div id="wheel_wrapper">
            <div id="safari_fix">
       
            </div>   
            <div class="semicircle_wrapper wheel2">
                <div class="segment_wrapper semicircle2">
                    <div class="segment7 segment">


Here's what you should have. A huge black God-awful ugly border around your wheel, hiding all the even uglier jagged corners. Try your code. Make sure everything works.



Now change the border color to match your background.
            #safari_fix
            {
                width:500px;
                height:500px;
                position:absolute;
                z-index:100;
                margin-left:-120px;
                margin-top:-120px;
                border:120px solid #FFFFFF;
                border-radius:50%;
            }


Voila! A cheap and dirty fix for Safari.



Not the best solution, but...

Yep, this is not the most elegant solution you could have. If you ever change the background color, you'll have to change the color of the border of your safari_fix div as well. But if it works, it works. Until I have a better solution, this stays.

Seeya around,
T___T

Thursday, 9 April 2015

The Impending Demise of Internet Explorer

Internet Explorer is dead! Well, sort of.

Yep! Party time, baby.


The demise of what could arguably be the most despised browser on the Internet (after Netscape Navigator, that is) was reported last month.

Microsoft will be working on a new browser, currently known as "Project Spartan".

This is not going to be one of those constructive commentaries over the Internet detailing the pros and cons of Microsoft's new browser baby. Firstly because I don't have a Windows 10 Trial running, and secondly because I'm too... well, ecstatic.

I mean, this is Internet Explorer. How many ways do I not love thee? Let me count the ways...

Developing for it has been a royal pain in the ass. I recall the days and nights of feverishly adjusting HTML and CSS code to hammer it into presentable shape for, like, five different versions. And at that time, IE 10 hadn't even been released yet! We used to have to run software like IETester just to make sure our websites ran on that damn thing in all its myriad versions. Gettin' real tired of that shit, yo.

IE Tester


Not to mention that sometimes JavaScript didn't run as expected on IE. There's a long boring story revolving around JavaScript and Microsoft's proprietary JScript, but I'm not going to go into it. You can get a rough idea here. Then again, considering this is Microsoft we're talking about, our problems on that front may not be over.

Suffice to say, I was not at all a big fan of Internet Explorer. The fact that Microsoft is no longer going to make it the de facto browser is the best news I've heard all week. It will still be available for legacy purposes, but no further work will be done on it... I hope. It takes a while for any technology to truly die. I mean, how many years has it been since classic ASP was no longer actively supported? Ten, eleven? It's still hanging on to this day.

What next?

The new browser is slated to be more lightweight, more friendly, and more consistent with web standards.

I'm wondering how AJAX runs on that. Though, at least where Greek mythology is concerned, anything named "Project Spartan" being anathema to something called "AJAX" would be strangely incongruous. In that same vein, I'd have to wonder how Trojan Horses would react to it!


Enough horsing around!

OK, enough of the corny and nerdy Trojan War references. It's time to launch a thousand ships in celebration!

This can only be a good thing. I'm dead serious.
T___T