James McParlane's Blog

I’m experimenting with describing all my CSS and JavaScript behaviors in XML. Currently working on allowing the optional nesting of CSS selectors which results in rules generated with normalised versions.

for example..

<selector css="pre">
    <style>
        font-size: 1.1em;
        background: #f0f0f0;
        -moz-border-radius: 10px;
        padding: 1em;
    </style>
    <selector css="span">
        <style>
            font-weight: bold;
        </style>
    </selector>
</selector>

I’m hoping this will make my life a little easier.

Need a way to specify the kind of selection being made. child, descendant etc. This is very very important for usability and for generating something that create a CSS that will render without boiling the ocean.

Read a post by Simon Willison today about taming the CSS monster, the comments pointed to some interesting resources, I added my 2c. I think what I am building in WireWrap will go part of the way towards solving the problem for me and improve the system that I am building as a whole – but as a general solution what I think we really need is good support in the IDE for CSS introspection and management.

All the rest is self discipline, good planning and knowing how CSS actually works.

Found an issue with Safari (tested against version 1.3.1)

With the following code….

var l_a5 = document.getElementById("a5");
l_a5.onclick = f1; 
l_a5.onclick = null; 
l_a5.addEventListener("click",f2,true); 

.. when clicking on the element referenced by l_a5 will result in both events triggering in the order f2,f1

Every other browser that supports addEventListener only triggers the single event f2

If you think about f1 should never fire, because the reference to it has been set to null – somehow, Safari remembers.

Here is a testcase  (see the last test) for browsers that support addEventListener which are off the top of my head Netscape,Firefox,Mozilla and Safari.

The testcase is used to show how different browsers handle a mixture of event listeners added by addEventListener  and inline or assigned eg. element.onevent = function.  Here is another testcase for my addEventListener replacement where you can see that I have made an attempt to normalise all the different quirks and emulate the way that the latest Mozilla engine handles some of these situations for all other browsers.

I’ve made a note in more detail on this problem here.

Just added a feature to my JavaScript libraries so that they can work out what other JavaScript libraries need to be included and then includes them in the correct order. Most of the work is done by the foloowing three functions: MwUse , MwRequire and MwInclude .

Not working under all browsers yet – but shows lots of promise!

For example, in one of my test cases I specify the following script includes

<script language="JavaScript" type="text/javascript" src="mw_lib.js" ></script>
<script language="JavaScript" type="text/javascript" src="mw_lib_page.js" ></script>

mw_lib.js is the core library and depends on no external libraries so it does not trigger the load of any dependencies.

mw_lib_page.js however has the following two dependencies decared with the following statements.

// Ensure we have the namespace we need before we load this page
MwUse("MetaWrap","mw_lib.js");
// Ensure we have the namespaces/objects we need before we start executing
MwRequire("MetaWrap.Page.Element.addEventListener","mw_lib_page_element_addhandler.js");

MwUse checks to see if the specified object exist, if not it loads the corresponding JavaScript file (in a future feature it will work out the file name from the object name if the filename is not provided, hence my strict naming standard).

So mw_lib_page.js is declaring that it needs the namespace MetaWrap which can be found in mw_lib.js and that if you want to even load and parse this library, you better have it. But we already have that namespace loaded so nothing happens. if this was another namespace and file pair, such as

MwUse("MetaWrap.Test","mw_lib_test.js");

Then mw_lib_test.js would be downloaded and included by MwInclude before mw_lib_page.js loaded any further.

MwRequire checks to see if the object exists and loads the corresponding javascript file only at the point of initialising the library, so its a kind of defered MwUse. Any files that calls, MwRequire is declaring that the file can continue to parse but before you execute any of the methods in the file, you need to include the specified library or it Would Be Bad.

To initialise the library we call MwInit() (looking into automating this – stay posted)

At this point all the namespaces/objects that have been specified by MwRequire are loaded and in this case its mw_lib_page_element_addhandler.js, which contains the following lines of code in its header.

// Ensure we have the namespaces we need
MwUse("MetaWrap","mw_lib.js");
MwUse("MetaWrap.Page","mw_lib_page.js");
MwUse("MetaWrap.Page.Element","mw_lib_page_element.js");

So it checks for MetaWrap, which it has, and then MetaWrap.Page, that it already has, but it does not have MetaWrap.Page.Element so it loads mw_lib_page_element.js, which contains the following

// Ensure we have the namespaces we need
MwUse("MetaWrap","mw_lib.js");
MwUse("MetaWrap.Page","mw_lib_page.js");

And all of these namespaces are loaded – so no more loads are triggered.

It solves some nagging problems for me and counters human error so I’m really liking this new feature.

Just lodged my first bug for Opera, only to figure out 5 mins after I hit submit that its not a bug with Opera, Its a bug with every other browser.

Seems that in Opera 8.5 when you use addEventListener with capture set to true, it behaves differently to the other common browsers that use addEventListener which are Safari and Mozilla.

On further examination (see below) its conceivable that Opera is the only one to follow the spec.

Here is my testcase for it

Try the CAPTURE example (the second test from the top)  First run it in Firefox or Safari, then Opera.

Try any of the ‘MIXED’ tests that capture on more than one element MIXED4, MIXED5, MIXED6, MIXED7 or MIXED8 and compare behavior with Safari and Firefox which follow the w3 spec.

Now From the spec, note the bit in bold…

Event capture is the process by which an EventListener registered on an ancestor of the event’s target can intercept events of a given type before they are received by the event’s target. Capture operates from the top of the tree, generally the Document, downward, making it the symmetrical opposite of bubbling which is described below. The chain of EventTargets from the top of the tree to the event’s target is determined before the initial dispatch of the event. If modifications occur to the tree during event processing, event flow will proceed based on the initial state of the tree.

An EventListener being registered on an EventTarget may choose to have that EventListener capture events by specifying the useCapture parameter of the addEventListener method to be true. Thereafter, when an event of the given type is dispatched toward a descendant of the capturing object, the event will trigger any capturing event listeners of the appropriate type which exist in the direct line between the top of the document and the event’s target. This downward propagation continues until the event’s target is reached. A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered.

If the capturing EventListener wishes to prevent further processing of the event from occurring it may call the stopProgagation method of the Event interface. This will prevent further dispatch of the event, although additional EventListeners registered at the same hierarchy level will still receive the event. Once an event’s stopPropagation method has been called, further calls to that method have no additional effect. If no additional capturers exist and stopPropagation has not been called, the event triggers the appropriate EventListeners on the target itself.

Although event capture is similar to the delegation based event model in which all interested parties register their listeners directly on the target about which they wish to receive notifications, it is different in two important respects. First, event capture only allows interception of events which are targeted at descendants of the capturing EventTarget. It does not allow interception of events targeted to the capturer’s ancestors, its siblings, or its sibling’s descendants. Secondly, event capture is not specified for a single EventTarget, it is specified for a specific type of event. Once specified, event capture intercepts all events of the specified type targeted toward any of the capturer’s descendants.

The bit in bold disturbs me, because I don’t think Safari or Firefox obeys this and if I am right then I suspect that Opera may in fact be the only one to obey the spec properly.

Going back and looking at the test case, if you click on an element that has a listener added with capture, it is not triggered- as per the spec.

Compare MIXED2 and MIXED3. Its spot on as the spec describes