Archive for the ‘Javascript’ Category

No Comments

Security and following the right principle

Friday, April 6th, 2018

Since there was some attention to a CSS driven keylogger, it’s good again to point out the security risks of third party content. That risk is huge.

When a third party CSS Stylesheet can steal your password, it would be a piece of cake for any Javascript script to do the same.

If you follow this blog, it will not surprise you that we’re skeptical to all the JavaScript driven frameworks that are fashionable. In general Javascript is bad for security, privacy, and the planet ūüôā : battery usage. It’s good for tracking, fingerprinting and advertisements, and visual eye-candy.

Yes, JavaScript can be nice, but please adhere to these old principles: graceful degradation and progressive enhancement. And it’s fashionable not to follow those principles.

Don’t force JavaScript, because you’re trying to sell adds, or track users.

Don’t overdo JavaScript: an URL with your contact info should have your contact info (in HTML). Otherwise you should point to another URL. Don’t hide this information behind Javascript and in JSON somewhere. You’re breaking the internet. Keep information accessible.

It’s important to underline again. Every script that is loaded with <script> has access to the DOM, and if the page is a login page, it has access to the password and username.

So a simple principle can be deducted, and it’s a shame that we have to repeat it here.

Never add any (third party) script to a login page. NEVER.

Nobody should be authorized to have access to a plain password, except for the user. Nobody. Limit access by design, not by trust.

(more…)

1 Comment

Breaking the bad, pushing a worse internet (part II)

Sunday, June 21st, 2015

In an earlier post we lamented the behavior of multinationals by dropping noble classic Internet principles like Graceful degradation and progressive enhancement to strengthen their business model at a high security and privacy cost for users.

Go to a site with JS disabled and you see Nada. Zilch. On Google, on Twitter, Facebook¬†tells us it can do much without JS. Nonsense, that is their policy, it’s not your fault.

(more…)

No Comments

Fixing Tracking Contact Form 7 with Google Analytics in WordPress

Wednesday, October 1st, 2014

Contact Form 7 advices to add this code to the Additional Settings field at the bottom of the contact form management page

on_sent_ok: "_gaq.push(['_trackEvent', 'Contact Form', 'Submit']);"

Actually that is a bad idea. Be tracked by Google is not every one’s favourite idea of a free internet, so people block Google Analytics either by any tracker blocker, like Ghostery or Disconnect, by Googles official `opt out extension` or by simple blocking the script in a firewall.

Yes, Internet is the only one place on earth you have to `opt-out` to live quiet and peaceful.

When a user has blocked the Analytics script and visits your contact form, he can’t submit it. It will not submit nor show any error-message. It will do nothing, except show an obscure JS error in the console.

`Uncaught exception: ReferenceError: Undefined variable: _gaq`

To fix this, wrap your code up in a try and catch, so it won’t stop on the error and submitting will not halt:

on_sent_ok: "try{_gaq.push(['_trackEvent', 'Contact Form', 'Submit']);} catch(e){}"

Integrating Contact Form 7 and Google Universal Analytics this way is more robust.

No Comments

Sorting with Flexbox

Wednesday, August 13th, 2014

The Flexible Box Layout Module is a very powerful tool to style your webpages. It offers simple solutions for things like `the Holy Grail`

Here we do a dirty sorting trick:

Just push the buttons or table header to sort the stuff.

How does it work

Sort the elements on text and write the order attribute for CSS.

<li style="order: 7;">scstqehfr</li>

Then set the elements to display flex on the ol element:

.sorted{
display:flex;
flex-flow:column;
flex-direction:column;
}

Be aware:

Sorting this way is kind of superficial, it’s only ordered through CSS: It will show the elements in different order, but in the DOM there is no change at all. So traversing or accessing elements can be surprising, it will go in original/DOM order.

Sorting an table through Flexbox ruins the layout, because it resets the display property from `table-*` to `flex-*`. An additional trick to write the width explicitly is needed to maintain layout.

No Comments

How to get a selection of text with JavaScript

Wednesday, October 31st, 2012

JavaScript is a language full of surprises, sometimes it’s dead simple, sometimes it’s complex or counterintuitive. In its early years it was considered as a toy for making wacky DHTML effects on pages, but it actually has elegant and powerful capabilities. Actually most problems rise out of cross-browser issues, and proprietary implementations for the DOM extensions.

To get a selection of text – user selected text by the user that can be copied to the clipboard – can be accessed by JavaScript as easy as this:

document.getSelection()
//document.getSelection().toString()

Wow, but it wouldn’t be this world if there aren’t any cross-browser issues.

The downside: It works for normal text on pages, but it doesn’t ¬†work for input or textarea elements in Firefox or Opera. It does work in Chromium in all cases.

For Firefox or Opera you need this, slightly more complex, code:

// get active Element

var el = document.activeElement, start = el.selectionStart, end = el.selectionEnd;
var selection = el.value.substring(start, end);

Wouldn’t it be nice if Firefox and Opera make document.getSelection()¬†¬†work like Chromium?

Yes, I guess, but there is another quirk. In Opera you can have multiple selections, you can select text in a texarea field, and leave that selected while you copy text somewhere else. I’m not sure why that is, sometimes confusing sometimes it’s convenient.

No Comments

Spinners and sliders with just native javascript

Thursday, April 5th, 2012

In an earlier post we waved goodbye to jQuery UI for animations. CSS transform and transitions are more powerful, easier to maintain, hardware accelerated, and last but not least less code.

And you could save bandwidth by not loading jQuery UI.

And now I have rewritten the former example to drop jQuery, and believe it or not, it’s even less inline Javascript code. Sure the former example wasn’t really clever programmed – now we use event delegations – but it’s quiet astonishing that using native JS requires less code then the former jQuery example. And of course one library less to load.

Why can we drop jQuery in a lot of cases?

Because CSS animations aren’t working in old browsers anyway, so it doesn’t matter that don’t understand the latest HTML5/ECMA Script 5 / Javascript additions. That’s what graceful degradation means. No eye-candy for older browsers.

Important HTML5/ECMA Script 5 / Javascript additions:

  • classList api: easy toggling, adding and removing of classes.
  • document.querySelectorAll, the native selector API,¬† get you’re DOM elements like the way you do with CSS
  • new powerful array functions, like forEach etc.
  • even Microsoft products (Explorer 9) now support Javascript specs: like addEventListener, XMLHttpRequest,¬† javascript objects instead of ActiveX objects etc.
  • innerHTML, outerHTML
  • DOM traversal

Above list is not complete, but in most cases jQuery was used for things like, binding events, toggling classes, selecting elements, add elements, and ajaxify sites.

Here is the new example

And the used Javascript code:


(function(){
var spinner = document.getElementById("spinner"),i=null
spinner.addEventListener('click', function(event){
// event.preventDefault()
// event.stopPropagation()
// which element is the target
i = Array.prototype.indexOf.call(spinner.children, event.target);
// if(window.console) console.log(i,event)
switch(i){
case 1:
// clicked left, pop -> unshift
spinner.insertBefore(spinner.lastElementChild, spinner.firstElementChild)
break;
case 3:
// clicked right shift -> push
spinner.appendChild(spinner.firstElementChild)
break;
default:
}
// Opera bug workaround
spinner.classList.toggle('operabug')
}, false);
})()

Caveats

The Opera bug with DOM mutations and CSS transform/transitions isn’t resolved yet unfortunately. Somehow the DOM mutations don’t seem to trigger a reflow.

UPDATE: there is an easy fix for the Opera Bug, trigger a reflow by setting a bogus class on any element:

// Opera bug workaround
spinner.classList.toggle('operabug')