General webdev notes

From Helpful

For more webdev-related articles, see the webdev category.
Among the more interesting are general webdev notes, Javascript related notes, CSS notes, browser peculiarities, jQuery
These are primarily notes
This is probably not going to be complete in any real sense, and exists to contain bits of useful information.

This is a messy page made of jots and notes.


Contents

[edit]

General

[edit]

common doctypes

For copy-pasting 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Note that HTML should be served as text/html, XHTML as application/xhtml+xml 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">


Newer: 

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml2.dtd">

And HTML5: 

<!DOCTYPE html>


[edit]

misunderstood attributes

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.


[edit]

Unicode in HTML/XML

In HTML/XML node text and attributes, you can:

  • use numerical entities (always, and unambiguously)
  • use named entities, for the subset of characters for which these exist. The set of named characters differs per standard -- and for plain XML consists of only five: amp, lt, gt, quot and apos, so those are the only universally safe ones.
  • use a specific encoding of characters - always possible, as long as you explicitly mention the encoding
    • for XML: in XML's prologue
    • for HTML:
      • in the charset part of the Content-type HTTP header (won't save into files, though), or
      • in the meta equiv (also has limitations)


In URL encoding (the specification of with does not deal with Unicode), a good solution for many uses is to UTF8-encode before URL encoding.

Note that control codes are not valid in XML (more exactly, their validity as literal character and/or as numeric entity varies between HTML4/XHTML/XML1.0/XML1.1) and a proper parser will probably trip over them. This means the C0 range (U+00 to U+1F), U+7F (DEL), and often the C1 range (U+80 to U+9F). Exceptions in the C0 range are tab (U+09, 'HT'), carriage return (U+0D, 'CR') and line feed (U+0A, 'LF'). Suggested is to either make them markup or encode them, e.g. in base64.


In general, these sorts of details are good arguments for frameworks in which you don't deal with (X)HTML documents directly (they are byte streams, afer all) but instead a logical model that you feed strings and that figures out the formatting details.


[edit]

Escaping and delimiting

See Escaping and delimiting notes#On_the_web

[edit]

PNG transparency in IE5, 6

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

IE6 and before does not display PNGs with alpha transparancy anywhere near correctly. IE7 seems to handle PNGs a lot better, so poke people to upgrade.


There is also a workaround for IE5 and 6, which depends on this DirectX filter (implicitly IE-only).

However, this workaround has

  • limitaitons
    • the new object is not an img tag to CSS anymore - although it can still react to classes(verify)
    • These solutions apply once, usually just after or just before rendering the images when the page is rendered. This means it does not apply to javascript-created DOM, and it seems there usually is no simple 'apply to this new element' or 're-apply to all' function.
  • a few bugs:
    • The filter shows serious bugs depending on image size, which mostly shows up on small image sizes, such as for many icons. (I'm guessing this is a DirectX power-of-two texture size thing? It seems to show up regardless of the sizingMethod...)
    • Links also act weirdly depending on image size. See e.g. the table at the bottom here
    • It looks like a different bug yet applies to images with no set width/height(verify).

TODO: check whether CSS spirtes are an effective solution for any of these problems.


A few different variations of this workaround:

All three showed the size bug for me, in different ways, probably related to different values for sizing/sizingMethod.


It seems there are two ways the filter was applied, one with expression, one without: 

background:none;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='sameimage.png',sizingMethod='crop');
img.pngfix {
  background-image: expression(
    this.runtimeStyle.backgroundImage = "none",
    this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "', sizingMethod='image')",
    this.src = "/img/transparent.gif"
  );
}

TODO: check http://blog.psyrendust.com/pngpong/

[edit]

Libraries

See also this roundup.


[edit]

Unsorted



[edit]

Peculiarities and workarounds


[edit]

Debugging

For firefox and other gecko-based browsers, get firebug.

For IE, see IE_peculiarities#IE_debugging.


[edit]

Cache

In browsers, there is often a difference between a soft reload (the regular kind) and hard reloads, which bypass the cache.

Note that a hard reload does not apply to external resources such as external css and javascript. The easiest solution is probably to clear your cache, though you can go to the specific resource and force reload that, updating the cache.

There is variation between browsers in the ways they do reloads. FF and IE seem to be consistent in that F5 is soft reload and Ctrl-F5 is hard reload.


If you insist on the hard way, see references like http://www.mozilla.org/support/firefox/keyboard

It seems that:

  • Firefox
    • Soft reload: F5, Ctrl-R, ReloadButton
    • Hard reload: Control-F5, Control-Shift-R, (Shift-reloadbutton(verify))
  • IE:
    • Soft reload: F5, Ctrl-R, ReloadButton
    • Hard reload: Ctrl-F5 (what about a reloadbutton combination?(verify))
  • Opera:
    • Soft reload: F5, Ctrl-R, ReloadButton
    • Hard reload: None?(verify)

(TODO: there seem to be version differences. Figure out which)

[edit]

Security

[edit]

Allowing HTML: whitelist, don't blacklist

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

For example, removing 'javascript:' from links is not enough. You are assuming that only exactly that is what browsers look for, and your assumption works only until an exploiter figures out that that is not the only case. For example, some browsers would evaluate: 

<a href="java
script:alert(foo)">

You will not be able to filter out all bad things from every evolving standards (and non-standard use) and the (interactions of) permissive parsers, because you can't reliably anticipate the not-so-obvious cases.

Instead, allow the things you want to support. This gives you direct control over what is allowed, and decent control over details and interactions.


In the case of URLs, you could decide to only allow absolute URLs, and then only those that start with 'http://' or 'https://'.

In the case of HTML, you would probably parse the user input and emit only tags known to be safe, say <em> <i>, <b>, and omit or escape anything else that looks like tags. (Arguably, you might as well use something with a simpler syntax, like bbcode, as it is less expressive and returning something verbatim won't potentially mess with the encompassing document structure -- although be aware that unsafe bbcode filter are just as to write as unsafe HTML filters.)


[edit]

Sessions

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

Making a session cookie store nothing more than an server-unique identifier (probably randomly generated) mentioned identifier, which should be used only as a token. Any other data the server wishes to relate to it can be stored server-side, often in a database (or not).

For example, you could add the username and a date, and only generate the entry and the cookie at a verified login. The token now means 'such and such has logged in at that time.' The user browses as being logged in, but the token alone gives nothing away to snoopers, and is only good for a limited time.

Security-aware websites allow will only basic functionality such as browsing information, but not changing user information and specifically not changing the password without asking for the current password. This makes snooping for the token even less interesting to script kiddies. When transfer of passwords and such information happens securely too it will dissuade real hackers too.

[edit]

XSS

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.



[edit]

Design

[edit]

Fonts

Note: serifs are the extra little twirls on the end of the strokes of letters. The idea is that they help you parse the letters and guide you along. The idea to not using them is that it makes things visually uncluttered. Sans-serif (sans meaning 'without') fonts are often used on the web, particularly for titles.



[edit]

Firebug notes

(See also widerbug, which uses a sidebar-like setup which can be handier on widescreen and multi-monitor setups)

[edit]

Logging and debugging

[edit]

Convenience function

I like to have a log function that:

  • doesn't break when firebug (or firebug lite) isn't there
  • shows the time in sub-second detail, for basic reference for how fast things are

For example: 

15:44 14.158  sourceclick
15:44 14.164 <div class="srcdsc set001074 hover" rel="fork1">
15:44 14.170  Object

Which was produced by something like the following: 

function log(o) {
  if (window.console && window.console.log) { 
    var now=new Date();
    var ns=''+now.getHours()+':'+now.getMinutes()+
           ' '+(now.getSeconds()+now.getMilliseconds()/1000).toFixed(3)+'   ';
    window.console.log(ns,o);
  }
}
[edit]

Functions

See 'Firebug console API' and 'Firebug command line API'.


A slight over-summary of the most interesting:

  • console.log(object) (shows clickable inspectable object)
  • console.log("printf style %s", object) (flattens objects, not clickable)
  • console.log("other string", object) (doesn't flatten)
  • console.count(): log each time the code executes this line
  • group and groupEnd()

Inspecting things:

  • console.dir(object) (inspectable, clickable objects)
  • console.keys(object) (string list)
  • console.values(object) (string list)
  • console.xml(dom)
  • inspect(object[, tabName]) (where tabname can be html, css, script, dom)


Event monitor (often used for DOM events, e.g. mouse):

  • monitorEvents(object[, types]) and unmonitorEvents(object[, types]) (where types is a list of one or more of "composition", "contextmenu", "drag", "focus", "form", "key", "load", "mouse", "mutation", "paint", "scroll", "text", "ui", and "xul")


Debugging:

  • debug(fn), unDebug(fn) (set breakpoint on functions by reference)
  • monitor(fn) and unmonitor(fn)
  • console.trace() (show stack trace, raise error)
  • profile() and profileEnd() (start profiling, stop profiling)
[edit]

Errors

[edit]

"Security Manager vetoed action"

...when evaluating something in the firebug command window.

If you are using beta firefox, note that Firebug 1.1b5 does not work in it. Get a newer firebug [4], or use an earlier firefox.

(Similar problems may be occasionally relevant, I couldn't predict...)


[edit]

Related software

[edit]

Non-browser UAs

Other UAs Perl:

  • Mechanize

Python

  • Mechanize
  • twill


Browsers


[edit]

The back button and bookmarkability in server-side and/or dynamic webpages

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.
[edit]

Some summary

Historically, the back button made sense to allow browsing one's direct history of visited pages. There are definitions to go along to make it faster, which define it to be independent of server state; according to HTTP1.1 (section 13.3): "In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."

That is, if the browser has any version, be it in the local cache, an in-memory still-rendered version or such, that version should be used, regardless of whether it has expired or not.


Some browsers are more likely to re-fetch when you try your best to not have the page cached (e.g. hand along some cache expiration headers referring to a date in the past), but this is not a robust or reliable approach. It's not hard to succeed for some versions of some browsers in some browser configurations, but if it was important enough to work around in the first place, you still have a broken app.


Another solution is to try to ask the browser to disable the back button, for example by trying to clear the history. The user would notice that the button doesn't work (which is already better than going to some random older vesion) and look elsewhere. However, you cannot reliably ask the browser to disable the back button, so this isn't really a solution. The one case in which this can be done reliably is when creating a new window (via window.open or a link with target="_blank"), but this annoys most users (except pehaps advanced users, who force them to be new tabs).

[edit]

The basic/static 'old server state' problem

The major problem is that this messes with pages that should alter and show content based on server state. People might go back to a form and submit a change that might conflict with something they have changed already.

There are two problems:

  • allowing the form submission page to be visited again. You can avoid this by eliminating pages that both show and change server state, because it allows you to make the submit-to-me page immediately do an external redirect to the view page. Browsers will treat such immediate redirects as items not useful for the history, so you cannot visit it again. The history will go back and forth between the viewing pages.
  • Allowing pages to show old state and allow editing on the same page. Do you want the second change to apply on top of that (more logical to the user but harder to code), or on top of the current state (seems random to the user, easier to code).


The latter problem is harder to solve. Half a workaround is to have any edit operation open a new page, so that the server can fill the current state into the edit form. This does not apply to one-click changes or to have a form in-page that submits to change the state.


[edit]

Single-use tokens

Generating unique tokens on the server can be used to identify resubmissions. You can use random numbers, or even the current time (to decent resolution).

When you embed these in a form, you can make the server remember that it has been submitted recently, and thereby detect repeat submissions from the same (past) pages, and choose to do something from there:

You can choose not to listen to the changes, giving an error. One downside is that usability isn't great; it is only at resubmission time that you can tell whether you just wasted a few minutes of tedious form-filling, particularly annoying if at this point you cannot recover the values. In some cases it may be simple enough to show a page with the message "Here's the actual current state, and here are your changes. They may overwrite a previous submission, do you want to do so?", although doing a partial change.


Since users usually go back to change their submission, you could detect resubmission and treat is as 'remove the previous transaction, and apply this one instead". This involves more than just overwriting the page values, and may need a structural redesign, but is more predictable for users.


[edit]

Disabling semi-hack: more redirection

A simple extension of the redirect hack named above is to redirect onto a page that does a script-based location change (or another way of getting that redirect page into the history) to the next view page.

That way, a single back click will technically work, but lands the user on a page that immediately moves them forward again. Only tenacious and/or advanced users that uses the back history or very fast clicks will get past this.

[edit]

...on dynamically changing pages

...such as heavily scripted, dynamic, AJAXing pages, add an extra dimension to this problem, as they will change the not only across page/URL changes, but also when it does not change.


The already-mentioned (from-cache, rendered-copy) details above also make solutions involving scripting harder.

One relatively simple check might have been to check with the server whether the page is current, or AJAX in all content (ensuring all state is current server state), but this approach is broken. As far as I have been able to verify, any choice of event (onload, etc.) is not guaranteed to be triggered - all suggested solutions I've seen so far are non-standard browser-precarious hacks, that sometimes effectively rely on the user's cache settings.


[edit]

# (window.location.hash)

One trick you can pull is copying/referring to page state after the hash in the URL (the fragment identifier, a.k.a. hash). The idea is that the use of #:

  • will get bookmarked
  • do not trigger page reload.
  • is entered in the history (...except on IE, which breaks this approach)

If there is (also) an anchor with the given name, the page will move so that the place that anchor is lay out in the page sits corresponds with the first viewed line. If there isn't, browsers generally go to the top of the page.


[edit]

for bookmarkability

If, on significant page actions, copy the state necessary to repeat that action to the hash, this means any such reference will be entered into a bookmark, and copied when someone copies and sends a link to someone else.

Since bookmark loads are fresh, onload will always be triggered and you can add code that, checks whether the hash value is/refers to state, and use it.

However, the page now relies on javascript. Non-scripters and unusual browsers will at the very least arrive at your site, though not necessarily get the right content on that page, or content at all, depending on whether you use this for actual functionality or for more optional features. Search engines do not use javascript, so this is not SEO friendly.

You can, of course, make server-side scripting also catch and react to the hash, fixing only the initial load, and then assume the scripting hijacks and handles any further functionality.


[edit]

for history

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

The basic idea is that you could use an interval timer to poll the window.location and trigger a content load (the same way you did with bookmarks) whenever the .hash changes. Since this is scripting, other content (such as Flash) can also be controlled.

The idea is feasible and works Firefox, but only on certain (often 'recent') versions on of some other browsers (like Opera and Safari), and not at all on IE as it does not create history items for hashes.

If you want to use this and stick to the purely client-side solutions, you'll probably want to use the IE hidden iframe fix: in IE, a document.write to an iframe creates a history item. This means you can use the iframe to store state, more or less the same way you would use the hash in other browsers (except now writing and polling document content).


If you must have a back button in this way, the best way to get the widest browser support is to use one of the ready-made solutions out there. They might not work on everything, but they might work on enough (e.g. the list of browsers Yahoo considers A-grade), and will likely support more than your own quick-and-dirty solutions would. See e.g.:



[edit]

See also


[edit]

Semi-sorted



[edit]

URL parsing notes

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.



[edit]

Criticism on dynamic content loading

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

You should never do this just because you can, only when you can explain why it's added value.

There are few use cases where you could really explain why AJAXing in content actually has added value (and, to use the word a few more time, you aren't removing other value or having negative value from non-robust execution).


I generally run ideas past tests like:

  • It may break usability by making things behave unlike all other pages
    • may break 'open in new tab
    • may break ability to bookmark content
  • if the argument of perceived speed is usually weak - lag often trumps, and if page generation time is slow, you probably want to be cacheing things more. This even goes for some of the late-loading of secondary features.
  • If it is programmatically simple to do the exact same thing without AJAX, you should probably go without
  • it is extremely hard to make (and rare to see) solutions that work as robustly as basic-page-load pages. Doing the error handling well usually sucks up time. Dependencies in more complex solutions can become hell.


Possibly valid arguments:

  • If dynamic loading isn't a core feature but a nicity, you can argue for it
  • If the page is interactive by design, so bits change in context of others (e.g. tagging one of many elements, editing individual fields, 'related' features), you may be able to argue for it
  • Late loading of features which are slow but out of your control (e.g. lookups remote to you, not made by you)
[edit]

Metadata in (X)HTML

[edit]

rel and rev

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

On <a> links (but also other tags, notably <link>), the rel attribute is used to specify the type of relationship some external resource has to the current one that it is written in.

For example, you can specify a link and mark it as an index page pertaining the current content.

The rel and rev attributes are interpreted as case-insensitive space-separated lists, although there is rarely need for more than one.


rev specifies relations the other way around. For example, you can specify that the current document is an index that pertains to another document (likely various, of course). It does not see as much use in practice.


[edit]

Common values

The best known values (mostly used in rel) are probably:

  • stylesheet
    • commonly used, to include CSS
    • defined in HTML4(verify)
  • icon (or, in its original form, shortcut icon)
    • refers to an icon for this resource -- see favicon for more details.
    • informal, but widely adopted
  • nofollow
    • meant to prevent spam content from affecting search engines (not from happening; it only indirectly and not very effectively discourages it)
    • see e.g. [5], [6]
    • introduced as a convention (google, blogger.com)
[edit]

Others, and more reading

There are quite a few more, ranging form official, microformat, to barely even convention.


see resources such as:


And perhaps:



Relations and structure within a document set (standard):

  • start
  • next
  • prev (some UAs also allow 'previous')
  • up
  • contents (some UAs also also allow 'ToC')
  • index
  • glossary
  • copyright
  • chapter
  • section
  • subsection
  • appendix
  • help (?)
  • bookmark (?)


Others (standard, mostly HTML4, some HTML5 and not really current yet):

  • alternate: used to indicate alternative versions of this document
    • e.g. different languages, or a print version
    • defined in HTML4
  • meta: Refers to a metadata document, e.g. in RDF
  • profile A globally unique namespace for structured data -- regularly a link
  • role: indicates the role/purpose (See e.g. [7])
  • cite: Refers to a citation (see also the <cite> element[8])
  • canonical: lets you specify the URL (within the same domain) that has the canonical version of this page. (basically lets you manually specify what a search engine automatically needs to do with some regularity)


Microformats that use rel:

  • nofollow
  • rel-license: specify license for current resource (and link to it)
  • tag (rel-tag microformat, and see also [9])
  • rel-directory (link to directory listing that includes current resource)
  • rel-payment
  • vote-links (see e.g. [10])
  • XFN


Firefox' prefetching (proposed standard):


Proposed Internet Explorer 8 values:

  • Entry-Content
  • FeedUrl

Unsorted:

  • apple-touch-icon, apple-touch-icon-precomposed


[edit]

Meta tags

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.
[edit]

Standard, short tooltips

HTML4/XHTML's
acronym
,
abbr
and
dfn
(acronym, abbreviation and definition) seem to be pushed by W3's semantic direction.

Of coure, I and others abuse them a little, because they display a tooltip when hovered over, which is a nice, subtle help feature. I suggest you use dfn for this; it is the tag for which this use is closest to the intended one.

Using is simple; fill a title attribute with what should be displayed - or, if you want to be correct, the actual expanded acronym, full form of the abbreviation, or proper definition of the terms you use. These tags may well become quite semantically useful in the future.


[edit]

Clickable text that checks checkboxes, etc.

The
label
tag is made for this, so no scripting is required.

Set an element id on the input tag you want referenced, then set this id in the for tag for the label. This also allows e.g. putting the label in a different table cell, or other layouting construction.

Not everyone knows about this, but experience from regular interfaces will make people often instinctively try clicking the text (or, arguably, experience on the web will mean they learned they have to go for the checkbox/radio button itself, but it doesn't hurt to do it right).

[edit]

Selection

You can disable text selection, which is useful when imitating buttons, doing drag-and-drop and such.

Unfortunately, you can't do this purely with CSS. You need javascript.


[edit]

Browser share

Seems to depend a lot on the site type. Technical sites' statistics will regularly show 60-70% firefox, while common sites that non-technical people also widely use often show 60-70% IE, 20%-30% Firefox, ~10% Safari and other.

Note that while IE is still one of the largest, it is also the only serious browser that is not cross-platform.


Note that many individual sites' statistics are skewed by the fact that they count only access to their own site. If it's MSN, use is going to get mostly IE. If it's a very technical site, it's going to get mostly Firefox.


See also:

[edit]

Resolution, browser size

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

Most computers now (~2008) use a resolution at or beyond 1024x768. That is to say, 800x600 is becoming outdated.

Note that a lot of people do not maximize their windows. as such, what matters is the width the window ends up having rather than the monitor resolution.


In addition, when looking at the width of actual page content, you also have to consider browser scrollbars (and borders, though those fall away in fullscreen), so the actual width available to you is a little under the full-screen/windowed size. This is important in fixed-size designs in that you can avoid making them too wide.

The (non-maximized) window width is pretty much always above 600px or 700px (in most resolutions), usually above 740px.


For maximized windows:

You often want to avoid making your website use too much width, if only to avoid making your text too wide.

A fluid design may be useful - that is, one whose width looks good at 740px wide and stretches to perhaps 1000 when available. Such sites will look nice and spacy at ~1000 and beyond, but will not get annoyingly scrollbarrish before you sink below ~750 pixels, so that yo do not particularly force people to maximize their browser (and the few remaining 800x600 users, who are likely to maximize their browser, are also happy enough).


(Note also that people with larger screens will often still browse fullscreen, so you may want to think about the separation of items at that scale.)



[edit]

fluid vs. fixed width

A never-ending debate.


Usability considerations:

  • Paragraphs that are very wide are harder to read, so there is an upper limit (arguably you can use max-width elements, although I'm not sure about IE7's support)
  • pages that are wider than they are high (in any way, e.g. menu items on one side, text on the other) are also often not easily scannable. Centering things a bit helps that, mind.
  • More width can be utilized in whitespace, which is nice for readability.
  • It may be a good idea to build in whitespace that will be compressed if the window gets smaller


Coder considerations:

  • If you want bounds, you can have relatively fixed elasticity work inside, say, the 800 to 1200 pixel range. Given decent design, this makes most people happy.
  • fixed with fixes browser (re)layouting bugs (particularly IE, particularly ≤6)
[edit]

Text scalability


[edit]

Web frameworks / code hosting

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

Numbered links are to reviews, discussions, notes and such.

[edit]

Ruby

[edit]

Python

See Python notes/Web

[edit]

.NET

[edit]

Java

[edit]

Links

Overviews and references:


Standards and behaviour:


Semi-sorted:

Charts:

CSS:

Entities (XML):



[edit]

Unsorted

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

In dynamic scripts, you should try to set the Content-Type (or have an implied one), or the browser might try to auto-detect it, which may be unpredictable in dynamic enough responses.

[edit]

Mobile browsers, mobile site versions

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

See also:

[edit]

Alternative names for AJAX seen around

...just because it amuses me.


AHAH: Asynchronous HTML and HTTP


AJAH: Asynchronous JavaScript And HTML


AXAH: Asynchronous XHTML and HTTP


JAHAH: Javascript Asynchronous HTML and HTTP (intended to be JSON(P)-transported)


[edit]

Static path stuff

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine. 
/mobile/
/mobi/
/m/
/iphone/
/apple-touch-icon.png
/favicon.ico


[edit]

CRUD, REST, and such


[edit]

Entities


[edit]

SVG, VML, canvas

All major browsers except IE (up to 7) render SVG natively. IE7 needs the adobe plugin, but it is being discontinued, probably in favour of Flash (*sigh*).


IE has its own vector language, VML, supported from IE5 on. Nothing else seems to suport it.

(There seems to be third-party code such as [12], which draws SVG in VML.)

Note that in some aspects, SVG is more annoying than VML.


Canvas is part of the HTML5 standard, so not officially supported, but all major browsers except IE seem to support it. (again, there is third party code, like [13], that supports canvas in IE)


Some systems use whatever is available to allow the simpler draw command anywhere. This includes:

  • dojo.gfx (apparently an API that offers the intersection between SVG and VML)


[edit]

Minimal HTTP request

HTTP 1.1 requires a Host header, so one minimal example would be: 

GET / HTTP/1.1
Host: vhost.example.com

Command-line example: 

echo -e "GET / HTTP/1.1\nHost: vhost.example.com\n" | netcat example.com 80

(-e interprets the newlines)

[edit]

Buttons

Functionally, a button is a submit button, a reset button, or a push button (no event handlers other than those that you add via script).

It's generally best to stick to submit (and reset, if you think it useful), because script-only buttons do not degrade gracefully, and image buttons can be overkill (IE peculiarities apply)

  • type="submit": basic submit button (text it displays can be controlled via the value attribute, e.g. value="Go!")
  • type="button": push button (does nothing by itself; handy to script buttons that shouldn't submit)


The <button> also has a type:

  • type="submit" (default, except in IE)
  • type="button"
  • type="reset"


IE is buggy (<input type="image" ... and to <button>s in general). Related notes:

  • If a (restyled) <input type="submit" ... works for you, use that.
  • A <button>'s submit value is innerText (recently IE started submitting the value attribute instead, as it should), and a <input type="image" ...'s submission value also isn't always what it should be. If you want to test for submission, the easy workaround is an <input type=hidden> with a name you'll test for.
  • a <button> should default to type="submit", but in IE defaults to type="button". The most obvious thing to do is probably to always explicitly set a type.

See also:


[edit]

dynamic apps, streaming, and error handling

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

For web applications to display a sensible/nice error message/page, it must not already have sent data to the browser, or it will risk corrupting the response. (This isn't always the same as '...have sent data into the framework' as buffering may apply, but you generally can't count on that or control it very well)


This is somewhat obvious, but there is the concept of streaming data out, writing it out of the app as fast as the underlying mechanisms allow, because many browsers will start rendering (HTML) earlier based on partial information (and, in the case of sizeable data, may reduce memory allocation needed on the server side).

(Note that incremental rendering that may both help and reduce speed -- that is, in rendering time and in perceived page loading speed, which are also not the same thing)


Given this, a good modelling rule of thumb is "finish all your logic work and decide on the presence of an error before you send any data, even when you are going to be streaming data to the browser".


Depending a little on framework implementation, and on actual usage, this often lets you deal better with wrapped applications, and with your own generation of an error page. The main reason is that you don't force the application to use a buffer (of unsure size) to be able to do error handling.


Some frameworks, particularly those that model application mounting and middleware, may modelled for error passing so that a wrapping application can be left to decide.

The example I'm thinking of is WSGI: 

try:    
    # regular application code here
    status = "200 OK"
    response_headers = [("content-type","text/plain")]
    start_response(status, response_headers)
    return ["normal body goes here"]
except: 
    status = "500 Internal Server Error"
    response_headers = [("content-type","text/plain")]
    start_response(status, response_headers, sys.exc_info())
    return ["error body goes here"]
# should trap runtime issues like 
#     in a separate handler before this bare 'except:'...

Notes:

  • You don't need to catch the error into a variable; WSGI uses its own error mechamism and fetches it separately (sys.exc_info()) and acts on it and/or passes it through
  • You could treat specific errors differently (assign sys.exc_info() into variables and test those), particularly runtime errors as you may want to react differently to those.
  • WSGI also allows streaming, but you have to know about some details to use it well.


Of course, practice is less back and white.

Some pages you can easily rewrite into a return-as-a-single-block. Others are to be expected to take longer and would render faster if streamed to some degree (faster than the intervals at which the browser re-renders, which varies).

There are enough cases where page generation acceptably incremental, par

Retrieved from "http://helpful.knobs-dials.com/index.php/General_webdev_notes"