Java ' C' handu: March 2012

Saturday, March 31, 2012

CSS : Containing block definition

The position and size of an element's box(es) are sometimes calculated relative to a certain rectangle, called the containing block of the element. The containing block of an element is defined as follows:

The containing block in which the root element lives is a rectangle called the initial containing block. For continuous media, it has the dimensions of the viewport and is anchored at the canvas origin; it is the page area for paged media. The 'direction' property of the initial containing block is the same as for the root element.
For other elements, if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest block container ancestor box.
If the element has 'position: fixed', the containing block is established by the viewport in the case of continuous media or the page area in the case of paged media.
If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' of 'absolute', 'relative' or 'fixed', in the following way:
1. In the case that the ancestor is an inline element, the containing block is the bounding box around the padding boxes of the first and the last inline boxes generated for that element. In CSS 2.1, if the inline element is split across multiple lines, the containing block is undefined.
2. Otherwise, the containing block is formed by the padding edge of the ancestor.
If there is no such ancestor, the containing block is the initial containing block.

In paged media, an absolutely positioned element is positioned relative to its containing block ignoring any page breaks (as if the document were continuous). The element may subsequently be broken over several pages.
For absolutely positioned content that resolves to a position on a page other than the page being laid out (the current page), or resolves to a position on the current page which has already been rendered for printing, printers may place the content

on another location on the current page,
on a subsequent page, or
may omit it.

Note that a block-level element that is split over several pages may have a different width on each page and that there may be device-specific limits.

With no positioning, the containing blocks (C.B.) in the following document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
   <HEAD>
      <TITLE>Illustration of containing blocks</TITLE>
   </HEAD>
   <BODY id="body">
      <DIV id="div1">
      <P id="p1">This is text in the first paragraph...</P>
      <P id="p2">This is text <EM id="em1"> in the 
      <STRONG id="strong1">second</STRONG> paragraph.</EM></P>
      </DIV>
   </BODY>
</HTML>

are established as follows:

For box generated by	C.B. is established by
html	initial C.B. (UA-dependent)
body	html
div1	body
p1	div1
p2	div1
em1	p2
strong1	p2

If we position "div1":

#div1 { position: absolute; left: 50px; top: 50px }

its containing block is no longer "body"; it becomes the initial containing block (since there are no other positioned ancestor boxes).
If we position "em1" as well:

#div1 { position: absolute; left: 50px; top: 50px }
   #em1  { position: absolute; left: 100px; top: 100px }

the table of containing blocks becomes:

For box generated by	C.B. is established by
html	initial C.B. (UA-dependent)
body	html
div1	initial C.B.
p1	div1
p2	div1
em1	div1
strong1	em1

By positioning "em1", its containing block becomes the nearest positioned ancestor box (i.e., that generated by "div1").

Wednesday, March 28, 2012

CSS Selector Syntax

http://www.w3.org/TR/CSS2/selector.html#type-selectors

Pattern	Meaning	Described in section
*	Matches any element.	Universal selector
E	Matches any E element (i.e., an element of type E).	Type selectors
E F	Matches any F element that is a descendant of an E element.	Descendant selectors
E > F	Matches any F element that is a child of an element E.	Child selectors
E:first-child	Matches element E when E is the first child of its parent.	The :first-child pseudo-class
E:link E:visited	Matches element E if E is the source anchor of a hyperlink of which the target is not yet visited (:link) or already visited (:visited).	The link pseudo-classes
E:active E:hover E:focus	Matches E during certain user actions.	The dynamic pseudo-classes
E:lang(c)	Matches element of type E if it is in (human) language c (the document language specifies how language is determined).	The :lang() pseudo-class
E + F	Matches any F element immediately preceded by a sibling element E.	Adjacent selectors
E[foo]	Matches any E element with the "foo" attribute set (whatever the value).	Attribute selectors
E[foo="warning"]	Matches any E element whose "foo" attribute value is exactly equal to "warning".	Attribute selectors
E[foo~="warning"]	Matches any E element whose "foo" attribute value is a list of space-separated values, one of which is exactly equal to "warning".	Attribute selectors
E[lang\|="en"]	Matches any E element whose "lang" attribute has a hyphen-separated list of values beginning (from the left) with "en".	Attribute selectors
DIV.warning	Language specific. (In HTML, the same as DIV[class~="warning"].)	Class selectors
E#myid	Matches any E element with ID equal to "myid".	ID selectors

Tuesday, March 20, 2012

Multipart/form-data

Excerpt from http://www.ietf.org/rfc/rfc2388.txt

In many applications, it is possible for a user to be presented with
   a form. The user will fill out the form, including information that
   is typed, generated by user input, or included from files that the
   user has selected. When the form is filled out, the data from the
   form is sent from the user to the receiving application.

multipart/form-data" contains a series of parts. Each part is
   expected to contain a content-disposition header [RFC 2183] where the
   disposition type is "form-data", and where the disposition contains
   an (additional) parameter of "name", where the value of that
   parameter is the original field name in the form. For example, a part
   might contain a header:

        Content-Disposition: form-data; name="user"

   with the value corresponding to the entry of the "user" field.

As with all multipart MIME types, each part has an optional
   "Content-Type", which defaults to text/plain.  If the contents of a
   file are returned via filling out a form, then the file input is
   identified as the appropriate media type, if known, or
   "application/octet-stream".  If multiple files are to be returned as
   the result of a single form entry, they should be represented as a
   "multipart/mixed" part embedded within the "multipart/form-data".

   Each part may be encoded and the "content-transfer-encoding" header
   supplied if the value of that part does not conform to the default
   encoding.

As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending appliction and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

If the value of a form field is a set of files rather than a single
   file, that value can be transferred together using the
   "multipart/mixed" format.

Forms may request file inputs from the user; the form software may
   include the file name and other file attributes, as specified in [RFC
   2184].

   The original local file name may be supplied as well, either as a
   "filename" parameter either of the "content-disposition: form-data"
   header or, in the case of multiple files, in a "content-disposition:
   file" header of the subpart. The sending application MAY supply a
   file name; if the file name of the sender's operating system is not
   in US-ASCII, the file name might be approximated, or encoded using
   the method of RFC 2231.

   This is a convenience for those cases where the files supplied by the
   form might contain references to each other, e.g., a TeX file and its
   .sty auxiliary style description.

Friday, March 2, 2012

How to track index in 'for' loops when we have callback inside it

A typical problem faced while working with javascript code involving "for" loop with callbacks created in each run of the loop is that when the callback is actually executed the value of loop index is different than the one when the callback is created.

For Example

<script>
for(var i=0;i<10;i++){
setTimeout(function(){alert(i);}.1000);
}
</script>

In each run of the loop a function object is created with its scope set to "global object".This global object contains variable i, the index of for loop.
All the 10 function objects will be referencing this 'i' in the global object;
By the time call backs are run ,for loop exits and the value of i is 10.So when the call back are actually run, the value of i , which is now '10' is printed.

Simple solution --- Anonymous function.
This works because as the scope of each function object created inside for loop now contains activation record of anonymous function (this record contains param index with value of 'i' in the current run of the loop).When the function are actually executed they refer to value of index in its scope.
<script>
for(var i=0;i<10;i++){
(function(index){
setTimeout(function(){alert(index);}.1000);

} )(i);
}
</script>