the target attribute for the a tag is deprecated. Some alternatives are out there, including assigning a class or using rel=”external”, then iterating through the page to spawn a new window using JS. Is that cheating? Not to mention.. is iterating through an entire page a drain on client resources?

There is always the old fallback, the ‘official’ way.

The modularisation of XHTML 1.1 breaks down XHTML 1.0 Strict into a collection of abstract modules, grouped by related elements and attributes. The idea behind modularisation is instead of having one huge DTD that defines everything; modules are used as and when required.

- From http://accessify.com/features/tutorials/new-windows/

Yes, George, that’s xhtml1.1. So what’re the differences between 1.1 and 1.0? According to the w3c,

This Appendix describes the differences between XHTML 1.1 and XHTML 1.0 Strict. XHTML 1.1 represents a departure from both HTML 4 and XHTML 1.0. Most significant is the removal of features that were deprecated. In general, the strategy is to define a markup language that is rich in structural functionality, but that relies upon style sheets for presentation.

The differences can be summarized as follows:

• On every element, the lang attribute has been removed in favor of the xml:lang attribute (as defined in [XHTMLMOD]).
• On the a and map elements, the name attribute has been removed in favor of the id attribute (as defined in [XHTMLMOD]).
• The “ruby” collection of elements has been added (as defined in [RUBY]).

-From http://www.w3.org/TR/xhtml11/changes.html

Well I can handle those.

I’m debating if this is the best way to handle this. Is a custom DTD a good direction?

The whole modularization seems a bit ‘off’ to me. So if I use this DTD, it is okay for me to target a different window, whereas others should not? Is that because if you’ve taken the trouble to research the various modules, they figure you won’t abuse the poor target?

You can’t currently use CSS to target input elements of a specific type. (i.e. radio, text, etc). This can be a pain when you want to set padding on radio buttons, or a width on textfields. Today’s issue was adding left padding to a button.

I decided to throw together some script to find these elements and apply the appropriate style info, and this is what I came up with:

function cssInputTypeFix(tipe, stile,val) {
  <!-- until browsers support CSS input type -->
  var inputs = document.getElementsByTagName("input");
     for (var i = 0; i < inputs.length; i++) {
         if (inputs[i].getAttribute("type") == tipe) {
             inputs[i].style[stile]= val;
         }
      }
   }

I then applied this when the page loaded, with Simon Willison’s handy dandy addLoadEvent script

addLoadEvent(function() {
   //cssInputTypeFix(type,style,val)
   cssInputTypeFix('button', 'marginLeft', '5px');
   }
)

And of course, as soon as I finished I did a search on the web and found this article: http://www.dustindiaz.com/input-element-css-woes-are-over/ It is along the same lines, although he creates styles such as input.text, input.button and uses the onload event to append the appropriate classname. Well, mine can do that too

cssInputTypeFix(‘button’, ‘className’, ‘button’)

where you have a class named button.

From Chapter 9: CSS-DOM.

A neat example on how to target elements in relation to their siblings. The following may be used to attach specific presentation to the element following another specific element. The example given is “the element immediately following an h2″. I like this; reminds me of the proposed section element in XHTML2. Headers are semantically associated with the content that follows, and often there are presentational implications as well.

This is also similar to the CSS pseudo-classes “first-child” and “last-child”.. which are not widely supported in modern browsers. This is a way to achieve those effects while browsers catch up.

Code:

function getNextElement(node) {
  if (node.nodeType ==1) {
      return node;
  }
  if (node.nextSibling) {
     return getNextElement(node.nextSibling);
  }
  return null;
}

And the code they used that called this one:

function styleHeaderSiblings() {
 if (!document.getElementsByTagName) return false;
 var headers = document.getElementsByTagName("h2");
 for (var i = 0; i < headers.length; i++) {
   var elem = getNextElement(headers[i].nextSibling);
   addClassName( elem, "intro");
 }
}

Thoughts: Can this help with setting up tabs, etc? Although we seem to be moving towards the sliding doors tabs, what about using this to determine if you are at the first or last tab, and load the appropriate image accordingly?

…….

And as I read further…
The book then goes onto talking about abstraction. The styleHeaderSiblings function is very specific, it deals with h1s and the classname “intro”. This should really be made more generic so it is reusable. We really should modify it to take in a tag and classname as arguments.

function styleElementSiblings(tag, theclass) {
 if (!document.getElementsByTagName) return false;
 var headers = document.getElementsByTagName(tag);
 for (var i = 0; i < headers.length; i++) {
   var elem = getNextElement(headers[i].nextSibling);
   addClass(elem, theclass);
 }
}

I should also store this somewhere.. and here seems as good a place as any!

function insertAfter(newElement, targetElement) {
  var parent - targetElement.parentNode;
  if (parent.lastChild == targetElement) {
     parent.appendChild(newElement);
  } else {
     parent.insertBefore(newElement, targetElement.nextSibling);
  }
}