You are currently browsing the tag archive for the ‘html’ tag.
If you are using iOS 6 and Safari 6, you can inspect web pages shown in Mobile Safari or in WebViews of applications like those created with ADF Mobile. This can either be in the iOS Simulator or on a device (iPhone, iPad, iPod touch) connected over USB.
In Safari 6, enable the “Develop” menu:
From that menu, your connected devices and iOS Simulator will display as submenus. Each submenu will list all of the WebViews that you are able to inspect (if you are not sure which one you want, a highlight will appear on your device or in the simulator as you hover over each menu item):
A web inspector window will open:
In the first column, the panel with a document icon (1) is where you can browse the DOM, look at scripts, style sheets, etc. When the HTML page is selected, the middle panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the hand tool (2) to click on the screen (of the actual device or the simulator) to pick an element that you want to inspect.
With an element selected, you can then use the “{}” icon (4) of the right panel to view the element’s style properties. This will show you the exact selectors that are providing each style to the element (5). This is incredibly valuable, particularly when multiple selectors are competing (a line will strike out any styles that lose due to some other more specific selector). You can also edit those values directly or add additional properties and see the change immediately take effect on the screen. Unfortunately, there’s no way to save off any changes you’ve made. If you are trying to create a custom style sheet, you’ll need to jot down elsewhere the changes you’ve made; if you leave the page or close the app, you’ll lose your changes.
Background
As browsers evolve, changes have been made with how the HTML “accessKey” attribute works. There are differences across platforms for the same browser version as well as differences across browser versions on the same platform. There are even some cases where the exact same browser treats accessKey differently for button elements vs. anchor elements! This post shows some examples of how to invoke the accessKey and what the behavior is.
Sample button and anchor HTML using the “accessKey” attribute
<html>
<body>
<button onclick="javascript:alert('hi button with onclick')"
accessKey="r">Button t<u style="color:red">r</u>y me</button>
<a href="javascript:;" onclick="alert('hi anchor with onclick');return false;"
accessKey="o">Anchor with <b style="color:red">o</b>nclick</a>
</body>
</html>
How different browsers handle the above accessKey letters for button and anchor elements
| Browser | Operating System | Key Combination | Button Behavior | Anchor Behavior |
|---|---|---|---|---|
| Chrome 7.0.517.41 | Linux | Alt + letter | Clicks the button (3) | Clicks the anchor (3) |
| Chrome 7.0.517.41 | Mac OS X | Control + Option + letter | Clicks the button (3) | Clicks the anchor (3) |
| Chrome 7.0.517.41 | Windows | Alt + letter | Clicks the button (3) | Clicks the anchor (3) |
| Firefox 1.5 | Windows | Alt + letter | Clicks the button (1) | Unknown |
| Firefox 2 | Linux | Alt + Shift + letter | Clicks the button (1) | Clicks the anchor |
| Firefox 2 | Mac OS X | Control + letter | Clicks the button (1) | Clicks the anchor |
| Firefox 2 | Windows | Alt + Shift + letter | Clicks the button (1) | Unknown |
| Firefox 3 | Linux | Alt + Shift + letter | Clicks the button (1) | Clicks the anchor |
| Firefox 3 | Mac OS X | Control + letter | Clicks the button (1) | Clicks the anchor |
| Firefox 3 | Windows | Alt + Shift + letter | Clicks the button (1) | Clicks the anchor |
| Internet Explorer 6 | Windows | Alt + letter | Sets focus on the button (2) | Unknown |
| Internet Explorer 7 | Windows | Alt + letter | Sets focus on the button (2) | Sets focus on the anchor (2) |
| Internet Explorer 8 | Windows | Alt + letter | Clicks the button (3) | Sets focus on the anchor (2) |
| Internet Explorer 9 (beta) | Windows | Alt + letter | Clicks the button (3) | Sets focus on the anchor (2) |
| Safari 3.1.2 | Mac OS X | Control + Option + letter | Clicks the button (3) | Clicks the anchor (3) |
| Safari 3.1.2 | Windows | Alt + letter | Clicks the button (3) | Clicks the anchor (3) |
| Safari 5.0.2 | Mac OS X | Control + Option + letter | Clicks the button (3) | Clicks the anchor (3) |
| Safari 5.0.2 | Windows | Alt + letter | Clicks the button (3) | Clicks the anchor (3) |
- Red = Different behavior for buttons and anchors
- Comment 1 = To just set focus on the button/anchor, change your about:config setting for the “accessibility.accesskeycausesactivation” user preference.
- Comment 2 = Press Enter to click the button/anchor
- Comment 3 = There appears to be no built-in mechanism to just set focus on the button/anchor. The component handling the click event would be responsible for setting focus while handling the click.
It is becoming an epidemic. More banks and employers are making changes to their web applications that they think are protecting both your and their interests but in practice, this is actually doing quite the opposite.
If your bank or employer is a well-known business, it is likely a frequent target for phishing attacks. More people are relying on Google searches and other websites that generate “tiny” URLs (long URLs are redirected through a third party with a short URL that can easily be typed in a chat client, email, etc.). This means that people aren’t using bookmarks to access their banks or companies which means if a website looks familiar to you, you aren’t going to pay close attention to the URL in your browser’s address bar. On the same token, it is easy for fat fingers to slightly mistype a URL that you know by heart so you can easily go to a website different than what you intended and will fall victim to a phishing attack. More and more banks and employers are becoming paperless so any interaction that is requested of the user comes from email. An email has many ways to fool the user into believing that it and the links provided in the email are authentic.
How are my banks and my employer putting my security (and theirs) at risk?
The reason is that they are implementing various mechanisms to prevent your browser from saving and recalling stored user names and passwords. This can be achieved by either adding autocomplete=”off” to the input fields or to the form that wraps these inputs. Another mechanism that is becoming more prevalent is the technique of asking for your user name in one screen and then your password in a second screen after the first screen is submitted. These mechanisms break the password storage and retrieval features of your browser.
Why does denying password saving put us at risk?
There are two reasons why this is very bad. Both reasons come from human error:
- Requiring that a human type in the user name and password means that the human must concentrate on typing in the data rather than analyzing whether the website is authentic. If the browser populated the user name and password fields, you know immediately that the website is the correct one. If the fields are blank and the user knows that the password should have been recalled by the browser’s saved password mechanism, the user becomes surprised and starts to question if they are visiting the correct page. If the browser never saves the password, the user no longer has a fast and accurate way to know that the website is authentic.
- Requiring that a human type in the user name and password encourages the user to have a password that is as easily memorized and typed as possible. This makes it an easier password to guess; fewer iterations to attempt before success. It may also force the user into reusing the same password for every website. Reusing passwords is bad because if one website is compromised, all other websites are wide open. If the user is conscientious about using unique passwords, they are then forced to write down the passwords and post them in an easily-accessible but also vulnerable location in their cubicle at work or desk at home where everyone in your office or everyone who visits or breaks into your home can access it.
Since the way web browsers deal with width and height is so non-intuitive, I’ve created this a handy guide showing how the CSS (Cascading Style Sheets) box model applies widths and heights when scrolling, margins, borders, and padding are involved:
