- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sat, 03 Jul 2004 14:02:36 -0400
Lachlan Hunt wrote: > I was thinking that there are different cases where mutually exclusive > sections are used. For example: [<br>] > 1. In wizard interfaces where the user must sequentially step through > each, usually with Next and Back buttons. > This could use something like <sequential> for the container. > > eg. > <sequential> > <exclusive>...</exclusive> > <exclusive>...</exclusive> > </sequential> > > (my preference is for <exclusive>, rather than <mxsection>, simply > becuase I like actual words, rather than abbreviations where possible, > and when there's no benefit of either being shorter to type) > > 2. In options/properties dialogs, or other tabbed interfaces where the > user can view them in any order, usually with tabs or buttons. > This could use something like <concurrent> for the container. > eg. > <concurrent> > <exclusive>...</exclusive> > <exclusive>...</exclusive> > </concurrent> > > The element names could probably be better, expesially <concurrent>. > I wanted an antonym for sequential, and that was the most appropriate I > could find with my limited research. I was thinking something similar, but I had planned to use CSS to differentiate tabs from a wizard rather than tabs. However, I believe your method is better. The fact that the later sections in a wizard depend on the previous ones is more semantic than presentational. The elements names are a bit on the long side, and they aren't the most common English words, which worries me a bit. Although abbreviations like <li> and <sup> are annoying from a readability standpoint, there are a lot of computer user and even webmasters out there that aren't exceptional typist and get frustrated with writing really long tag names over and over again. If I had to, though, I could live with the names as they are. Then again, I took a community college typing course when I was still in high school, so my typing skills are a bit better than average. These elements are still a problem in the Element-Eating-Browser, though. See below... >> The problem here that you're ignoring is that in the most common >> web browser in the world doesn't even allow styling for these new >> elements, which means they degrade into nothing but their child >> contents. In fact, the opening and closing tags will be treated as >> separate, stand-alone elements, so the DOM will have all their >> contents as siblings rather than children. > > So, effectivly they degrade to unstyled <div> or <span> elements > (depending on whether it defaults to block or inline styling ? I'd > assume inline, which is effectivly no style at all, but I could be > wrong) No, they degrade nothing at all. They stay in the DOM, but they're really no better than comment blocks in IE. So instead of your above <concurrent> example being rendered like this (with indent indicating parent-child relationships in the DOM)... <concurrent style="display: block"> <exclusive style="display: block"> ... </exclusive> <exclusive style="display: block"> ... </exclusive> </concurrent> ...It would render in IE like this... <concurrent style="display: none" /> <exclusive style="display: none" /> ... <slash_exclusive style="display: none" /> <exclusive style="display: none" /> ... <slash_exclusive style="display: none" /> <slash_concurrent style="display: none" /> So you can see why I'm not thrilled about new elements from the standpoint of graceful degradation to IE 6.0. It's not so bad if they're stand-alone (forget the term for this), but if they actually serve as a container, you have to use Javascript just to put the contents in a styled container. Personally, I'm beginning to think we shouldn't worry about IE. We could just tell everyone running IE with Javascript disabled that if they want to use Web Apps 1.0, they either need JS turned on or they need to get a standards compliant browser. You never know; Microsoft could turn around tomorrow and fix this problem so that you can apply styling to unknown elements. /me shrugs.
Received on Saturday, 3 July 2004 11:02:36 UTC