Re: [WSG] Mac FF hidden div still shows scrollbars

2005-12-22 Thread Ben Curtis


On 12/22/05, Thomas Livingston [EMAIL PROTECTED] wrote:

Hi listers,

We have a div being hidden (visibility:hidden;) and then using
javascript to show hide layers (sort of a pop-up but not sorta thing).

If we give it a height and apply overflow:scroll; (or auto) it looks
and works dandy, except for Mac FF (1.5). We are still seeing the
div's scroll bars when in it's hidden state.

Anyone come across this before and fix it?



I've seen other evidence that Mac browsers that call the OS for  
elements (scrollbars, buttons, etc.) have trouble with changing styles.


One thing you might try is to have the javascript change the class,  
instead of changing a style attribute. This also helps because you  
just style the two states of the div however you please, and the  
javascript never needs to change.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] positive-discrimination === not positive and IMG properties

2005-12-19 Thread Ben Curtis


RE: my htc to remove uneeded alt text after an image loads.


On Dec 15, 2005, at 12:44 PM, Derek Featherstone wrote:


On 12/15/05, Ben Curtis wrote:


The alt text is removed from the element if the image is loaded.

...

You attach it to the img selector in your css, or a more specific
selector if you don't want all images to be affected.


I can't see why you'd want it to have an effect on any images, to be
honest.


You might have missed my explanation. The alt text popup was  
obscuring the more helpful text I was providing. IE's mishandling of  
the alt text was the issue.




I would assume that the blind have their browsers set to not load
images. I may be dreadfully wrong in that assumption, but if the
images don't load then this code has no effect and the alt text
remains.


Dreadfully wrong. Well, you said it, not me :-)

The blind have just as many varied setups and configurations as the
unblind.


Sure. Makes sense. But 100% of the half dozen blind people I've  
worked with had their browsers set to not load images. I'm sure in  
the larger population it's less than 100%, but surely it is most of  
this audience?




If you take away alt text, you take away *critical*
information.

Even if you target specific images via CSS selectors, I'd question
whether nor not it should be removed at all. After all - how do you
decide which ones to take away and which ones not to take away?


I take away only the alt text that is useless if the image loads.  
This is why I target by CSS selector. In my particular case, there  
are two images side by side, the first is the abbreviation for the  
second. This way, when you tab to the nav link and the abbreviated  
alt text is removed, you get the screen reader saying the full word  
instead of the abbreviation.


The fact is that in my tests with CSS on/off, images on/off,  
javascript on/off, and visual/audible browsing, removing the alt text  
of only the fully loaded images of abbreviations in Windows IE  
created the most consistently understandable navigation. Every other  
option was stymied by IE's mishandling of the alt text, and led to a  
more confusing page.


So I agree with your stance in principle. But if you stand by it  
without testing the ramifications on the users, I think it's wasted  
effort.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] positive-discrimination === not positive and IMG properties

2005-12-15 Thread Ben Curtis


On Dec 14, 2005, at 3:10 PM, Rebecca Cox wrote:

Will this also prevent the alt text from being available in say the  
JAWS screen reader, (which uses Internet Explorer), when the user  
has javascript enabled?


Or is it just the tooltip behaviour not the alt content which is  
removed by the htc ?



The alt text is removed from the element if the image is loaded. It's  
a very simple htc that runs this code for each image after the page  
loads:


if (element.complete) element.alt = '';

You attach it to the img selector in your css, or a more specific  
selector if you don't want all images to be affected.


I would assume that the blind have their browsers set to not load  
images. I may be dreadfully wrong in that assumption, but if the  
images don't load then this code has no effect and the alt text remains.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] positive-discrimination === not positive and IMG properties

2005-12-14 Thread Ben Curtis


On Dec 13, 2005, at 1:37 PM, Ric  Jude Raftis wrote:

Alt attribute content only provides tool tips in IE because it is a  
non-compliant browser.  They do not display in other browsers.  The  
title attribute however, does display in Firefox, but not sure  
about Opera et al.



On my tests, Firefox, Safari, and Opera display the title. IE will  
display title text if it is provided, and alt text if there is no  
title text.


My current project has css rollovers display the full text of an  
abbreviation within an image. The title text was the full text, but  
that meant that a hovering mouse would trigger the full text rollover  
*and* the full text title popup -- a confusing double effect.


So I nixed the title, but then IE displayed the alt text  
abbreviation, which was worse because now the abbreviation was  
concealing the full text. An empty title attribute (title=) didn't  
override this behavior, so I wrote an htc called Alt Destroyer that  
will remove the alt text in IE for images that are successfully  
loaded. Not stress tested, but so far works like a charm to prevent  
ugly alt popups in IE.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Flash and Validation

2005-12-13 Thread Ben Curtis


On Dec 12, 2005, at 10:18 AM, morten fjellman wrote:

I have used the following code for a couple of years now, and have  
never had any problems with it.


object

...

!--[if !IE] --
object data=header.swf

...

/object
!-- ![endif]--
  /object



I'm about to launch a site using a slightly enhanced form of this  
technique, based on Hixie's method:


!--[if IE]
object width=89 height=13 type=application/x-shockwave-flash  
codebase=http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/ 
swflash.cab#version=7,0,0,0

param name=movie value=/swf/audio.swf /
param name=flashvars value=code=Van_Vorst_Park /
![endif]--!--[if !IE]--
object type=application/x-shockwave-flash width=89 height=13  
data=/swf/audio.swf?code=Van_Vorst_Park

!--![endif]--
	a href=/Film/Van_Vorst_Park/audioblog_1.mp3img src=/img/text/ 
buttons/audioblog.gif width=89 height=13 alt=audioblog //a

/object

The enhancement is mostly some combined redundancies, and an  
alternate content viewable by IE. (Morten's version hides the inner  
object and therefore its alternate from IE.)


The only problems I've found with variants of Hixie's method do not  
apply to my site, but may apply to you. Safari apparently does not  
read the param values of an object tag. (Please let me know if I'm  
misinterpreting its symptoms.) This means that flashvars need to be  
passed in the url (bad for caching), and that things like bgcolor or  
wmode need to be set as attributes within the object tag. Such  
proprietary attributes, of course, invalidate the tag.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Altering a Valid (X)HTML with DHTML = Is it still REAL LY valid?

2005-11-14 Thread Ben Curtis



It's a tricky one


How?

If a tree falls in a  wood and no-one hears it - does it still  
make a noise?


Well, it is tricky one. It certainly makes some air waves, ...

So, kidding aside, invalid is invalid.



Except that validity is a concept that can only be applied to  
documents. Is the document valid? Yes. QED? Nope. It's tricky.


Once the document is parsed, the W3C is very clear on the matter: how  
these data, nodes, etc., are represented in the internal memory  
structure of the client application is entirely up to the vendors --  
and I can pretty well assure you that they all do it differently.  
However, they must maintain the DOM API, which is designed to work in  
specific ways. These ways will permit an in-memory structure of nodes  
and attributes that could only be derived from an invalid document if  
they were wholly derived from a document; the DOM API permits them,  
so they are valid internal structures.


So, validity cannot be applied to the in-memory document, once  
parsed. But, of critical importance is that if a variety of vendors  
do things differently, and the only thing linking them together is  
the validity of the source document. Straying from the interpretation  
of that document means you are possibly venturing into areas where  
the vendors disagree.


It's not a validity issue; it's a compatibility issue. And, given the  
confluence of specs involved (HTML, XML, CSS, DOM), there ought to be  
plenty of guaranteed-compatible room outside of what would come from  
valid documents. But staying valid would be easier, I should think,  
though easier is not always the primary concern.


Is it REALLY valid?

To sum up my position: it's like asking if a deep blue sky with  
little puffy clouds if REALLY sweet? Sweet, in this case, has nothing  
directly to do with sugar, but how we humans react to sugar.


Valid is a term that does not directly apply to the in-memory data  
structure; it is, nevertheless, a helpful and analogous concept to  
keep in mind. And it helps keep your code sweet.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] PNG Question

2005-11-14 Thread Ben Curtis


Only supported in IE 6 with a hack, kind of an ugly one too as it  
renders the PNG's transparent area with a mid gray until it has  
finished loading, I guess if it's on a small image it's ok.


I've had a lot of luck with PNG Behavior:
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html

It's an .htc, which you may have to configure your server to deliver  
properly. You assign the behavior to the img elements via your CSS  
rules. Handles src changes to/from other pngs or non-pngs. (This only  
works with actual img tags; if you want to affect pngs as your  
background-image, then you should apply the filter directly in your  
CSS, and my advice is to make the image the same size as the  
container it's backgrounding.)


I've hacked this a bit, so that the img is visibility:hidden; until  
the htc loads/runs, avoiding the ghostly gray-background issues. The  
trick is that you must only do this if JS is running, otherwise you  
might wind up with a site with no images. (The hack is testing right  
now -- NRFPT.)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] disabling autocomplete and validation

2005-11-07 Thread Ben Curtis


I’m trying to implement a similar thing to Google suggest but have  
found that the browser’s default autocomplete gets in the way.


The only way I’ve found to override this is to use the non-standard  
autocomplete=”off” attribute of the input element.


I suspect that if you give the form element a random name (its id  
could be consistent, for your javascript), then the browser won't  
ever match anything in its memory and so won't try to autocomplete.  
Then you just make your server app figure out what name to look for,  
perhaps with a hidden form field value.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] IE team says no to hacks

2005-10-13 Thread Ben Curtis


On Oct 13, 2005, at 12:55 AM, Geoff Pack wrote:
If the IE team fix the CSS hacks and also fix the bugs the hacks  
are used to work around (as I think they originally mentioned they  
would), then the hack users will be fine.


And if not, then it's no worse than having to update your  
conditional statements anyway. Because I bet you don't yet know  
which of your conditionals will have to change to !--[if lt IE 7]  
and which to !--[if IE]


This is only true in certain circumstances when the hack does not  
make use of a deliberate feature that is not changed. For example,  
this scenario is common:


- IE 5.x has a natural box model problem
- put IE 6 into quirks mode so it emulates this problem
- use * html to fix the problem in both IE5.x and IE 6

Now, we know that IE 7 will support quirks mode and will not support  
* html. New problem. In fact, a problem made more difficult by  
deliberately putting IE 6 into quirks mode, perhaps with a comment  
before the DOCTYPE, because this is a deliberate feature in IE. How  
many of these developers put that comment in a server-side include  
function, so they can remove it easily? My guess is none, even the  
ones that put all of their CSS calls in some sort of include. A  
better, more forward-thinking approach would be:


- IE 5.x has a natural box model problem
- IE 6 and IE 7 in standards mode do not have this problem
- use conditional comments with [if lt IE 6] to fix the problem  
in IE5.x
- use conditional comments with [if lt IE 7] to fix other IE 6  
problems
- use conditional comments with [if lt IE 8] to fix other IE 7  
problems


Then you place whatever is needed into whichever stylesheet is  
appropriate.


As a general rule, Only hack the dead. The only safe bug to exploit  
is one that is fixed in ongoing generations of the product, or will  
never be fixed because the product is dead. All other necessary  
targeting should use features, not bugs. (Some may ask what the  
difference is. The answer: features are supported.)




On Oct 13, 2005, at 7:27 AM, Francesco Sanfilippo wrote:

That's not really true, Alan.  A site without CSS hacks does not
necessarily have to be ugly.  I develop table-less ASP.NET sites using
CSS and I have never used a single CSS hack or conditional comment,
yet my sites are still clean, good-looking and functional in the
leading browsers (IE, FF, Safari, and Opera).


However, if you read about the Slashdot upgrade problem in the blog  
post, you'll see a point that is tough to navigate around without  
targeting browsers:


1. HTML validator requires a legend tag inside a fieldset  
(although I can't find that requirement in the spec)
2. HTML spec does not declare whether an empty element should  
render or not (according to the blog post -- not sure about this)

3. IE and Gecko choose to render empty elements differently.

It would seem to me then that without targeting browsers you cannot  
achieve the goal layout in both of these browsers unless you drop all  
fieldsets, forms, etc.


The spec is not complete. If you bump into one of these un-specified  
areas, then it seems your layout is subject to the will of the  
browser makers. Sometimes this is ok. Sometimes this means the client  
goes shopping for a new developer.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] But why didn't Eric use positioning

2005-10-05 Thread Ben Curtis


On Oct 5, 2005, at 3:06 AM, Donna Maurer wrote:


The challenge was:
* three columns of content
* no guarantee which would be longer
* vertical lines between them
* a footer that spanned the full width of the screen

As part of the decision, he was discussing whether he would use  
absolute positioning
or floats for the columns. I remember him saying that he couldn't  
use absolute

positioning because he wouldn't know which column was longest.

...
I understand this is hard because you don't know which column to  
use as a reference for the footer positioning. But couldn't you  
wrap the three columns in an relatively positioned div and position  
the footer relative the the whole thing?



The problem is that absolutely positioned elements are removed from  
the flow. They take up no space as far as the rest of the page is  
concerned, and so that relatively positioned wrapper div you invoke  
would only be as tall as the tallest non-absolutely-positioned  
element it contains. Then your footer would be positioned at the  
bottom of that, with the absolutely positioned elements flowing over  
(or under) it.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Hacks / Work Arounds for IE Mac and Old er IE Pc versions

2005-10-03 Thread Ben Curtis


I would be interested to hear suggestions on methods for improving  
display across platformss / browsers

- IE Mac - OS9
- IE Mac - OSX
- other OS X broswers (I think everything works fine)


Mac IE is the only Mac browser you need to hack if you are concerned  
about audiences greater than 0.5% of the market. (It's just now  
falling below 1% on some of my sites.) If you are concerned about  
less than that, consider Netscape 4 hacks on OS 9 (about 0.2% on some  
sites), but IMO it's better to deliver them a style-less site. Modern  
Safari is hack-free, but older versions for OS 10.1 and 10.2 (about  
20% of the Mac market) need help with min-height. For that, you might  
consider this:

http://www.mezzoblue.com/archives/2004/09/16/minheight_fi/


I was thinking of using an overriding style sheet for IE Mac using  
the following hack


/* IE5/Mac Only Styles Uses the IE5/Mac Band Pass Filter: http:// 
stopdesign.com/examples/ie5mac-bpf/  
--- */ /*\*//*/ @import  
url(ie5mac.css); /**/ what are the groups thoughts on this hack?  
does it work? is there a better way?


It works. There is no better way, and it keeps your main sheet clean.  
It's a good thing because it's valid, and the browser is dead so it  
won't change its interpretation of it, and it's a parsing bug that is  
unlikely to crop up in other, newer browsers.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] When bugs become patterns - A look at CSS Hacks

2005-09-29 Thread Ben Curtis


Irina wrote:
I've found this to be an interesting idea and wondering what other  
members think about it:


When bugs become patterns - A look at CSS Hacks:
http://spaces.msn.com/members/siteexperts/Blog/cns! 
1pNcL8JwTfkkjv4gg6LkVCpw!1805.entry



The idea is not new, the logic has a lot of merit (IMO), but is not  
commonly used, and I wouldn't recommend it. Actually this fellow  
doesn't do it justice: class is not a valid attribute of the html  
tag, for one, and by assigning classes based entirely on the user  
agent he's encouraging practices that have been debunked for some  
time, especially in Javascript circles. Browser sniffing is just a  
backwards-thinking method, compared to capability testing, which some  
hacks attempt to do.


His technique might be better dealt with if he assigned classes like  
this:


body class=boxWidth minHeight floatJog

...and so forth. Of course, to do this with either server or client- 
side scripting still means browser sniffing, so you remain in an  
awkward situation.




On Sep 29, 2005, at 10:14 AM, Drake, Ted C. wrote:
I think the future of CSS is not in hacks but looking seriously  
into using the conditional comments. I’m saying this as someone  
that is trying to figure out the best approach for retrofitting  
older conversions.
Agreed. The major stylesheet should be standard-compliant only and  
hack free. Then use a conditional comment to fix up the outliers.


Conditional comments are IE statements that say if ie6 use this  
additional CSS file, if IE5Mac, use this style sheet, if neither:  
ignore this statement.
IE 5 Mac does not respond to conditional comments. However, since it  
is dead, its response to the Mac IE comment filters will not change  
and such hacks are safe.


I’m dreading the idea of inserting conditional comments into the  
head sections of html pages. I’d like to insert it into the  
main.css file that imports more sophisticated styles.  I have been  
overwhelmed lately and haven’t been able to test any answers to  
this. Does anyone have a suggestion?


If you don't mind proprietary styles in your CSS, I was working on a  
conditional comment-like import statement that goes in the  
stylesheet. It worked, but Win XP SP2 allows scripting to be  
deactivated in the CSS as well as the regular page script, which  
would deactivate this technique. So I abandoned it. If anyone is  
interested, I suppose it still has a place in project where scripting  
is a requirement. Let me know if you use it.


http://www.bivia.com/sandbox/css_cc_4ie/conditional_comment_test.html

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] When bugs become patterns - A look at CSS Hacks

2005-09-29 Thread Ben Curtis


On Sep 29, 2005, at 11:52 AM, Anders Nawroth wrote:

Conditional comments are IE statements that say if ie6 use this  
additional CSS file, if IE5Mac, use this style sheet, if neither:  
ignore this statement.



Conditional comments are Windows-only, unfortunately.



Conditional comments are valid comments. I think hacks are more  
treacherous than structuring your comments to activate an IE-only  
property in a way that is deliberate on the part of the browser  
developer (and therefore supported, and therefore future-secure if  
not future-proof). But it does mean that a) you need to code first  
for standards, and send IE a corrective stylesheet, and b) you need  
to markup the content to support it.


The only unavoidable downside I see is that it encourages bad browser  
sniffing behavior. I think the multitude of hacks out there encourage  
worse behavior.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] consistent fontresizing - the right way

2005-09-23 Thread Ben Curtis


On Sep 23, 2005, at 4:17 AM, Gunlaug Sørtun wrote:


html { font-size: 100%; /* IE hack */ }
body { font-size: 0.75em; }
...does always result in consistent resizing. However, it does not
prevent unnecessary breaking of some designs, *if* elements further in
are sized _up_.

The reason is simple-- and logical:
Browser-option; 'minimum font size', will act on any defined font-size
that is smaller than users set as acceptable.



Georg,

I haven't seen this documented anywhere. Do you have links? These  
preferences effectively set a floor below which no value may be  
inherited, radically changing the intent of the preference setting.


I went ahead and created a test page. It seems that this is a  
significant problem in all browsers I tested except IE (because it  
doesn't support the user preference) and Safari (because it applies  
the filter on the final calculated value).


http://www.bivia.com/sandbox/demo/minimum-font-size-inheritance.html

This is very disheartening. It means that if you want to take into  
account people setting minimum font sizes, you need to radically  
change how you set up your fonts. For example, instead of this  
typical setup:


div.content { font-size:0.875em; }
div.content h2 { font-size:2em; }

...you will need to use this:

body { font-size:1.75em; }
div.content h2 { font-size:1em; }
div.content p { font-size:0.5em; }

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] ol displaying 3.1 3.2 etc. instead of 1 2 3

2005-09-22 Thread Ben Curtis


Webmaster wrote:


The far simpler way would be simpy to use:
 ol start=3 type=1
 li class=MsoNormalText/li
 li class=MsoNormalText/li
 li class=MsoNormalText/li
/ol



This would render as:

3. Text
4. Text
5. Text

The poster wants:

3.1. Text
3.2. Text
3.3. Text

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] images in html or css

2005-09-16 Thread Ben Curtis


On Sep 16, 2005, at 1:43 PM, kvnmcwebn wrote:


browsers do not cache the images
linked from the stylesheet so caching is a little more work

wow, thats news to me.



I believe that's actually browser, singular. Who else, but IE?

IE's problem will crop up (I believe -- someone who uses Windows,  
please correct me) when anything changes a layout property of the box  
the background is applied to, such as javascript or css rollovers.  
Then, the browser will check the server to see if the file has  
changed (I'm not sure it actually automatically downloads).


Actually, although I think the statement is wrong, I don't know  
enough of the right stuff to argue. Anyone? Anyone? Beuller?


More, from The Great Google: http://tinyurl.com/cr44n

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] images in html or css

2005-09-15 Thread Ben Curtis



Is the img tag still widly used among list members. Should
we put as many of the images we can in the css as backgrounds etc.

Right now i put most sitewide images in the css and the page by  
page content

in with the img tag.



Content goes in the html.
Presentation guides for content go in the css.

One way to tell if an image is content is to ask yourself these two  
questions:


- With images off, would the user miss it? (yes = it's content)
- Will this change if we redesign? (yes = presentation)

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] wishing not for picky browsers (was) Barclays standards redesign

2005-09-14 Thread Ben Curtis


On Sep 14, 2005, at 12:40 AM, heretic wrote:


At 03:44 PM 9/7/2005, Christian Montoya wrote:


I was actually thinking the other day, browsers should be more like
compilers... they should refuse to parse incorrect code. Then the
enforcement would be on the output end, too.


Why on earth would I want to use a browser that refused to show me
pages that didn't validate?  I'd be blocked from seeing 98% of what's
on the internet.

...

Realistically the horse long since bolted on the concept. But imagine
two scenarios:

1) Code compilers were as forgiving as browsers

In this scenario, it wouldn't matter how broken, inefficient or
vulnerable (security holes) the program was; the compiler would
cheerfully let it through and it could end up on your computer.

Now think about how often you have to patch the average windows
machine to plug up the latest hole. Imagine how much worse it would be
if there was even less standards enforcement! :)


Meaning, that I could teach my mom to program effectively in an  
afternoon? That artists and journalists would get basic programming  
skills covered in the first two weeks of class? That about one out of  
three people interested in software would actually be able to program  
it -- unlike the one out of maybe twenty now?


How horrible. :)



2) Browsers were as unforgiving as compilers

If this had always been the case, everything you could view on the web
would be standards-compliant.


When I first started learning HTML, I viewed-source on the Yahoo  
page. The only Page. They hadn't bought a domain yet. They had a  
message at the bottom of the page, after having listed a couple  
hundred categorized links, If you know of another URL not on this  
list, please let us know. If browsers were as restrictive as  
compilers, *none* of those sites would even exist, because they were  
all done in the free time of professors, students, internet  
aficionados, and hackers with better things to do. But HTML was so  
easy and forgiving, everyone was trying their hand at it. Three years  
after explaining what a URL was, they were on billboards and ads  
everywhere. That's faster adoption than the DVD had at about the same  
time.


Making browsers forgiving is part of the core ideology of the Web. I  
wouldn't discard it so casually.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] OL vs DL

2005-09-08 Thread Ben Curtis


On Sep 7, 2005, at 2:19 PM, Kenny Graham wrote:


 I wouldn't lose any sleep over which is
 the most semantic way, as it can get fairly academic...

But that's why I love this list. Even the smallest things get  
academic very quickly here. To get to the semantic root of it, ask  
yourself Does each subitem function as a definition of its parent?



This is a good way to figure out what list (or table) to use. Ask  
yourself, how do the data relate to each other?


* the data in the group all relate to each other equally = unordered  
list (e.g., all items on a shopping list are on par with each other)


* the data mean something different if you change what proceeds or  
succeeds them = ordered list (e.g., every item in a list of  
directions must follow a specific other item, and lead a specific  
other item) -- note that the order should change the meaning, and not  
simply be a preference such as an unordered list that is sorted in  
some manner. Menu items and alphabetized shopping lists do not change  
their meaning if you re-order them.


* the data are sectioned, and each section is an unordered list with  
each item relating (equally) to a title for the section = definition  
list (with section titles being the defined terms), even if there  
is only one section so long as that section is titled.


* the data relate as an unordered list, but in two mutually  
independent ways = table (if you find yourself considering the  
coordination of two different unordered lists so that each requires  
no order but both must be in the same order, e.g., an unordered list  
of cities, each with a sub-list of population, latitude, and  
longitude, then this is a two-dimensional relationship that is best  
shown with rows and columns)


Note that this is why calendars give people headaches:
- they have columns that are an ordered (not un-ordered) list that  
acts as a cycle, but no rows (move Sunday from the last column to the  
first, and all Sunday dates change rows but not meaning)
- they have sections like dl's (months), but the content of each  
section is ordered (days)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] divitis - a worthy goal?

2005-09-08 Thread Ben Curtis


On Sep 7, 2005, at 11:33 AM, Patrick H. Lauke wrote:


Drake, Ted C. wrote:

Now, the goal of a medium to advanced CSS-based programmer is to  
find the
elegant balance of essential divs, spans, ids and classes.  
Consider it a

challenge.



Indeedy. I cringe, however, when I see DIVs where they're not  
necessary.

...
if you already have a perfectly good block level element, don't  
wrap it in a generic div unless you have a very good reason for it.



I, too, consider it a challenge (one that I cheerfully pursue without  
reason or any outside encouragement, BTW) to strip out all  
unnecessary markup, and style the most basic element possible. I  
regard it as a fun and ever-changing puzzle. So that's my stance, but  
I'd like to float a counter-argument to see if it holds up:


Eschewing markup that is not needed today is equivalent to
adding presentational decisions to the markup for tomorrow.

Does the argument hold water? Is the logical conclusion of truly  
semantic markup that all meaning of a document should be embedded in  
tags, including semantically empty tags that serve only to group and  
divide content, whether those elements are required for the current  
design or not, such that they may provide hooks for future  
presentation considerations? Ted had mentioned the example of  
navigation that is fully expressed as a list today may instead  
contain a list and other elements tomorrow (or conversely, on some  
pages it is only a list, on others it is a list plus headings, but on  
all pages it is the same navigation, etc.). In addition to divs and  
spans, this would also require giving all elements an id and most  
would have multiple classes. (Surely this would add excessive bulk  
and require excessive planning; let's ignore the practicality of  
download and work-weeks for a moment as we chase an ideal.)


Is there a point where stripping things out, simply because your  
current visual design is still possible without the excess, means  
that you are stripping away presentational abilities and embedding  
that presentational decision in the markup instead of the CSS? In  
essence, could divitis/classitis be not only the scourge of the  
beginning standards-coder, but also an enlightened ideal we may be  
avoiding due to current download concerns?



I think this discussion is highly theoretical, but can lead directly  
to a rationally-derived process for marking up documents such that we  
truly separate content from presentation. Although I mention an  
idealized goal, I recognize that reality is likely to intrude. I also  
recognize that there may be critical holes; that's why I'd like to  
hear other opinions.


I'm also unlikely to give up my habit of trying to slim things down  
to the final ounce possible. It's too fun. :)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] divitis - a worthy goal?

2005-09-08 Thread Ben Curtis


On Sep 8, 2005, at 2:20 PM, Rimantas Liubertas wrote:


 Eschewing markup that is not needed today is equivalent to
 adding presentational decisions to the markup for tomorrow.


Only if tomorrow we won't have browsers with advanced CSS support  
(talk

multiple backgrounds).



I think my point was missed. Treating tags as hooks on which to hang  
your design implies that if you want hooks for all possible designs  
(e.g., you are separating presentation from your markup), then you  
need to add a lot of hooks that are not needed for *this* design.


For example, CSS3 has a means to move content from one area to  
another -- not positioning, in layout terms, nor moved in the DOM  
tree, but moved in the document flow. For example you can duplicate  
all the headings in your document (h1:before { content:contents; }),  
and place the duplicates up front in a table of contents that the  
rest of the document recognizes as being in the flow. Or footnotes  
can be inline, right next to the content they refer to, but then  
placed last in the document, one after the other, with self-numbering  
precursors like an ordered list.


But how can you use this future technique of CSS to present your  
existing document differently if you didn't put in some empty (and  
currently worthless) hooks in the first place? Therefore, by *not*  
putting those hooks in, are you essentially making presentation  
decisions?



Even though I'd like to see if someone picks this idea up and can  
help argue the for/against, because I think it's a worthwhile  
discussion, I don't think that reality will play nicely with the  
idealized end result of this line of thinking. I think it's far more  
likely that people will continue to adopt XML-compatible XHTML-like  
documents, which then they can convert in the future via XSLT to have  
the markup-based hooks needed for future presentational concerns. In  
essence, I think I believe that separating presentation from markup  
is ultimately unachievable in the purest sense of totality, but the  
consequence of striving to achieve it is a Good Thing(tm).


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Images as accessible form buttons

2005-09-06 Thread Ben Curtis


On Sep 5, 2005, at 11:54 PM, Andreas Boehmer [Addictive Media] wrote:

I then thought I should use input type=image, but realised that  
this
doesn't work in all browsers. IE, for example, has got the nasty  
habbit of
submitting name.x=0name.y=0 when these kind of buttons are  
clicked, which
can make it really difficult if you have got multiple buttons in  
one form

and you wish to detect which of them was clicked.


The .x and .y values are according to spec; any browser that doesn't  
do this is broken. I suspect this is your best bet. Is the reason  
it's difficult to use multiple submits because you are not receiving  
a name=value in addition to the name.x=xxname.y=yy values? If so,  
then that browser is broken as well.


...an input type=image creates a submit button...
http://www.w3.org/TR/html401/interact/forms.html

...a submit button is successful if clicked...
http://www.w3.org/TR/html401/interact/forms.html#submit-button

...successful form elements have their values submitted paired to  
their names...
http://www.w3.org/TR/html401/interact/forms.html#successful- 
controls


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Microformats

2005-09-01 Thread Ben Curtis


On Aug 31, 2005, at 4:37 PM, Drake, Ted C. wrote:


The summary is at: http://www.tdrake.net, but it is about opening new
windows for pdf files.
For a summary of microformats, visit http://microformats.org/

...

From: Chris Kennon
Sent: Wednesday, August 31, 2005 4:25 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Microformats

Hi,

Where is this summary, Microformated?

...

On Aug 31, 2005, at 2:44 PM, Ben Curtis wrote:


Ted Drake just wrote up a summary of the previous opening a new
window conversation, so I'd like to grab a sample from what he was
doing -- after all, microformats *must* satisfy a real, current
need in order to be useful.




My apologies. My point was to take a current, existing, common  
problem and present a new microformat type response to show how the  
concept could be applied to any problem. Since a conversation had  
just focused on a problem many people had, I adopted that problem to  
tackle.


Note: Microformats are not solutions to problems, but rather they are  
agreed-upon syntactical standards which would in turn allow for many  
third-party solutions to be interoperable.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Microformats

2005-08-31 Thread Ben Curtis


On Aug 31, 2005, at 9:47 AM, Chris Kennon wrote:

Having just completed the article on Microformats from Mr.  
Weakley's weekly read list (say ten times, very fast),I'm excited  
by Microformats contribution to standards based development. It  
seems to give syntax and grammar  to the mark-up of personal data.  
Would this be a brief, but succinct definition of the microformat  
contribution?


Meaning, is this true:

dl
dtmicroformats/dt
ddsyntax and grammar for the mark-up of personal data./dd
/dl

I would say no. Microformats are standards-based, shared techniques  
to add complex semantic meaning to any type of content. It doesn't  
have to be personal data, and it is more than syntax and grammar --  
it adds meaning. For an example, Ted Drake just wrote up a summary of  
the previous opening a new window conversation, so I'd like to grab  
a sample from what he was doing -- after all, microformats *must*  
satisfy a real, current need in order to be useful.


Say you wanted an agreed-upon microformat for links to non-hypertext  
files, so that the format defined the file type, file size, and  
dimensions. (Perhaps other metadata in the future.) Once you've  
defined the format, then all sorts of things could be written to  
parse and understand that format, including Thierry's unobtrusive JS  
scanner/tweaker. The a tag is mostly there with the under-used type  
attribute, so we don't need to add much. So, off the top of my head,  
how about this (wrapped for email):


a href=../path/to/filname.foo
  type=application/foo
  rel=cul-de-sac
some file
var class=unitKb12/var
var class=fileWidth unitPx1234/var
var class=fileHeight unitPx567/var
/a

There. You have just witnessed the birth of the RelCulDeSac  
microformat, named because you can link in to a non-parsed file, but  
the only way out is back the way you came.


Now you can use CSS3 selectors or javascript to add appropriate file- 
type icons; or hide or show the size of the download and the  
dimensions, or either, or neither; interpret the file size (e.g.,  
adding up all of the sizes in a list); open a new window in the  
correct dimensions (or not, or allow the user to choose and the  
choice adds/removes a class to the body tag which then shows or hides  
the little opens-a-window icon for links with a type that is not text/ 
html); convert the links to properly-sized thumbnail gallery of  
object tags, with a progress bar based on the total file size sum; or  
any number of other things.


(Note: this idea violates a microformat concept of visible data  
instead of invisible metadata, because the units are in the class  
name -- but I couldn't figure out another markup that would allow you  
to turn it off with CSS, so I tip the balance in favor of of utility.  
Maybe someone else can make it work.)


The greatness of microformats is that this functionality could be  
written by third parties and used by you, because you all agreed on  
the format.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Randomly load images into the background-image selector...

2005-08-26 Thread Ben Curtis


Andrew did all the hard lifting, so I hope my comments don't come  
across as criticism but polish on top of good work. All code that  
works and is freely given is Good Code(tm). But I hope to share some  
stuff I've learned that may be helpful to Andrew and others, and  
doing it on list means I just might get the right info to the right  
person.


So, thanks to Andrew for the code. Here are some tweaks:

On Aug 24, 2005, at 6:21 PM, Andrew Krespanis wrote:



function randomBG(targetObjID) {
var obj, imgs, randNum;
obj = document.getElementById(targetObjID);
imgs = new Array();
imgs.push( 'foo.jpg');
imgs.push( 'bar.jpg');
imgs.push( 'w007.png');



The Mac IE Array object does not support the push, pop, shift or  
unshift methods. They are easy to simulate, so if you need to support  
that browser you can either attach custom methods to the prototype or  
run the custom code for everyone:


imgs[imgs.length] = 'foo.jpg'; // push




randNum = Math.random() * (imgs.length - 1);
randNum = Math.round(randNum);



Even though in English we often talk about rounding numbers, you  
don't want Math.round() here as this will give you lopsided results.  
randNum is between 0 and 2, but only values less than 0.5 will give  
you 0, more than 1.5 will give you 2, but between 0.5 and 1.5 will  
give you 1 (twice the rate of the other two). What you usually want  
is more like:


randNum = Math.random() * imgs.length; // 0 = randNum  3
randNum = Math.floor(randNum); // 0-0.9...= 0, 1-1.9...= 1,  
2-2.9...= 2,





obj.style.backgroundImage = imgs[randNum];



Although this is likely to work in many browsers, the standard way to  
assign values to style properties is to use the same format as if it  
were a stylesheet. That means:


obj.style.backgroundImage = url(+ imgs[randNum] +);




}
window.onload = function() { randomBG('swapMe'); };



You see this a lot, but for those who are learning: know this is a  
shorthand. Using this particular technique means you can only have  
one onload handler per page, as they will override each other. Better  
methods exist that allow you to have many such self-contained  
functions, but are tough to write concisely, so in code examples you  
almost never see them. Here are some places to look:


http://www.onlinetools.org/articles/unobtrusivejavascript/chapter4.html
http://www.scottandrew.com/weblog/articles/cbs-events

And for the Mac IE-compatible technique (that prevents you from  
removing the even later):

http://simon.incutio.com/archive/2004/05/26/addLoadEvent




I'm 90% sure I've got a script at home that does the above, but fades
between the remaining  images after choosing the initial one at
random I say 90% sure because I remember needing that
functionality for a client site but I may have ended up using an img
element due to problems with Opera  7.5 and Safari  1.1



I'm pretty sure you did it with images, not backgrounds, since  
backgrounds can't have their opacity changed separately from the  
foreground (until CSS3, but that's only with colors in rgba format, I  
think).


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613





**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] another 'open new window' dilemma

2005-08-25 Thread Ben Curtis


On Aug 25, 2005, at 11:24 AM, Drake, Ted C. wrote:

Regardless of your window philosophy, I think using target=top is  
asking
for trouble. That is a common target for pages with frames. I would  
at least
suggest using a target name that is not part of the frame  
architecture. That

is why most people used target=_blank.


target=_blank will always open a new unnamed window.
target=_top will open a link in the outermost frame, replacing all  
framesets with the document linked to.
target=_parent will replace the frameset that defines the frame  
that has the clicked link, replacing it with the document being  
linked to.


target=top will open a window named top; if the current window is  
already named top (e.g., it had been opened with such a link), then  
a new window will not open but instead the document linked to will  
replace the document with the link in that same window.


The problem with target=top is not that it uses a confusing name,  
but that all links on the site will open into the same window. This  
means that the typical experience is that the first link opens a new  
window, and subsequent links open into the same window and if it is  
minimized or hidden, clicking the link will appear to have done  
nothing at all.


So, regardless of your window-opening philosophy, the standards allow  
for two methods that are consistantly applied:


1- link replaces current document (no target or js new window)
2- link always opens new window (target=_blank or js equivalent  
with unnamed window, e.g., window.open(this.href,'',winOptions);)


Anything else, and the behavior depends on the context the link is  
in, possibly meaning that your icons or title text are giving wrong  
information.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] another 'open new window' dilemma

2005-08-25 Thread Ben Curtis


On Aug 25, 2005, at 12:33 PM, Thierry Koblentz wrote:


Ben Curtis wrote:


1- link replaces current document (no target or js new window)
2- link always opens new window (target=_blank or js equivalent
with unnamed window, e.g., window.open(this.href,'',winOptions);)



I agree, the opener getting focus each time the user clicks on a  
link create

problems with named windows (using target or JS).
But I think one can use the following to make sure named windows  
pop up on

top of the opener.

newWin=window.open(this.href,'zWin');if(window.focus){newWin.focus()}



True, and that does cure the most disabling aspect of named windows.  
However, it is still context sensitive in that if you click a link so- 
coded which is in a document already in a window named zWin, then it  
will open the new document in the same window instead of the other one.


One could, I suppose, code around that, too (wrapping for legibility  
only):


a href=foo.html
onclick=
if (self.name == 'zWin') self.name = '';
var newWin = window.open(this.href, 'zWin');
if (window.focus) newWin.focus();
return ! newWin;
Open Foo/a

But you still haven't coded around the contextuality, since now you  
have opened a new window, but which window has what name? If other  
links point to zWin, which window is that? Your arrangement of  
windows, and what the targets actually point to, is dependent on  
previous user actions, which are unpredictable. So, to be  
predictable, links either need to target self (no target, no new  
win), or always open a new window.


The merits of always knowing your context are as debatable as whether  
one should be opening windows in the first place, anyway.



(Of course, if you were to try this sort of thing, you'd be applying  
it unobtrusively and not inline like the example...)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] body onload=blah not working in Mac IE 5.2, any suggestions?

2005-08-24 Thread Ben Curtis


On Aug 24, 2005, at 1:31 AM, Bennie, Jack wrote:

Got a problem, which only occurs in IE Mac 5.2, with using the  
onload function in an HTML BODY tag, any suggestions how I might  
be able to get around it?


I suspect your Mac IE is firing the onload just fine, but the value  
you give to it is confusing it. Test to make sure the onload is  
firing by adding an alert('fired'); to the function before any other  
code.


I suspect your problem is that Mac IE does not want the quotes around  
the url value. You have:


document.getElementById(masthead).style.backgroundImage = url 
(' + bgimage + ');


...which expands to (say):

document.getElementById(masthead).style.backgroundImage = url 
('images/header1.jpg');


...but those single quotes are fouling things up. Try this instead:

document.getElementById(masthead).style.backgroundImage = url 
( + bgimage + );


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Can this function be duplicated using CSS

2005-08-24 Thread Ben Curtis


On Aug 24, 2005, at 9:44 AM, Jeff wrote:


http://www.electrabike.com/04/bikes/05bikes/cls/05_cls_01.html

The scrolling section...can this feature/function be duplicated  
using nothing but CSS?  The entire scroll effect, the links and  
targets, etc.


If it could, it wouldn't be a good thing to choose to do.

* If you want it to say something, use HTML.
* If you want it to look some way, use CSS.
* If you want it to act different, use JavaScript.

A more pure approach would be to say, If you want it to do  
something, use JavaScript, but HTML allows for links and form  
submission, and CSS allows for :hover. But the key here is that  
behavior should be scripted; even if you could do it in CSS, that's  
not the proper place for it and will cause many headaches down the  
line -- the same headaches caused by people putting presentational  
markup in their HTML.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Semantic Calendar

2005-08-18 Thread Ben Curtis


On Aug 17, 2005, at 8:31 PM, T. R. Valentine wrote:


On 17/08/05, Scott Swabey (Lafinboy Productions)
[EMAIL PROTECTED] wrote:


Does a calendar (single month) qualify as tabular data,
are ordered lists a better fit, or should I be looking at
another option?



IMO, a calendar is always tabular data.



I agree that in general, calendars on web pages should be marked up  
as tables. This affords some backwards compatibility with the CSS- 
challenged. So I in no way want to argue against Valentine's  
position, but I do want to discuss a point about it.



Tabular data means data that both the row and column add meaning  
and context to the displayed data. A calendar is not row-sensitive;  
columns are only columns because that is a convenient shorthand for  
repeated meta data (days of the week). As I understand it, Mayan  
calendars (for examples) represented the same thing as circular  
(cyclical?) data, and not tabular.


Case in point: depending on national preference, the calendar weeks  
may start with Sunday, or end with Sunday. But Sunday, Aug 14, 2005,  
would move to a different week (a different row, and therefore a  
different meaning) if you switched from Sunday-first to Sunday-last.  
In tabular data, you cannot arbitrarily switch rows and not change  
the meaning, but in a typical calendar Aug 14 would remain the same  
regardless of the column order.


The data structure of a calendar is an ordered list, with repeated  
meta data (days of week), and sectional groups (months and years).  
There is no truly appropriate HTML markup for this, since you cannot  
segment an ol.


A current project of mine allows people to select a week by clicking  
on any day within it. In this case, changing from Sunday-first to  
Sunday-last *would* change the week the Sunday is related to, and so  
tabular data it has become.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] html design - best practices

2005-08-18 Thread Ben Curtis



Without trying to drag this on Ben...


Indeed. I suspect this discussion is one of those that a lot of  
people would be in agreement if they were in the same room, but in  
email it seems like there may be more disagreement than intended.  
Tends to produce many emails, especially from folks like me who find  
themselves arguing a point they aren't fully behind...




If backward compatibility is the only argument
then it only goes slightly further back than SPAN

...
Non-backwards compatibility of the B tag is screen rendered bold  
text which
may not be the purpose of the class hook, now, or in the future.  
SPAN is

neutral which is what we want.


The original poster was trying to highlight certain text. He  
suggested the b tag but worried that it was deprecated. My response  
was that it is not deprecated, would provide the highlight he wanted  
in non-CSS browsers, and as valid XHTML1.1 it would also be as  
forward-compatible as any other option (because my contention is that  
for any XHTML 1.0 or 1.1 document to become XHTML 2.0, it must be  
translated, perhaps with XSLT). I was not advocating the b tag over  
the span tag, but merely pointing that it is a valid option. Whether  
it is the correct option is debatable.


So the compatibility thing is not that span was introduced later, but  
that b would produce the desired effect when a browser is incapable  
of rendering the CSS. This is not necessarily about non-CSS browsers  
(e.g., Netscape 3, Lynx), because a popular technique for handling  
browsers with poor market share is to deliver no CSS to them. People  
are discussing whether this should be done with IE5 (Win and Mac),  
which certainly could render a span as bold but might not be given  
the chance.




Time for a cold one I think... ;)


A brilliant idea. Always up for a cool pint. Lemme finish breakfast  
first. :)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] html design - best practices

2005-08-17 Thread Ben Curtis


On Aug 17, 2005, at 4:39 AM, Julie Romanowski wrote:


On Aug 16, 2005, at 9:07 PM, Ben Curtis wrote:
That's a very curious thing for the W3C to publish. I am not  
aware of any HTML standard in which b and i are deprecated. Can  
anyone cite such a declaration?

...
Please look at the date of each document. The document listing the  
items

as deprecated is the most recent.

HTML 4.01 Specification http://www.w3.org/TR/html401/ 
cover.html#minitoc

W3C Recommendation 24 December 1999

XHTML(tm) 1.0 The Extensible HyperText Markup Language (Second  
Edition)

A Reformulation of HTML 4 in XML 1.0 http://www.w3.org/TR/xhtml1/#defs
W3C Recommendation 26 January 2000, revised 1 August 2002

Modularization of XHTML(tm)
W3C Recommendation 10 April 2001
http://www.w3.org/TR/xhtml-modularization/

XHTML(tm) 1.1 - Module-based XHTML
http://www.w3.org/TR/xhtml11/Overview.html#toc
W3C Recommendation 31 May 2001

HTML Techniques for WCAG 2.0 http://www.w3.org/TR/WCAG20-HTML-TECHS/
W3C Working Draft 30 June 2005 (includes the information regarding
deprecated b and i tags)


Looking solely at the dates would lead people to believe that we  
should currently be coding to XHTML2 specs, since that was most  
recently updated, but that would be wrong. Dates are useful in  
finding what spec is the most recent, but a spec is only a standard  
once it reaches recommendation status. The HTML Techniques spec you  
cite is a Working Draft, and they state in the prologue:


Publication as a Working Draft does not imply endorsement
by the W3C Membership. This is a draft document and may be
updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite this document as other
than work in progress.

It's not a standard yet. It's important to recognize that standards  
that are developed publicly will present a number of documents from  
official sources that are not, in themselves, definitive. It's  
important to cite the documents that are definitive, and only in the  
manner that they claim to be definitive. For example, had the HTML  
Techniques been a Recommendation, it would still be inappropriate to  
cite this entry as a declaration of the deprecation of the b and i  
elements (http://www.w3.org/TR/WCAG20-HTML-TECHS/#em ). It's  
inappropriate because the document is not intended to define the  
state of elements, but only the techniques for using them.




If the W3C misspoke... Do you really believe that the W3C misspoke
because they have a working draft with change/updates to the current
HTML/XHTML recommendations?


Nothing can change or update a standard; only a new standard may be  
adopted. The portion you quoted stated that b and i as elements were  
deprecated in the HTML 4.01 and XHTML Recommendations. I have yet to  
find anything that would indicate that this is true. Thus, the W3C  
misspoke.


Now, that all said, I think that we're on pretty much the same side  
on this issue. Edward also points out:



On Aug 16, 2005, at 11:51 PM, Edward Clarke wrote:
You are correct, it hasn't been 'officially' deprecated but as  
visual tags

and not logical ones; CSS offers a better long term solution.


When there are only semantically inappropriate tags to use (e.g., the  
a tag as the original poster had implemented), then I opt for  
semantically empty tags, with a class applied, and the class is  
styled. Some opt for the semantically empty span tag; I opt for the  
semantically empty b tag. In both cases, they must be styled to suit:


b.bookTitle { font-weight:bold; }

If you treat the b or i tag (or any other valid markup) as  
semantically empty, then treat it in your CSS as having no default  
style. The only advantage is backwards compatibility with non-CSS  
browsers. As a long term solution, one must keep in mind that the  
declared doctype is just as much a part of the document as the other  
tags in it. Therefore, if I were to convert the doctype to, say,  
XHTML 2, then it would be just as easy to use XSLT to convert span  
class=bookTitle to something appropriate as to convert b  
class=bookTitle to the same thing. If your doctype states XHTML  
1.0 Strict, then that's the standard it needs to conform to.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Win IE hacks -- Please help!

2005-08-17 Thread Ben Curtis


On Aug 16, 2005, at 9:45 PM, Janelle Clemens wrote:

Thanks Ben.  Unfortunately it is not for tabular data but page  
layout.   But
let me clarify that.  The main template (topnav, sidenav, footer)  
is in a
tabless format and validated.  The content area will have a 2 row,  
3 column

layout.   Each cell will contain content, like highlights or list of
products, but not relate to eachother in a tabular fashion.   
However each
cell has a bottom border that need to match up so if one cell  
expands in
height I need the rest to expand at the same rate.   Only a table  
can give

this or display: table-cell.



I think your previous training with tables has taught you to look at  
things on a page, instead of things being properties of the content.  
For example:


- you see that the bottom borders of two cells in one row need to  
line up on the page


- I see that there are two equally important content areas which are  
themselves related; I need to illustrate these relationships by  
placing the content areas side by side, and making them visually take  
up the same space as each other.


Coding XHTML+CSS is much easier when you look at the semantics first.  
They share a bottom border. Why? What does this mean? It means they  
are a group.


style type=text/css
div.blockContent {
float:left;
width:100%;
border-bottom:2px solid #000;
}
div.blockContent div {
float:left;
width:50%;
}
/style

div id=primaryContent class=blockContent
divblah blah blah/div
divblah blah blah blah blah blah blah blah blah blah blah  
blah/div

/div!-- /primaryContent --
div id=secondaryContent class=blockContent
divblah blah blah blah blah blah blah blah blah blah blah  
blah/div

divblah blah blah/div
/div!-- /secondaryContent --

Notice: the borders matching up on the page indicate that the cells  
are related, and since the border is the relationship, the border  
property gets assigned to the element that relates them -- the parent  
div.


(The float:left; on the parent div is just so that it stretches to  
enclose all of the floating children. Since the width is 100%, it has  
no other effect.)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] html design - best practices

2005-08-17 Thread Ben Curtis


On Aug 17, 2005, at 10:02 AM, Edward Clarke wrote:


I see your point about backward compatibility but B and I aren't
technically, semantically empty. (If that makes sense).

span style=font-weight: normal;Harry Potter/span

makes sense...

b style=font-weight: normal;Harry Potter/b

does not.


Both of your examples make the same amount of sense, semantically.  
Bold text does not mean anything different than non-bold text, and  
therefore boldness has no semantic meaning. Consider the semantics of  
these (fictional) tags:


compassNorth/compass
surnameNorth/surname
dictionary-entryNorth/dictionary-entry

Those are three different meanings that North can have. In your  
example, the span'd Harry Potter is the same as the b'd Harry Potter,  
and that would be true regardless of what content you wanted to span  
or b. That's why I say b is semantically empty.


What you are saying though, is that it doesn't make sense to declare  
that the b tag not render as bold. To which I reply, in a CSS  
browser, none of the presentation properties should be derived from  
the tag, and all should be derived from the CSS. Why single out a  
specific, meaningless tag? All presentation must be in the CSS,  
regardless of the tag.



B and I being visual tags should be removed from the markup and  
styled via

SPAN or inherited from its parent element, the styled using CSS.


img is also a visual tag. This is likely the reason that img was  
going to be removed (like b and i) in XHTML2, until a developer  
outcry insisted it remain for backwards compatibility (nonsense, I  
say -- if you're moving to XHTML2, the img tag is the easiest thing  
to transform). I wholeheartedly agree with removing presentation from  
the markup. This is why in my original post I stated that using b  
gains you backwards compatibility, but you *must* style it  
appropriately, as if it were a span; otherwise, you fail to separate.


Allow me to reiterate:
- b and i are not deprecated (i.e., valid but marked for future  
removal)

- they are semantically empty, and must be thoroughly styled
- they achieve a semblance of backwards compatibility

Some point out that b and i are deprecated because they are not in  
XHTML2. This argument is soft at best; for example, the very document  
pointing out that b and i are deprecated requires a use of the label  
element that is incompatible with XHTML2.


http://www.w3.org/TR/WCAG20-HTML-TECHS/#label
http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod- 
list.html#edef_list_label


Those trying to code their XHTML1.0 Strict to be forward-compatible  
with XHTML2 have their work cut out for them.




It's a
fundamental aspect of removing presentation from content; something I
believe should fail (but doesn't) the validator on any STRICT DTD  
check.


Don't confuse valid with preferred technique. The Strict DTD is a  
different DTD than the Transitional or Frameset DTDs, and it is not  
better or worse, nor are the other DTDs less strict (as in rigidly  
applied), they just include more options. What you are proposing is  
that the Strict DTD should not include b and i; it's a valid  
argument, but it does not reflect the approved Recommendation of the  
W3C.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Q: cross browser submit button image replacement

2005-08-16 Thread Ben Curtis


On Aug 15, 2005, at 4:15 AM, Rex Chung wrote:


Anyone know what is the best practise for image replacement with
rollover states for submit buttons.

I tried adding onmouseover class change javascript with:
1. background image for input type=submit /
but - doesnt work for safari, value attribute shows up

2. text-indent=-1000em for button type=submit submit/button
but onmouseover doesnt seem to work for IE.



Is there a reason you can't use an input type=image, and then swap  
the src value on rollover? For purposes of having readable text, make  
sure to add an alt attribute.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] html design - best practices

2005-08-16 Thread Ben Curtis


On Aug 16, 2005, at 10:46 AM, [EMAIL PROTECTED] wrote:


Sam Brown wrote:

I'm not sure I would put these book titles
in a tags unless they are actually anchoring
something.



they are not anchoring anything.  strong isn't what i want and  
b is deprecated (?), so what is the practice to highlight a  
word or words?


b is not deprecated, it just has no semantic value and in the fight  
to get people to markup their content semantically instead of  
visually, b and i became clear targets. Unfortunately, this means  
that many people think they should use strong and em when they  
really should use b and i. It's similar to the people who bend  
over backwards in order to put tabular data in some sort of floating  
list construct, just because they think that CSS-styled markup should  
not have the table tag.


From your description, it sounds like you want the b or span  
tag. You want book titles to be bold; there is no clear tag for a  
book title (although there was a thread earlier in the year  
advocating cite I think), so you want a tag with semantic meaning  
like span or b. Then, add a semantic-like class name, such as:


b class=bookTitleInnocents Abroad/b

Then style the class as you see fit.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] html design - best practices

2005-08-16 Thread Ben Curtis


On Aug 16, 2005, at 12:41 PM, Julie Romanowski wrote:


Here is a W3C Working Draft that addresses b and i:
http://www.w3.org/TR/WCAG20-HTML-TECHS/

The em and strong elements were designed to indicate structural
emphasis that may be rendered in a variety of ways (font style  
changes,

speech inflection changes, etc.). The b and i elements were deprecated
in HTML 4.01 and XHTML because they were used to create a specific
visual effect.



That's a very curious thing for the W3C to publish. I am not aware of  
any HTML standard in which b and i are deprecated. Can anyone cite  
such a declaration?


They are included in XHTML 1.1 (Presentation Module)
http://www.w3.org/TR/xhtml-modularization/ 
abstract_modules.html#s_presentationmodule


They were not deprecated in XHTML 1.1:
http://www.w3.org/TR/xhtml11/changes.html#a_changes

As I understand it, nothing was deprecated in XHTML 1.0; in fact,  
they don't define the term for possible use:

http://www.w3.org/TR/xhtml1/#defs

HTML 4.01 didn't deprecate anything; it only clarified HTML 4.0. b  
and i are not deprecated in 4.0:

http://www.w3.org/TR/html401/appendix/changes.html#h-A.3.1.2


If the W3C misspoke, or if they are indeed deprecated but not listed  
as such in the common specs... well, it's no wonder such rumors persist!


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Win IE hacks -- Please help!

2005-08-16 Thread Ben Curtis


On Aug 16, 2005, at 3:10 PM, Janelle Clemens wrote:

My recent headache is trying to create a column/row of cells, like  
what

tables used to be used for, but with the display properties table,
table-row, table-column, table-cell.



Use a table.

Tables are valid HTML. You style them with CSS. When you have tabular  
data, using anything else is unsemantic and wrong. If you have rows  
and columns, then you have tabular data. Use a table.


The table tag is not banned for use in XHTML+CSS sites. Using tables  
to lay your page out is a bad idea, but anything other than tables  
for tabular data is a worse idea. Don't throw the baby out with the  
bathwater.



Oh, and regarding hacks for IE: remember that IE7 is coming out very  
soon, and anything that relies on a parsing bug may behave  
unpredictably. Using * html will likely mean that you will apply  
your hack to IE7 before you even see how it does without the hack.  
Your best (only?) bet is the conditional comment option.


Remember: Only hack the dead.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Firefox DOM and whitespace (bug?)

2005-08-05 Thread Ben Curtis


On Aug 4, 2005, at 2:45 PM, Patrick Ryan wrote:


User agents have always (and will always) ignore whitespace in their
display of XHTML.  Should the DOM ignore it too?  I recognize that's
kind of backward logic, but it's certainly the practical view.



Useragents better *not* ignore whitespace in their parsing of XHTML,  
since any element can be styled with white-space:pre;


They only ignore the whitespace if the CSS tells them to, and even  
then it needs to be stored in the DOM somehow because you may change  
what styles get applied at any moment. In short, the whitespace is  
and always will be important to keep track of, even if it is  
routinely discarded during rendering.


It would be interesting to create a test case to see if IE parses the  
DOM differently based on whether the element in question preserves  
whitespace, and if that parsing changes when the white-space property  
changes


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Firefox DOM and whitespace (bug?)

2005-08-04 Thread Ben Curtis


On Aug 4, 2005, at 1:39 PM, Patrick Ryan wrote:

I recently ran across an issue (I would call it a bug?) in  
firefox's DOM.

...

But in short, firefox considers whitespace (tab, space, new line) to
be nodes in the DOM.

...

But it seems to me white space should be entirely ignored in the DOM.

...

IE handles this differently (no surprise there...) and in
this case, better.  Is this a recent Firefox bug or proper behavior
(that must be scripted around...).



Firefox is right, I believe, because the DOM is defined like this:

The DOM presents documents as a hierarchy of Node objects
that also implement other, more specialized interfaces.[1]

The whitespace is part of the document, therefore the DOM must  
present it within the hierarchy of Nodes. In this case, it is a Text  
node (defined on the same page).


The proper way to parse a Nodelist is to not assume you know what is  
next, but to test what Nodetype the next child is, and then tailor  
your operation to fit (e.g., skip the whitespace and gimme the next  
node). Admittedly, the IE model would make some of my scripts easier  
to write, but then we'd lose the capability of the DOM to work with  
XML such that *everything* is a node, and HTML would be a special  
case that ignores whitespace.


Enough special cases, and the standard ain't so standard. So I think  
we need to keep coding with tests for Nodetype.




1. http://www.w3.org/TR/DOM-Level-2-Core/core.html

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



[WSG] Regexp vs indexOf (followup on: Opening external links)

2005-08-02 Thread Ben Curtis


On Aug 2, 2005, at 1:45 AM, Andrew Krespanis wrote:


On 8/2/05, Ben Curtis [EMAIL PROTECTED] wrote:



Good catch. Now we're talking a good excuse for regular expressions.
Instead of my recommendation of:

 a[i].getAttribute('href').toUpperCase().indexOf(HTTP://) == 0

...I now recommend:

 /^https?:\/\//i.test(a[i].getAttribute('href'))




Talk about technology for technology's sake! At least you admitted it
(good _excuse_ for regular expressions ;)

RegExp() is one of the top three resource hungry javascript functions
to avoid. The other two biggies being eval( ) and setInterval. ( JS
Gurus: please feel free to correct me on that one if you believe
otherwise! )


This is outdated information, apparently. I had heard the same, and  
was curious if things had changed since then, so I ran tests. In  
Firefox, the regular expression is faster than the complete indexOf,  
and just as fast as your minimal indexOf check. Not so in Windows IE  
5.5, and in Win IE 6 the two techniques are on par. This would  
indicate a common audience sees no difference or a performance  
improvement with regular expressions over indexOf.


http://www.bivia.com/sandbox/code_performance/ 
string_parse_speed_test.html


The difference in speed is minor enough (fractions of milliseconds)  
that the extra code to make the indexOf check the same factors (i.e.,  
case insensitivity, that :// isn't occurring somewhere later in the  
url, after the protocol, etc.) is a factor (about 60 bytes = 0.4  
milliseconds over 1Mbps broadband, or twenty times the speed of the  
regexp execution).


But, honestly -- fractions of a millisecond. The only concerns I have  
for the equation are:
1- if it's unobtrusively applied, then is it bullet proof (that is,  
can it give a false positive a non-scriptor will have to contend with)?
2- is it easy to read, understand, and modify three years later  
without documentation?


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Opening external links in popup windows with no extra markup

2005-08-01 Thread Ben Curtis


On Jul 29, 2005, at 5:53 PM, Andrew Krespanis wrote:


On 7/30/05, Thierry Koblentz [EMAIL PROTECTED] wrote:


I think you ought to check specifically that 'http://' is at the
beginning of the string.



Good point, I'll change this.



A more reusable approach would be to check for '://', as this is what
differentiates 'mailto:', relative paths and 'http://' links, but will
still allow you to use the script on secure pages.
Whenever dealing with href maniputlation, it's always good to keep
'https' in the back of your mind ;)



Good catch. Now we're talking a good excuse for regular expressions.  
Instead of my recommendation of:


a[i].getAttribute('href').toUpperCase().indexOf(HTTP://) == 0

...I now recommend:

/^https?:\/\//i.test(a[i].getAttribute('href'))

(tested only in Firefox, Safari; pretty sure it's good but I'm not  
familiar with IE regexp quirks)


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Opening external links in popup windows with no extra markup

2005-07-29 Thread Ben Curtis


On Jul 29, 2005, at 12:43 PM, Thierry Koblentz wrote:


One thing though--  what happens to mailto: links?


Good point! To be honnest with you I didn't even think about these :)
But they are safe because I'm checking for an HTTP string  
inside the

attribute's value.


I think you ought to check specifically that 'http://' is at the  
beginning of the string. This would help rule out false positives  
like these:


a href=/protocols/about_http.htmlFind out about HTTP/a
a href=/affiliate.asp?ref=http://foo.com/bar.php;Set your  
affiliation reference cookie/a


In your code you have:

a[i].getAttribute('href').toUpperCase().indexOf(HTTP) = 0

...and I think you might be better with:

a[i].getAttribute('href').toUpperCase().indexOf(HTTP://) == 0

And other than the design choice of whether all external links ought  
to open a new window, I think you've got something good. I like your  
idea of attaching the style and title with javascript so as to leave  
the natural behavior intact.


Personally, I prefer the rel attribute, because when done well you  
are expressing the arbitrary relationship the current document has to  
the target document. If you only use rel to basically say open a new  
window then that's not very semantic and it's coupling markup and  
behavior closely. But if you use rel to say some links are for other  
content, others are for examples and figures, and either can be  
external sites, and then use JS to set examples and figures on  
external sites to open in new windows, then you're golden. Your rel  
is meaningful and your behavior is attached to the meaning of the  
markup.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] My life as an 800x600 leper

2005-07-26 Thread Ben Curtis


On Jul 26, 2005, at 3:04 AM, Jeremy Keith wrote:


Clive Walker wrote:


We use the stats here to guide our general design choices.



I think that's missing the point. The goal is not to design for the  
majority but to design for everybody.



It is often not a question of designing for the majority or for  
everybody, but a question of optimizing the experience. A horizontal  
scrollbar does not mean the site is broken, it means that it is more  
difficult to use. Similarly, scaling a graphic with text on it (say,  
a map) down to 750px wide or 450px tall might mean that you've just  
made it more difficult for those with high resolution to read. Even  
more difficult if it's sized to 200px tall, to be above the fold  
after all the logo and branding and ads and navs up top. Using SVG to  
scale it would make it more difficult for those using browsers that  
require an SVG plugin. Using Flash instead would make it more  
difficult to repurpose the content outside of that proprietary  
technology.


Design can often achieve satisfactory or even exceptional results for  
everybody. Sometimes, compromises should be made, IMO, and user stats  
can inform those decisions. But be careful: don't use the stats of  
websites that publish stats. These are frequented by us; a biased  
group to be sure. Use the stats of the previous generation of the  
site you are working on, or similar sites. Two personal cases from  
this year:


1- we redesigned a site for a big name actor. His old site was 1020px  
wide, with the content on the left and navigation on the right.  
Before designing, we ran a screen-size tester on the home page and  
found 25% of the visitors with javascript enabled had screens 800px  
wide or narrower. This meant that 25% of the audience did not even  
know there was navigation on the site, partly explaining why 50% of  
the visits were to the home page only.


2- we redesigned a site for an interior design firm. The old site was  
built (by us!) in 1996, and back then maybe 25% of the users had  
800x600 screens, so the site was narrow. We ran the screen tester on  
this audience -- execs and their assistants, artists, and people with  
a bunch of money to spend on making stuff look good -- and found no  
one at 800x600, and the average screen res above 1024x768 -- my  
designer got excited at having a big canvas. On a hunch, I tweaked  
the code to measure the browser window size: average was now about  
800x700, with the big-screen people using a narrow window. Just the  
same as everyone else.


Nothing beats your own stats. But don't use stats as an excuse to  
exclude people.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] javascript question - body onload events question

2005-07-21 Thread Ben Curtis


On Jul 21, 2005, at 8:29 AM, Drake, Ted C. wrote:


I hope this is on-topic.


Javascript and DOM are web standards, and on topic. They just aren't  
talked about much.



Many of us are already using the great Zebra Tables from  
Alistapart.com
It requires an onload event for the body tag and to include a link  
to the

javascript file.


Your solution is to add the onload handler within the script, instead  
of within the body tag. Then you can include the script whenever you  
need it.


If there are no other onload handlers, and never will be (you know  
the future, right?), then you can assign it easily enough by adding  
these lines to the end of the referenced script file:


window.onload = foo;

...where foo is the name of the function you want to call onload.  
Be careful: you are adding a reference to the function, and you are  
not *calling* the function here. That's why there are no parentheses  
after foo. Here's how I remember that: parens mean do this, so when  
the window does its onload, it calls onload(). If you assigned  
foo() to onload, then the window would call onload()() and  
that's not right, is it? The parens get added when the thing happens;  
for now, don't put them in.


Now, a cleaner way to add the onload is to preserve any existing  
onload handler, instead of overwriting it. That way you can add a  
fancy shmancy javascripted menu system later. You could write your  
own function, or use this:


function addToOnLoad(fn) {
var Prev = window.onload || function () {};
window.onload = function () { Prev(); fn(); }
}

addToOnLoad(foo);

This function is drastically simplified from the truly compatible  
version (but works Win IE5-6, Gecko, Safari, not Mac IE, although I  
*thought* it did). To use it, *all* onload handlers need to be  
assigned this way; the first one assigned in the body tag throws out  
all the others. So:


addToOnLoad(foo);
addToOnLoad(bar);
addToOnLoad(baz);

The DOM provides a better means to do this, but IE isn't on board  
with it yet, so there are a hundred scripts out there for this basic  
idea.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Learning The DOM

2005-07-19 Thread Ben Curtis


And now, I'd like to turn the question around and ask everyone on  
this list what they'd like to see from the DSTF.


How much JavaScript do you know?


Quite a bit. I helped beta some of the LiveScript engine the  
Netscape boys whipped up in 95. Sadly, I was stuck in a be  
compatible with Netscape 4 environment for far too long and now have  
some severe DOM deficiencies.




What kind of things about DOM Scripting need clarifying?


There's a bunch of stuff out there along the lines of use this  
script to do X.
There's some stuff about I've just made this standard way of doing  
things that solves a bunch of problems.
There's also a bunch of stuff about here's a mega-library that  
solves all your monster DOM/AJAX/Web application problems.


There's very little about growing, as a programmer/problem solver,  
from the using and hacking of found scripts, to architecting large  
organizational solutions. For example, most Unobtrusive examples end  
with this line to get things going:


window.onload = init;

For all the effort that goes into an Unobtrusive script to make it  
play nice with the HTML and CSS, this one line essentially declares  
There shalt not be any Other Script before Me. Beginners try to  
stitch two of these in the same page, and it fails and they think  
they broke it. If beginners are going to become advanced, they need  
to know more than code; they need to learn how to stitch scripts  
together to make systems, and systems to make applications. It's that  
mentality, that potential for hugeness in every minor script, that  
needs more support in more tutorials.


I *don't* think this means we need another here's the architecture I  
use presentation -- I would cringe at the notion of an official,  
WaSP-authorized standard. Learning to think about architecture is  
different than using someone's pre-developed one. We need to teach  
the beginners how to think differently. Without that, DOM is just  
another set of methods to memorize.



Do you want to see examples of cool stuff with a kind of DOM  
Scripting for dummies style explanation or more sober articles  
with a more geeky leaning?


There may be a place for a For Dummies approach for the topic, but  
in my experience such approaches get the complete n00b going just far  
enough that they realize what they need to learn and they move on.  
Cool stuff is what gets the word out (e.g., techniques and articles  
cited in this very list), but I think the level of the learner should  
be assumed to be higher than that.



Please share your personal experiences: what's your skill level  
with JavaScript compared to say, CSS or XHTML? What's your opinion  
of JavaScript?


I run a team of coders who do all that stuff, and I'm their reference  
for getting it all to play nicely. To me, the separate languages are  
more than separating presentation, structural content, and behavior;  
it's about giving my team the tools to do their jobs without stepping  
on each other's toes. I see the three languages just starting to  
learn the steps of a very cool dance.



Feel free to contact me off-list, if you wish to chat more.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Body tag background color changes

2005-07-19 Thread Ben Curtis


On Jul 18, 2005, at 7:16 PM, Bert Doorn wrote:


Just wondering whether there was a way to include different body
background colors (for different pages) within the same css file.
For example #fff for page1.html, #ffc for page2.html etc.


If every page has to have a different background colour, you could  
put an ID on the body element, then in your css:

...
If there's a few different backgrounds but they are used on a  
number of pages, use a class instead of id.



This is a good habit, IMO, although technically the body tag is  
unique on the page and so many pages on the site can have a body tag  
with the same id -- IDs need only be unique per document. There are  
two reasons it's still useful (AFAICS) to make body IDs unique on the  
site, and classes non-unique:


1. You may be coding in XHTML, which may give you the ability in the  
future to do something entirely wacky like dump every page in your  
site into a single XML file. Then you'd want your XPath query to be  
able to home right in on a single body element.


2. Class attributes are a space-delimited list, allowing you to stack  
up the categories the body belongs to. I use this technique to define  
a range of layout types, which may be content- or section-specific,  
like so:


body id=pageBioPubIntphoto class=sectionBio sectionPub  
layoutText


The page___ and section___ identifiers are derived directly from  
the path, and the layoutText class in this case sets black text on  
white background (the layoutPic is mostly pictures, with a black  
background and subordinated grayish text).



With this technique, you can do more than change the background per  
page, section, or layout type. You can also, for example, set  
specific dynamic submenus to appear or hide, or layouts with the same  
IDs can be radically shifted.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] web stanards detection - is it possible?

2005-07-13 Thread Ben Curtis


On Jul 13, 2005, at 7:03 AM, sam sherlock wrote:

Basic Splash Page that degrades (though in my case it can't degrade  
too much) directing the user to a site more suited to them (with  
some PHP trickery and a list of Bad Browsers)
I don't want to emabrk upon a a tangent taking us off the focus of  
this list, lets say I had a list of known bad browsers and they get  
put to Junk/Old Skool site and all others go to the full xhtml  
experience (others later can view the full flash experience)


Since this is a music media site the main user base are expecting  
glitz n glamour, bells n whisltes a plenty.  Not giving them this  
is against the wishes of the site owner.



The key unknowns about your proposal are:

- what browsers are included in your list of Bad Browsers (and how  
much of your audience is that)?
- what do you mean by full XHTML experience? What XHTML features  
are you using that your Bad Browsers can't handle?
- does the site owner agree that this is worth doubling the  
development costs?


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] are underscores a problem

2005-07-08 Thread Ben Curtis


On Jul 8, 2005, at 1:37 AM, Chris Taylor wrote:
I've been using the dash and period in ID names a lot recently  
(part of
an unobtrusive DOM scripting set of functions I've been developing)  
and

not found any problems yet in any of the Win browsers. Whether IDs
formatted like this functionName.-fe-4r-6s-ef-s5-ef.2000 will  
work in

older browsers or different operating systems I'm kind of crossing my
fingers about!


By not found any problems I assume you mean that these IDs are only  
referenced by your script, and not the CSS. JS only requires that IDs  
are strings. Trying to assign styles to your elements via CSS would  
be problematic, since each period would be interpreted as a class  
name indicator, and your middle classname starts with a hyphen (an  
illegal start). But if you are only accessing the info via JS, then  
it should be fine.




Richard Czeiger wrote:

Does that mean the best way to go fro ID, Class Names, Variables,
etc... is interCaps (also known as CamelCase or lowerCamelCase) ?


Some people believe so. I do. The problem that you'll run into is  
that IDs and class names are case sensitive with an XHTML doctype  
(and always case sensitive when accessed via the DOM), and so using  
compound words can result in particularly difficult bugs to find  
(e.g., what that backGroundDIV or BackGroundDiv or backgroundDiv  
or...?). Best to avoid compound words, I think (e.g., replace with  
bgContent).


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] are underscores a problem

2005-07-07 Thread Ben Curtis


That said, I was asked if we could modify some id and class names  
to go from
nav1sub1 to nav1_sub1 . I told them my preference would be nav1- 
sub1. But
then I thought I should check to see if there would be any problems  
using an

underscore in an id or class. Is it one of the legal characters?



This topic came up a month ago. Read the archived thread for more info.

Underscores were illegal in CSS 2.0, but legalized in 2.1 since  
every browser except Netscape 4 violated that rule. Since 2.1 is a  
refinement of 2.0, 2.1 completely replaces 2.0 -- that is, there is  
no such thing as conforming to CSS 2.0, like you could conform to  
both HTML 4 and XHTML 1.


Hyphens are not forbidden, but are frowned on since they caused minor  
problems with some versions of Javascript interacting with IDs. I  
don't remember the specifics.


If you need to support Netscape Navigator 4.x, do not put underscores  
in your IDs or class names.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] HTML 4.01 versus XHTML 1.0

2005-07-05 Thread Ben Curtis


This topic was discussed last month, with good results.
http://www.mail-archive.com/wsg%40webstandardsgroup.org/msg17988.html


On Jul 1, 2005, at 3:03 PM, Iain wrote:

If I were to write a webpage in XHTML of any flavour but also made  
the effort to serve it with the correct MIME-type to browsers which  
support it, that would work fine, but the benefits would be  
debatable.  If I had javascripts within those pages and the pages  
were served as XML, some methods that work when they are served as  
plain old HTML would not work in an XML document.



The counter argument, over which you are free to decide, goes like this:

1. Serving two MIME types is likely not worth the cost, since there  
is likely few XML abilities you would use in today's browser market.


2. Properly coded, XHTML served as text/html does not break in  
today's browsers. There are valid arguments that XHTML does not make  
*valid* HTML, but XHTML does not break because today's browsers do  
not fully implement HTML. Being that HTML is dead, they are unlikely to.


3. Your site is likely to exist in the future to some extent, and at  
some time you might need to port your current pages into a future  
format; this format is likely to be XML-based.


4. Coding as XHTML today does nothing for your site today (unless you  
serve two MIME-types, in which case it increases your work), but it  
may significantly reduce your effort to port it to tomorrow's format.


Others argue that a port is a port, and cleaning the XHTML so that  
you can use XSLT to manage the port is little different than cleaning  
your HTML and using a Perl script to port the pages over. I'm a wiz a  
Perl and would have no problem, but I sorta hope I'm running the  
company when it comes time for porting, and the guys that port my  
code are going to know XSLT -- so I'm writing XHTML today for them,  
not for me. Also, I expect the odd errors that creep into XHTML are  
easier to clean than the odd errors and coding variances that crop up  
in HTML.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613




**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] input/text random background color in IE?

2005-06-27 Thread Ben Curtis


Why is it that IE turns the background of some input/text elements to 
light yellow?  I can't find any information as to why or how it's 
doing this...and I want to stop it.



Keep in mind when you want to stop normal behavior of the browser, if 
you succeed then people that expect that behavior will become 
disoriented and perhaps will believe that your site is broken. In 
essence, the answer to your question may be IE turns some input/text 
elements to light yellow because the user wants them that way. You 
haven't given us enough background to understand if this general rule 
applies to your circumstance.


I'm not sure about IE, but Safari does this to indicate which fields 
were filled in by the auto-fill and which the user had modified. 
Without this distinction, the users may submit more incomplete or 
inaccurate forms.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] detecting css display properties

2005-06-24 Thread Ben Curtis


On Jun 23, 2005, at 11:30 PM, Focas, Grant wrote:


What about document.getElementById('something').style.display

...

Also, the display property may not yet be set.



The .style object of an element only contains properties that are set 
within a style attribute in the tag:


style type=text/css
span { display:block; }
/style
...
span id=foo style=display:inline;Foo./span
span id=barBar./span
...
script type=text/javascript
alert(document.getElementById('foo').style.display); // alerts inline
alert(document.getElementById('bar').style.display); // alerts  or 
barfs

/script

The proper DOM method is:

document.defaultView.getComputedStyle(el,'').getPropertyValue(prop);

...where el is the element reference, and prop is a hyphenated 
string representing the CSS property you wish to retrieve (i.e., 
background-color and not backgroundColor).


IE 5.x (6 too?) doesn't recognize this, but does give you access to the 
.currentStyle object -- gives you teh same thing but you need to 
camel-case the property string:


el.currentStyle.backgroundColor

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Hiding styles from IE5?

2005-06-22 Thread Ben Curtis


On Jun 21, 2005, at 4:23 AM, Roberto Gorjão wrote:

In this last styles sheet I reset all properties to 0, auto or 
inherited, using the wildcard selector.



Won't this be of lower specificity than all your other styles, and 
therefore never triggered? Are you using a bunch of !important 
declarations?


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] detecting css display properties

2005-06-22 Thread Ben Curtis


I have been trying to detect ,using javascript , the css display 
property

(set via an external @import style sheet)  of an element

Example
page: http://www.jimthatcher.com/site_resources.htm has a LI 
(class=skip

with CSS display:none.
but when i try to find this via the (IE DOM) i cannot locate it.



I've written a script that I've used many times. Seems to work well 
enough (Win IE5+, Mozilla/Firefox, Mac Safari 1.3), although the format 
of the returned values varies a bit (e.g., Safari outputs colors as 
rgba(), Mozilla outputs what you've typed, IE and Opera expand it out). 
Safari before 1.3 was unable to do this.


Here's my test page with the script embedded.

http://www.bivia.com/sandbox/bv_lib_tests/find_current_style.html

One problem you'll have (I just tested this) is that Safari seems to 
dislike getting the style of display:none. I haven't looked into this 
further.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Clash of nested lists

2005-06-20 Thread Ben Curtis



Here the problem though:
I want to display a couple of icons infront of each of the folders 
(Edit,

Delete, ...). So my list actually looks like this:

- Edit Delete Folder One
  - Edit Delete Subfolder One
  - Edit Delete Subfolder Two
- Edit Delete Folder Two
- Edit Delete Folder Three



I've cobbled together this:
http://www.bivia.com/sandbox/list-with-links/v1.0_span_goes_away.html

The links are after, instead of before, but under the li text for 
consistent columnar presentation; an off-left skip link jumps you to 
the next list item. In this way, the text of the list item is read, 
then you can jump over the edit/delete stuff. Not sure about the wisdom 
of adding one link to skip two, but if you had more than two (edit, 
delete, verify, reorder, inquire, rename, foo, bar...) it might be 
good.


I think that by forcing your links before the text you're hobbling 
yourself.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Marking up lists with title

2005-06-17 Thread Ben Curtis



What is the recommended way to mark up a list that has a title?


With better IE support, I might do:

ul title=Features
 liIt's big/li
 liIt's heavy/li
 liIt's wood/li
/ul

...and then style it something like:

ul[title]:before {
display:block;
content:attr(title);
}

But, as it is, I suggest:

div
h1Features:/h1
ul
 liIt's big/li
 liIt's heavy/li
 liIt's wood/li
/ul
/div


Replace h2 with 2,3,4,5,6 as appropriate. The only drawback to this, I 
think, is that you are saying the heading is for the section, and the 
section contains a list -- not that the heading is for the list.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



[WSG] Proper use of alt, title, longdesc

2005-06-17 Thread Ben Curtis


I'm trying to create easy-to-follow guidelines for my team. Regarding 
alt, title, and longdesc attributes for img tags, I'd like to know if 
my summary below could use some correcting. Also, URLs of concise 
guidelines on the matter would be appreciated.


1. When possible, images that are not part of the content (i.e., the 
user came to this page to view the content) should be placed in the CSS 
when possible.

2. ALL remaining img tags must have an alt attribute.
3. The alt text should be an empty string if the image conveys no 
information.
4. If the image has text in it, that text MUST be in the alt text. 
(Exception: CAPTCHAs)
5. If the image conveys information without words, compose a 1-5 word 
descriptive phrase to serve as an alternative to viewing the image, and 
use this as the alt text. Alternative does not mean descriptive; it 
means it serves the same purpose as the image. E.g., if the pictures 
help people identify people, use their names (Bob Downes, CFO), not 
description (man smiling in tweed suit).
6. If 5 words cannot convey the required information because details 
are important to understanding (e.g., a figure or illustration 
discussed in the accompanying text), use the longdesc attribute to link 
to a longer description of the image.
7. If additional information is desired (typically, meta information 
about the image, e.g., name of photographer), and does not need to be 
visible, use the title attribute. (Rare.)



Regarding the longdesc, I read with interest the idea of longdesc 
footnotes, and may try to standardize on this.

http://www.stuffandnonsense.co.uk/archives/accessibility_footnotes.html

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] the use of reset buttons on forms

2005-06-15 Thread Ben Curtis


But I am getting the feeling that the reset button is not only a waste 
of time, but in fact fairly user-unfriendly. ...
Seriously: how many people enter data into a form and go so completely 
wrong that they want to erase everything they have just done and start 
over new?
On the other hand, how many people *accidentally* press the reset 
button when they actually wanted to hit the submit button?



I think in most forms, a reset button is junk and can only add stress 
to the site's relationship with the user. The edit initial 
information form mentioned by Justin is the exception.


However, I suspect we'll see more of them for AJAX-powered form 
submission. Much like previous uses with frames, the form may be 
persistent while the submission results change. There may be cases for 
those forms where a new submission ought to start with a blank or 
initialized slate, and the form is not blanked out via the submission 
process. There likely will develop a better way to handle it though, 
since the Javascript needed to handle the form is so much easier than 
the stuff for such an application.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] em vs i

2005-06-14 Thread Ben Curtis




I recall some controversy surrounding when to use em and i, could
someone clarify proper use?


Simply don't use i, because it is visual markup. Think about what
you really want. Is it emphasis, use em, is it just something visual
use span class=someclasstext/span. And try to give the class a
semantic name, not italic.



The counter-argument being that there is no semantic difference between  
this:


span class=someclasstext/span

...and this:

i class=someclasstext/i

...and that if you are going to style someclass anyway, then they are  
functionally the same except the second provides a default style when  
CSS is inactive. In addition, if you do DOM scripting and want to  
access your italic tags, getElementsByTagName('i') is likely faster  
than getElementsByTagName('span'), though probably not by much.


Please note that this argument only holds when you want a semantically  
empty vessel, for example when you are italicizing foreign words, book  
titles, ship names, or other things that are typically italicized but  
not emphasized. Each of these cases should have a different class, even  
if they are all styled with italics. It is true that most times you  
think of italics, you will want to use em.


The downside of this argument is that screen readers have adjusted to  
the typical use if the i tag, and will emphasize text within it even  
if you end up styling it otherwise.


There is a myth that i (and b, and big, etc.) are deprecated, but  
they are currently in the XHTML 1.1 Presentation module, so this myth  
is not true. However, they are in the *Presentation* module, which  
gives a clue as to their semantic value.
http://www.w3.org/TR/xhtml-modularization/ 
abstract_modules.html#s_presentationmodule



Hope this helps you make a decision.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] WSG Meetings for the rest of us

2005-06-09 Thread Ben Curtis


Then there's this one Deaf WSG member who's gonna ask for some kind of 
captioning/subtitling of the video/audio...


One free audio download per subscriber.

To get your next free download, you must submit at least 250 words of 
transcribed text.


After you've transcribed 1000 words, you can review others' 
transcriptions instead. Press the lever, get your pellet.


Someone more brilliant than me figures out how to merge 100 submissions 
into one transcription, incorporating the reviewers' ratings of each 
transcriber. This person founds a business and makes a mint. Or opens 
the source and becomes an accessibility guru and makes a mint. Or keeps 
mum, tells everyone he's doing it by hand, charges by the hour (38 of 
them yesterday alone), and makes a mint.


The world rejoices. Qantas stock plummets as we all stay home in 
pyjamas instead.


--

Ben Curtis : webwright
	bivia : automatic business plans for saving the world and making a 
mint, while you wait

http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Ten questions for Russ

2005-06-07 Thread Ben Curtis


Apparently the MIME/DOCTYPE argument of XHTML vs HTML has been going on 
for a while, a bit out of my scope. I only have one argument to 
contribute, which I don't believe I've seen before and may be of some 
value.



On Jun 7, 2005, at 7:17 AM, Rimantas Liubertas wrote:


Yes. Only critical thing for the Web standards is _understanding_ them
(and HTML4 _is_ a standard, you know?), not just using something that
is cool and much talked about.
And understanding includes knowing pros and cons and when and _why_ to 
use each.


I (my company, my team, my clients) am interested in standards only so 
far as they make the future more predictable. To make the future more 
predictable, my code today needs to be more regimented.


HTML is a standard; it is broadly supported today, but its future is a 
predictable dead end. Any future versions of a document coded in HTML 
will need to be coded from scratch, or a custom parser will need to be 
made to convert it to some future standard (or close enough that 
hand-tweaking the rest is ok). Because HTML is more loosely defined, it 
is more difficult for teams to code to a regimented standard, making 
the prospects of even a custom parser unlikely in the future. Things 
don't *have* to become sloppy just because the team codes in HTML, but 
it will be difficult to tell if they are becoming sloppy -- so the 
future is not as predictable.


XHTML is a standard; it is poorly supported today, but its future will 
allow it to be predictably converted to any other XML standard through 
standardized tools (offline, regardless of MIME type or DOCTYPE). It is 
a highly regimented standard, with tools already built to help coding 
teams make their code more predictable.


XHTML is useful to me because I can swap out the DOCTYPE and serve it 
as HTML, because it *is* HTML, giving it broad support today while 
giving it a predictable and flexible future. This is, essentially, 
XHTML-compatible HTML 4.01 Strict.



One of the central tenets of the arguments that we should be coding to 
HTML instead of XHTML is that the only or primary purpose of using 
XHTML is that you need XML-based abilities (namespaces, etc.). This is 
something I agree with. However, it is a mistake to believe that these 
abilities will be used today, when the document is created, or even 
tomorrow when it is served from your web server. It might be 5 years 
from now when the document is inserted as-is into an XML database 
archive, or 7 years from now when converted to XHTML2, or later this 
year when you get around to syndicating that content you've been 
marking up for the past 5 years.


We are coding and serving HTML today; by coding it as XHTML-compatible 
we can extend the life of the document indefinitely.




And that's all I have to say about that.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Ten questions for Russ

2005-06-03 Thread Ben Curtis


Russ,

One of the topics you discuss is your stance on the XHTML vs HTML 
debate. Your links support your stance -- I've read these before, and 
find them interesting and insightful, however they are trying to 
convince the reader of their point and I prefer a balanced argument. In 
looking for articles on the other side of the argument, I quickly found 
myself swamped in a mountain of words, some rational, some rabid. It 
would take days to wade through.


Do you know of a place or article that is a good roundup of the 
arguments, presented neutrally or balanced so the reader can assess 
his/her position and decide accordingly?


Right now I'm serving HTML (text/html Content-type headers), but as a 
coding practice we code as XHTML 1.0 Strict (for the cleanliness of the 
code, not for the XML properties). For the sake of validation as a 
coding tool, we need to put in the XHTML DOCTYPE, but I'd like to serve 
the HTML DOCTYPE in order to match our Content-type headers. Perhaps 
some automated scripty thing.


But that is neither here nor there. What I really want to do is weigh 
what I regard as our shop's personal coding standards against a roundup 
of these arguments to see where we stand.


Any pointers?

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] best way to approach markup of an address

2005-05-26 Thread Ben Curtis


On May 25, 2005, at 8:32 PM, Andrew Krespanis wrote:


On 5/24/05, Ben Curtis [EMAIL PROTECTED] wrote:


dl class=postalAddress
dtCanada/dt
dd class=companyIn The Game, Inc./dd
dd class=divisionCustomer Service/dd
dd class=street1135 West Beaver Creek Road Box #604/dd
dd class=cityRichmond Hill/dd
dd class=stateON/dd
dd class=postalCodeL4B 1C0/dd
/dl


picky type=semantics
I think that one would have to qualify as improper use of a dl.
The method I use to decide on the appropriate use of dl is to say
'equals' in between the dt and each dd.

...

/picky



Agreed that it's imperfect, and your comment is not terribly picky -- 
this is an ambiguous topic at best. A) I was merely supporting 
another's suggestion of using such markup, and  b) I haven't ventured 
much into this space and haven't come up with something semantically 
closer to what I want that allows me to style it the way the designer 
and client want.


I think the stronger way to determine if a definition list should be 
applied is: in your group of related elements, are they all equal 
players that relate in the same way to a single item or term?


You choose a narrow definition of definition so that your relate in 
the same way is always equals. I have chosen to be a bit more broad, 
and have used dls to create breadcrumbs and other subnav blocks, 
where each element in the list relates to a title for the list that I 
often hide. I think in the future I may do something more akin to this:


div class=subnav
h2subnav stuff/h2
ul
lia href=here.htmlHere/a/li
lia href=there.htmlThere/a/li
lia href=somewhere.htmlSomewhere Else/a/li
/ul
/div

...which seems more correct, though less novel than the dl did when I 
first started using it.


Thanks, Andrew.

--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Best way to train someone in css and web standards

2005-05-23 Thread Ben Curtis


On May 23, 2005, at 10:58 AM, Gunlaug Sørtun wrote:


Keep them away from anything that isn't strictly standard-based (x)html
and CSS for a while. Let them work and test against real browsers and
the validators, and make sure IE/win doesn't get in the way with its
broken standard-support and tag-soup recovery.



Stick them on Firefox with these two extensions:

HTML VALIDATOR (based on Tidy)
http://users.skynet.be/mgueury/mozilla/
Validates as they view their pages, so they should always see the 
beautiful green checkmark that says the HTML is valid. It has some 
issues, but hopefully it will train them to cringe when they miss that 
closing slash on their link tag.


WEB DEVELOPER
http://chrispederick.com/work/firefox/webdeveloper/
Web Developer is a toolbar with wonderful, wonderful abilities for 
people learning CSS. Chief among them is the Outline menu and the 
ability to switch styles off with a keystroke, IMO. The Tools menu 
also trains them to validate, validate, validate.


--

Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613



**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] got a safari hack

2005-05-17 Thread Ben Curtis

Is there an equivelant to the underscore hack for safari out there?
Based on Bert Doorn's idea in January, I started developing and testing 
this:
http://www.bivia.com/sandbox/safari-hack/

It was working perfectly as a Safari hack -- until Safari 1.3 (aka, 
Safari 2.0) came out with the case-sensitivity thing fixed. (Mostly 
fixed: the alternate hack still catches Safari, but also catches 
Mozilla older than 1.7.) As a result, I think this line of thinking is 
dead, but you're free to tinker with it.

This hack still seems to work, although it doesn't validate:
html*[class~=foo] {
/* rules */
}
This shows some of the folly of using hacks for browsers currently 
under development.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] zindex

2005-04-15 Thread Ben Curtis

I've been playing around with positioning and z-index and I'm 
wondering if it is possible to give a containing box higher z-index 
that it's children.  As far as I have been able to tell, ( in 
firefox/opera ) it doesn't work. I have a ul with a 
background:transparent url(image) no repeat, and I need the li's to 
be under that background image.
Alan,
I made this test a couple days ago: 
http://www.bivia.com/sandbox/z-index/

You can specify a negative z-index for the children, which will put 
them behind the parent in theory. However, it looks like that's Gecko 
and Opera only for now. Don't know if that's because it's a newer 
standard or what.

Any z-index you add to the parent only establishes its stacking order 
within the stacking context it exists in--usually its own parent. It 
also establishes a new stacking context for its children. Also, z-index 
only applies to elements not positioned statically (i.e., absolute, 
relative, or fixed), but some browsers mess up the fixed thing, and 
Opera seems to get confused when things get floated.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Fixed pixel fontsize - resizable font size

2005-04-14 Thread Ben Curtis

was wondering if there are any percentage or em
equivalents or formulas to convert from:
FONT-SIZE: 11px, 22px, 10px, 14px and 16px.
To go from pixels to em's, simply divide by 16.
Is this a cross-browser, cross-platform formula? Is there a chart of 
the standard settings for browsers, and possibly for the common user 
settings?

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Hidden Content

2005-03-30 Thread Ben Curtis

What is the repercussion, if any, of having a div set to display: 
none with content meant strictly for search engines.
Strictly for search engines? Actually, non-flash content would be most 
valuable for accessibility reasons to all users which don't have, or 
can't use, flash content. And there's the rub: most screenreaders 
don't see any content that has been hidden via display:none

I've got a site that uses javascript to deliver enhanced content, 
including Flash. The same javascript writes out the display:none; 
declaration for the non-Flash content (which is identical to the Flash 
content -- in fact, the Flash pulls its content from the HTML). I 
figured this was fairly foolproof, but I'm not 100% certain.

Any comments on the general theory? (The particular implementation, 
actually, leaves something to be desired...)

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] !important via script possible?

2005-03-29 Thread Ben Curtis

I'm pretty sure this isn't possible, but does anyone know if its
possible to add the !important declaration to a style set with script,
as in:
document.getElementById(mydiv).style.height = hvar + px !important;
When would this ever be necessary? Do you have a test page we could 
look at?

When you set an attribute of the style object, you are essentially 
declaring a new value that is last in the cascade. It should override 
anything else that is not set with !important. So if you are finding 
that you need to use !important in the scripting, I suspect you might 
find it easier to search back through the CSS and remove those 
!important declarations that you don't need.

That said, you might have better luck using the IE runtimeStyle 
object instead for that browser.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] problem mixing stucture and content

2005-03-29 Thread Ben Curtis

Consider the following lines of fake poetry:
   Class aptent taciti sociosqu ad litora torquent,
   per conubia nostra per inceptos hymenaeos.
Now consider making a xml document out of it
...
   |?xml version=1.0 encoding=utf-8?
   poem xmlns=http://some.name.space;
   lineClass aptent taciti sociosqu qad litora torquent,/line
   lineper conubia nostra/q per inceptos hymenaeos./line
   /poem|
but it's not well formed, and neither or the alternatives

Allow me to pose this back to you:
The display for these data is 13 characters wide. Do your 
line.../line content wrap?

no = the fact that it is on one line is more important than being 
able to read it in its entirety (e.g., wrapping it would change the 
meaning, as in ASCII artwork)

yes = the content is more important than the display, and the end of 
line more important than the fact that it is a single line.

So, for your poetry example, I would encode it like so:
poem
	stanza
		Class aptent taciti sociosqu qad litora torquent,br/per conubia 
nostra/q per inceptos hymenaeos.
	/stanza
/poem

br/ in this sense doesn't mean a line-break so much as it means 
end-of-line. If a quote did not terminate before the end of a stanza, 
then you self-close the quote; the next quote will be an open-quote at 
the beginning of the next stanza, anyway.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] XHTML 1.1 Presentation Module

2005-03-24 Thread Ben Curtis

I can gather from this exchange, although the elements have not been 
deprecated, they should not be included in clean semantic markup?
One could argue that the replacement of i, b, sup, sub, tt, and hr with 
spans, classes, and the like are equally unclean semantically. What is 
the semantic difference between these two bits?

	Einstein's span class=foriegnPhrase 
lang=deGedankenexperiment/span
	about being a photon led to span class=equationE = mcspan
	class=mathExponent2/span/span.

...or:
Einstein's i class=foriegnPhrase lang=deGedankenexperiment/i
about being a photon led to b class=equationE = mcsup
class=mathExponent2/sup/b.
Since the presentational tags are empty like span, these are 
semantically equivalent. The difference, I suppose, is trying to be 
forward compatible with XHTML2 -- a ludicrous idea at this time, IMO.

This standpoint (I'm not sure I agree) I've found best articulated here:
http://mpt.kiwiwebhost.net/archive/2004/05/02/b-and-i
http://mpt.kiwiwebhost.net/archive/2004/05/09/semantic
--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] CSS validator says [xX][mM][lL] is not allowed.

2005-03-19 Thread Ben Curtis

I have valid XHTML
http://idealcouple.com/
http://validator.w3.org/check?uri=http%3A%2F%2Fidealcouple.com%2F
...
Please, validate your XML document first!
Line 2
Column 6
The processing instruction target matching [xX][mM][lL] is not 
allowed.
...
I have both XHTML and CSS valid, but CSS Validator dont think so :(  
Whats my
problem?
...
We use PHP to render XML prolog and DOCTYPE, and we use PHP sessions.
XHTML served as text/html is valid with the ?xml prologue optional.
XML documents must have the ?xml prologue.
Your CSS validation error claims that you should validate your XML 
document. Obviously, then, it believes your *xml* is flawed, even if 
your *xhtml* is ok.

The problem is likely a PHP quirk: newlines immediately after closing 
PHP compilation markers (?) are trimmed. So this code:

Hello, ?php
// some stuff
?
Bob.
...will output this text:
Hello, Bob.
...and not this:
Hello,
Bob.
Thus, your doctype is on the same line as your prologue, and your 
prologue it on the second line when it must be on the first. Hope that 
helps.

--
   Ben Curtis : webwright
   bivia : a personal web studio
   http://www.bivia.com/
   v : 818 507 6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] problems with nodetype

2005-03-11 Thread Ben Curtis

I was tying to use nodeType to make sure that a node was an element in 
my javascript, but it wasn't working.  Then when I did 
alert(aNode.nodeType); I got undefined, I was really confused so I 
tried alert(document.nodeType); and I got undefined again! Is there a 
reason I'm getting undefined instead of DOCUMENT_NODE or 9?

Give us your demo page URL. Likely, you are alerting these values 
before they exist. The DOM attributes don't exist for nodes that have 
not been parsed yet. Are you triggering this onload, or in the head of 
your document?

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] javascript problem with pop-up on hyperlink click (IE6 displays an error, FF, Opera work fine)

2005-03-11 Thread Ben Curtis

and don't use inline scripts. They are as bad as inline styles:
a href=therapeuten/barkow-lewinsky.html  
class=popupBarkow-Lewinsky, Eva/a

var links = document.getElementsByTagName('a');
for(i=0;ilinks.length;i++) if  
(links[i].className=='popup')links[i].onclick = function()  
{window.open(this.href,'_blank','width=450,height=200,left=150,top=150 
');return false;}

This would be better, in case you have multiple classes assigned to  
your a tag:

if (links[i].className.match(/\bpopup\b/))
Better than class, though, would be to use rel=external or  
rel=dialogue or some such thing. The rel attribute describes the  
relationship of the destination document to the origin document. Class  
is a style, and not a relationship. But honestly, 6 of one, half dozen  
of the other.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] navigation using arrows for location

2005-03-03 Thread Ben Curtis
http://c41.com.au/test/sample_nav.gif
...
any ideas, wacky or otherwise, appreciated.

Always respect those wacky ideas.
Here's one:
What you would ideally have is an older-sibling, younger-sibling type 
selector. Then you could select all the li elements that are siblings 
and come before your active element, and give them a vertical line 
background or border. Then give your active element the arrow. And 
leave the younger-siblings (the siblings after your active element) 
alone.

CSS gives you child, descendent and sibling selectors, but no 
source-order selector like that. Dynamic css might give you a chance 
with nth-child selectors, but that's years off from being practice in 
public websites.

So, if you're not averse to calling down the wrath of the semantic 
gods, nest each element so you have a bunch of descendant selectors to 
work with. Instead of the nice and meaningful:

ul
liWoodCentre/li
li250 Latin Street/li
liEl Changeo/li
li2 Changed Ave/li
liChangewood Facilities/li
li class=activeActive Project/li
liPark in Perth/li!
li11 Smith Street/li
li58 amp; 88 Changed St/li
/ul
...you would instead code it like this gob of meaningless gunk:
div class=locationArrow
divWoodCentre
div250 Latin Street
divEl Changeo
div2 Changed Ave
divChangewood Facilities
div class=activeActive Project
divPark in Perth
div11 Smith Street
div58 amp; 88 Changed St
/div/div/div/div/div/div/div/div/div
/div
Then you could style it like this:
div.locationArrow div { background: transparent url(vert-line.gif) 0 0 
repeat-y; }
div.active { background: transparent url(arrow-thing.gif) 0 0 
no-repeat; }
div.active div { background:none; }

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] navigation using arrows for location

2005-03-03 Thread Ben Curtis

However, that would only work if the line always comes from the top of 
the list and then down to the active category. In the example, though, 
the line can come from below (see the line from the first to the 
second list).

Right. I only saw the gif without anything going up. Hm. Wow. Tough nut.
--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] opacity as a hover for photo gallery thumbnails

2005-03-02 Thread Ben Curtis

I need to put a hover on the thumbnails so that the user knows where 
they are.  I'd like to have it change the opacity, but a) I'm not sure 
how accepted that is amongst the browsers
Modern Gecko supports the standard opacity:#.#; property.
Previous Gecko supports -moz-opacity:#.#; in the same way.
Safari/Konquerer supports -khtml-opacity:#.#; in the same way.
Win IE 5.0+ supports filter:alpha(opacity=##);
Win IE 5.5+ supports 
filter:progid:DXImageTransform.Microsoft.Alpha(opacity=##);

#.# is a float between 0 (transparent) and 1 (opaque).
## is a float between 0 (transparent) and 100 (opaque). So for IE, 
multiply your opacity by 100.

Mac IE is out. I believe all Opera 7 is out.
This means 98% of the typical audience will support one form or another 
of CSS-based opacity settings, but only 3-5% will support the standard. 
But typically, specific audiences are atypical. Use your own stats.


and b) if it is, I'm sure how to do it, or where to place it in my CSS.
For your setup, I should think this would work:
#thumbs a {
filter:alpha(opacity=80);
-moz-opacity:0.8;
-khtml-opacity:0.8;
opacity:0.8;
}
#thumbs a:hover {
filter:alpha(opacity=100);
-moz-opacity:1;
-khtml-opacity:1;
opacity:1;
}
I've heard that some opacity engines switch off when the image is fully 
transparent or opaque, and sometimes there is a little flicker at that 
point. The workaround is to not set 0 or 1, but rather 0.0001 and 
0..

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] opacity as a hover for photo gallery thumbnails

2005-03-02 Thread Ben Curtis
On Mar 2, 2005, at 11:05 AM, Ben Curtis wrote:
Safari/Konquerer supports -khtml-opacity:#.#; in the same way.
Behold the march of progress!
It appears that Safari now supports the standard opacity:#.#; call, 
even though it is not listed here: 
http://developer.apple.com/internet/safari/safari_css.html

Just ran a test and turned off the -khtml-opacity and the thing was 
still transparent. v1.2.4. Not sure when it got added.

--
   Ben Curtis : webwright
   bivia : a personal web studio
   http://www.bivia.com/
   v : 818 507 6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Standard this

2005-02-16 Thread Ben Curtis

Why not include a 'browser-build' selector in css?
While it sounds good from a practice perspective, it goes against the 
whole idea of CSS: A standardized, device independent language for 
describing the presentational aspects of a document.
How is this different than a media selector, media queries, or lang 
attribute selectors? These examples seem to fit and they, too, are 
about customizing the presentation based on how it is likely to be 
displayed/interpreted in the particular rendering environment. There's 
no inherent reason not to place a user-agent selector in the mix, so 
long as it was regex-based, and the user-agent strings are not 
themselves standardized.

BUT, as I understand it, speculation and wish-lists are off-topic for 
this list. They are *the* topic of the W3C lists, and I suggest you 
search the archives and post the idea there: http://www.w3.org/Mail/

Such a selector would beat the pants off MS conditional comments.
--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] ie INSANITY ... please help me

2005-02-14 Thread Ben Curtis

note to all: IF IN DOUBT, add position:relative; -- it fixes many,
many IE bugs :)
Would it be excessive or treacherous to declare for Win IE:
* html * { position:relative; }
?
Is the default of position:static; important?
Off the top of my head, I think this would only negatively affect later 
opting to position:absolute;, since it would be absolute in relation 
to the immediate parentNode.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?

2005-02-09 Thread Ben Curtis

I thought I should pick up on the comment by Peter and ask one of my 
many newbie questions... What is the advantage of the fact that IDs 
must be unique on a page? I am aware of the circumstance that if you 
need to repeat an ID, set is as a class, but have still not figured 
out the advantage of an ID.
If you used absolute positioning, or a background image of the company 
branding, or a structure only appropriate for the main navigation, or 
some other set of styles that should only be rendered if they are 
unique on the, then it is useful to have IDs instead of classes. In 
today's browsers, put multiple IDs on a page and the page is ok, if 
maybe unusually styled. But future browsers are likely to be more 
strict and may display a big fat parse error message for such a page. 
That's a good thing -- it'll help you identify when you accidentally 
gave two id=nav styles to teh same page.

It will be problematic, however, when you combine templates, CMSs, and 
webservices-sourced XML all in one document. This is where we are 
rescued by namespaces and the increasingly common habit of giving IDs 
unique prefixes based on the author.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] scribbles

2005-01-24 Thread Ben Curtis

I ... have started to put down some thoughts about
various areas of this 'new philosophy' which have me (as a newcomer of 
only
4 months to 'standards') totally confused. The first endeavour 
concerns the
classic - opening new windows.  My scribbling can be seen at:

http://www.betasite.fsnet.co.uk/comment/scribblings.html

An a tag represents a link to another document from the current 
document. A search engine encountering that link will understand it in 
its entirety. Add the target attribute, and now you've confounded the 
issue. Does that link only exist between these documents if it's in a 
windowing environment? Does the link represent the relationship between 
two documents, or between two windows? If the window's name is the same 
as the target value, and therefore it is not opening in a new window, 
should the link not be followed?

These are the sorts of rules that exist in a windowing environment, but 
cannot be expressed by a simple target attribute. In the end, to keep 
the web platform-neutral, target attributes were removed. 
Platform-specific scripting can easily replace any functionality you 
want to include. For example, I've written a script that finds a 
tags, then attaches specific behaviors based on the rel attribute value 
(the link's relationship to the linked file). For the values of 
popview and newwin I attach new-window functionality.

Yes, this is a bit more work. I think that needs to be addressed, but 
the removal of target is a step in the right direction.

--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Future XHTML Proposals?

2005-01-24 Thread Ben Curtis

I was thinking about your stereotypical Angelfire / Tripod user, the 
beginner hobbyist.
I think about them a *lot*. If it weren't for the ease of publishing, 
the web would not have taken off. Doubt me? How many other networked 
document protocols created in the early 90's or before do you use 
today? I know of a dozen or so -- I only use HTTP/HTML. I think it's 
because it was the only one that could be written so sloppily that we 
could publish things *while* we learned.

I am concerned that the growing rigidity of the code will lock out the 
hobbyists. I believe we are going through a similar transition as early 
radio, after the hobbyist crystal-set owners stopped broadcasting 
because they couldn't keep up with the rules they needed to follow. 
However, without those rules much of the radio culture would not have 
formed.

It is vital, IMO, to have advanced, capable standards existing 
side-by-side with easy, flexible, and immediately useful means for each 
individual to grow into them.


I think the W3C needs to produce more flavors of XHTML than just the 
single specification... I'm thinking more along the lines of:

XHTML 2.0 - Simple
XHTML 2.0 - Contracted Tags + Attributes
XHTML 2.0 - Complete
Where the Simple edition is a vastly simplified version where 
there's less emphasis on content/presentation separation, such as 
greater support for attribute styles and perhaps a LayoutTable 
element? Where each LayoutCell has a Context Order informing 
screen-readers in what order to read the content?
A simple, advanced DTD that is not XML-rigid would be very good. I'm 
not sure tables are needed; our newbie coders think in tables because 
that's what they know. Tomorrow's newbies will think differently.

What is needed is specifically a DTD that merges presentation, content, 
and behavior, without burdening user-agents that are already built for 
the more strict, rigid, powerful stuff. For example, an easier way to 
attach inline styles and scripts than our single event handlers and 
style tags.

div SBorder=1 sWidth=500 AttachMouse=follow()
The content of this div is 500px wide and follows the mouse.
It is not xml-compliant, but its attributes clearly map
to specific CSS standards, with certain, common assumptions.
/DIV
...or some such. Something that allows the newbies to see one small bit 
of code do something specific. From here they can graduate to removing 
styles to classes, behaviors to scripts, and so forth. It is this 
merged ability that makes beginning print layout hobbyists opt for 
embedded graphics, styles, and macros in a Word document over the 
professional layout designer using the separated Quark method. It is 
worth maintaining, and should be deliberately designed to foster 
self-propelled education in the proper methods.


I was also thinking of bandwidth conservation, especilly with the 
mobile device market, and thought up a variant of XHTML where only the 
essential elements are included, and represented using the minimum of 
letters, ditto for their attributes
Don't worry about tag space. Tags compress *very* well with http 
compression, to the point where your code may not save any space.


Note my use of my proposed universal closing tag '/'
Then the bad habit this induces would be to start throwing unneeded 
extra universal-closers everywhere you can think of. Ick.


Just out of curiosity... how do I get things like these formalised 
into an RFC Document and sent to the W3C for review?
I'd start here: http://www.w3.org/Mail/
--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] empty named anchors

2005-01-20 Thread Ben Curtis

h2a name= id=/aSome heading/h2
Or drop the anchor tag altogether. What is the browser compatibility of 
this:

a href=#someIdOnThePageGo to Some ID/a
...
h2 id=someIdOnThePageSome ID/h2
My initial tests show great support. Anyone know better?
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Popups

2005-01-18 Thread Ben Curtis

For when you ever have links that open in a new window, it helps to 
have that little image, would this be appropriate: ?

a href=# onclick=newwindow() rel=external/a
a[onclick=newwindow()] {
   padding: 10px;
   background: url(newwindow.png) no-repeat 0 0;
}

Yes, but...
The point of having rel=external is to provide a hook for an external 
javascript to add the new window functionality. If you have that 
external script running, then having the onclick=newwindow() in the 
tag is redundant. Also, you may need some new-window links to have 
other onclick handlers too, so you should match on one of a pattern 
(foo~=value).

*Also,* having the onclick encoded in the tags reduces your separation 
of content, presentation, and behavior. When possible, keep the event 
handlers in the javascript and out of the HTML.

So...
a href=# rel=external/a
a[rel~=external] {
   padding: 10px;
   background: url(newwindow.png) no-repeat 0 0;
}
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


[WSG] Unusual Mac IE flow error fixed with comment tags

2005-01-18 Thread Ben Curtis
Over the weekend I ran into a series of rendering errors in Mac IE that 
amount to certain circumstances that involve elements taken out of the 
flow (via position:absolute or float:left|right), where the fix 
involves placing a comment tag in the HTML in a certain place.

I've documented it all, and could write this up to help others, but 
before I spend all that time I was wondering if this is a known issue 
that I just couldn't find the right search terms for?

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Popups (plus, standards-based event handling)

2005-01-14 Thread Ben Curtis

Another method I've imagined but never implemented is for each added 
function to add itself to an array of functions.
...
It's efficient. Your imagination is  should try it.

Er, Your imagination is on the right track; you should try it.
My imagination, apparently, completes sentences that my fingers do not.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Zero margin - just sharing

2005-01-14 Thread Ben Curtis

I know a lot of people use this:
* { margin:0; padding:0; }
To help reduce code and eliminate lots of those strange default margins
issues.
Don't think this has been mentioned anywhere yet, but one issue I 
found with
this, was that within dropdowns the downarrow GUI, covers some of 
the text
on the right. Here is the fix for that:

option {
padding-right:1em;
}

I use margin, but now that I think about it padding may be better since 
it won't collapse against any other nearby margins...

Here's what I put at the top of my primary stylesheet for every site 
I'm doing recently. It models all browsers' defaults on Mozilla's 
(mostly).

/* - STANDARDIZE DEFAULTS - */
/* default whitespace 
[ref:http://leftjustified.net/journal/2004/10/19/global-ws-reset/] */
	* { padding:0; margin:0; }
	h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, 
fieldset, address { margin:1em 0; }
	input { padding: 0.08em 0; }
	option { margin-right:0.5em; }
	li, dd { margin-left:2em; }
	fieldset { padding:0.5em; }
/* /whitespace */

/* font : don't forget Win IE resize-font hack of setting by % of 16px 
*/
	body { font:11px Verdana, Arial, Helvetica, sans-serif; }
	* { font-size:1em; }
	input, select, textarea { font-size:1.18em; }
/* /font */

/* - /STANDARDIZE DEFAULTS - */

Then in my Win IE hacksheet:
body { font-size: 67%; }
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Can I use a table in a form?

2005-01-13 Thread Ben Curtis

Part of the point of using CSS for layout is it gives us the ability 
to separate the content from the presentation. Slapping a form into 
table cells doesn't allow this. It makes it much harder for instance 
to restyle the form so the labels appear above, rather than next to 
the form inputs.
I think you misunderstand the context. Changing the position of tabular 
data changes the data's meaning; position in this case is not 
presentation, but content. That's why tables are rigid in their 
placement of things.

Labels are not separate and distinct items of the tabular data, and 
should not be confined to separate tabular-data (td) fields. Labels, 
acting as meta-data when associated with tabular data, IMO should be 
placed within the same td as the data they label; to do otherwise would 
lose the meaning of the row and/or column. Because in tables, the 
placement conveys meaning.

What is important in this thread is not the tables vs no tables layout 
question; this is the same discussion as we always have whenever 
tabular or quasi-tabular data is mentioned. Refer to the archive for 
more.

What is important is the recognition that form elements are merely a 
means to mark up content such that you declare it editable in specific 
ways by the user, and the choice to present data as editable does not 
change the data's meaning. Purely interactive/declarative elements 
without content (e.g., buttons, the form tag itself) are the exception, 
and in this discussion I think they ought to be outside of the table.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Can I use a table in a form?

2005-01-13 Thread Ben Curtis
On Jan 13, 2005, at 10:01 AM, Andy Budd wrote, in part:
hairs and getting semantic, isn't all information on a website 
really just data? So why can't present it all using tables?
Because it is not *tabular* data, unlike the practicular form that 
this
discussion is all about.
Why? How can you say that a bunch of empty form elements are tabular 
data even if there isn't any data?
...
When you apply for a bank load do they give you a table of blank 
data to fill in or do they give you a form to fill in?

Table:  An orderly arrangement of data, especially one in which the 
data are arranged in columns and rows in an essentially rectangular 
form

Form:  Document with blanks for the insertion of details or information

Null values for named data fields *are* data; empty form fields contain 
data, and those data are null. They still have meaning, and the meaning 
is contained within the rows (groups) and the three columns (age range, 
# of travelers, trip cost per person). A bank form rarely includes 
tabular data; mostly, it includes a number of questions that relate to 
you, but not to each other in a columnar way. This author wanted to 
create a form that applies identically to a number of groups, not just 
a single group.

Allow me to quote the initial request:
We have a use for a table inside a form. We want to sell a group 
travel insurance product and many of the questions are simple entries 
and their may be a large number of people on a trip.
...
You have three fields to input for each group: age range, # of 
travelers, trip cost per/person. My first instinct is to put each sub 
group into a fieldset and repeat the labels and inputs.
To use fieldsets would destroy the semantic declaration of a 
relationship between groups; even though each fieldset would contain a 
field that represents the number of travelers, there would be nothing 
in the markup that declares these data as related in the same way to 
their respective group. In short, you could not pull from fieldsets the 
answer to the question Which group has the most travellers? That is 
why marking it up as a table is useful.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Popups (plus, standards-based event handling)

2005-01-13 Thread Ben Curtis

Also, while it's convenient to insert javascript event handlers into  
HTML
markup when demonstrating an example, in practice it's probably best  
to
leave the script out of the markup and apply it from a separate
script file
at window.onload.
I'm curious as to how you do that, because to my mind it's a great  
idea.
Keeping it out of the markup would make sure that the code of the page
itself remains nice and lean and would also make it easier to remove  
the
popups altogether if such a feat was necessary.

If you could elaborate on that, either on or off list, I'd really  
appreciate
it. :)
Here's a place you can start:
http://www.sitepoint.com/article/standards-compliant-world
One beef I have with this code, and most code of this nature, is that  
it uses this to trigger it:

window.onload = externalLinks;
This is fine, if it's the only code you are assigning to onload, but it  
overwrites any previous onloads and is overwritten by subsequent  
onloads. But it should use the DOM (a standard! woohoo!) when possible  
to add a handler to an event. Unfortunately, IE on Windows doesn't use  
this, and IE on Mac won't use what IE Win uses. So I've written this  
code, that you are free to use (beware of line wrap, and send support  
questions offlist):

/*
	the ondocload event is triggered by this code you place before the  
closing body tag:

script type=text/javascriptwindow.ondocload();/script
/body
	it is the event before onload that indicates the document is done  
downloading;
	after the func declaration we set two handlers to make sure events  
assigned to
	docload are triggered onload if the author forgets to put the call in  
the doc.
*/
function bv_addListener(el, evt, fn) {
	if (typeof el == string) el = document.getElementById(el);
	if (!el) return;
	if (window.addEventListener  evt != 'docload') { // DOM
		el.addEventListener(evt, fn, false); // false, because IE can't  
handle the truth
	} else if (window.attachEvent  evt != 'docload') { // MS, incl Opera
		el.attachEvent('on'+ evt, fn);
	} else { // Mac IE and the ondocload event
		var prevHandler = (typeof el['on'+ evt] == 'function') ? el['on'+  
evt] : function () {};
		el['on'+ evt] = function() { prevHandler(); fn(); }
	}
}
bv_addListener(window, 'docload', function () { window.bv_docInited =  
true; });
bv_addListener(window, 'load', function () { if (!window.bv_docInited)  
window.ondocload(); });
/* END bv_addListener */

Now, if you want a script to run when the HTML has finished downloading  
(e.g., initialization scripts), use this:

bv_addListener(window, 'docload', someFuncName);
If you want something to run onload:
bv_addListener(window, 'load', someFuncName);
If you want to add any handler (e.g., someClickHandler) to any event  
(e.g., onclick) on any element (e.g., el), use this:

bv_addListener(el, 'click', someClickHandler);
If you don't have an element object to pass, it also accepts an ID as a  
string (and a future version will accept classes -- let me know if this  
interests you); this is handy when you want to attach an event to an  
element that doesn't exist yet:

	bv_addListener(window, 'docload', function () {  
bv_addListener('someID', 'click', someClickHandler); });

The testpage for this is here:
http://www.bivia.com/sandbox/crossfade_slideshow/ 
test_bv_addListener.html
(tests will report as failed until the event is triggered -- until you  
click or mouseover)

I tested it a bunch, but would appreciate reports of other platforms  
success/failure. Once I get out from under some deadlines, I'll write  
this technique up and give it to the community.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Popups (plus, standards-based event handling)

2005-01-13 Thread Ben Curtis

Also, while it's convenient to insert javascript event handlers into
HTML
markup when demonstrating an example, in practice it's probably best
to
leave the script out of the markup and apply it from a separate
script file
at window.onload.
One beef I have with this code, and most code of this nature, is that
it uses this to trigger it:
window.onload = externalLinks;
This is fine, if it's the only code you are assigning to onload, but  
it
overwrites any previous onloads and is overwritten by subsequent
onloads.
http://www.bivia.com/sandbox/crossfade_slideshow/ 
test_bv_addListener.html

Wow, your method looks elaborate.
A bit. But you put it in a central utilities-script file, and then all  
you need to do is call it so you never need to see the elaboration.  
Instead of the DOM:

el.addEventListener('event', func, bool);
...you call a function that does the same, but cross-browser:
bv_addListener(el, 'event', func);

Another method I've imagined but never implemented is for each added  
function to add itself to an array of functions.
This is essentially how I used to do it. Each js file that housed a  
certain behavior would have this at the end:

if (!window.ToLoad) window.ToLoad = new Array();
window.ToLoad[window.ToLoad.length] = someFuncName;
window.onload = function() {
for (var xx = window.ToLoad.length -1; xx = 0; xx--) {
window.ToLoad[xx]();
}
}
It's efficient. Your imagination is  should try it. Notice that it uses  
FILO ordering of the handlers (that's First In, Last Out, or reverse  
order from being added).

The advantage to my other code is that it adds any event handler to any  
event on any object. So, in this case, the same code could be used to  
cue the init script, and the init script could use it to add the  
onclick handlers.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] How to create a mark-up guide?

2005-01-07 Thread Ben Curtis

And all that Malarkey 
http://www.stuffandnonsense.co.uk/archives/css_markup_guides.html
has a recent post about how he creates sites with black and white 
drawings and adds the div id's etc after the client has approved...
This made me think that I should go back to our re-designed web site 
and create a similar sketch.
My first thought was add:

div {border:1px solid #000 !important; margin: 2px !important;}
to the style sheet to show the divs. Then I was wondering if there is 
a css2 method to show the id or class within the div?

div {
border:1px solid #000 !important;
margin:1.25em !important;
padding:0.25em !important;
}
div[class]:before {
content: class= attr(class);
color:#900;
font-weight:bold;
}
div[id]:after {
content: id= attr(id);
color:#090;
font-weight:bold;
}
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Slightly OT... Interview with IE Dev team

2005-01-05 Thread Ben Curtis

After being instigated by Channel9 
(http://channel9.msdn.com/ShowPost.aspx?PostID=34005 (And I'm W3bbo, 
btw)) I managed to get through to one of Microsoft's PR 
interview-arrangers people.

I was wondering if any of you have any specific questions, queries, or 
comments regarding the development of IE, and more specifically, IE7 
which may, or may not, come with Longhorn (before... if we're lucky)

Naturally they want to develop a better product, and to better render 
many sites out there that already exist they will need to become more 
standards compliant. If I accept that as a given, then I have one major 
concern:

Will Microsoft put significant effort into *not* fixing the parsing 
bugs that CSS authors have been using to fix the current IE CSS models, 
unless and until they fix those models as well?

In short, will they test their new browser to make sure sites that are 
hacked for IE5-6 don't break in IE7 -- because either no fixes are 
needed or the same fixes work? And if they cannot do this 100%, will 
they offer and publish solutions to our real backwards-compatibility 
issues at least 3 months before the release of IE7?

This requires that Microsoft recognize the common practices used to fix 
rendering in their previous browsers, and work with those practices.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Slightly OT... Interview with IE Dev team

2005-01-05 Thread Ben Curtis

Naturally they want to develop a better product,
Oh really? That's a laugh. All Microsoft is interested in is sticking 
a very
large hose directly into your wallet to suck as much cash out as 
possible.
This is the 8000-pound gorilla who believes in web standards as long as
those standards are theirs. In fact, that's the corporate philosophy 
across
the board and now they're heading into your living room! Can't wait to 
see
what havoc they reek there.

As the other posts have said, they've had ample opportunity and time 
to get
things right, where are we now? Hacks and java scripts...

Well, I did not say that naturally they will adopt W3C standards, but 
that naturally they want to develop a better product. Yes, better as 
defined by them. However, better as they define it is capable of 
maintaining greater than 70% market penetration, and they are losing 
market penetration because:

1. IE's ActiveX and Javascript holes allow for spyware and other 
malware, and people know it, and people are more savvy about it now.

2. The hearts and minds of developers are lost, and (over time) with 
that goes all the benefits of declaring the de-facto standard: if 
developers develop to other browsers first, and then adapt it to work 
in IE (becoming more of the case each month), then sites will work 
better in other browsers. To win back the hearts and minds of 
developers, they need to adopt standards.

They will also extend standards in a way that breaks future 
compatibility with standards so that they can get stuff developed now 
that is wiz-bang, and tomorrow developers and users will have to choose 
again whether those IE extensions are good or bad.

So, I think it's a given that the answer to the question Will you 
adhere to all recommended W3C standards for XHTML and CSS? will be 
Yes. If you know the answer to the question, there is no point in 
asking except to vent your frustration.

I wanted to ask a question I did not know the answer to: Will you make 
sure not to break existing sites that are coded in a messed up way, but 
a way that you are responsible for requiring?

I don't know the answer. If they say no, then I will change my coding 
habits to easily banish IE7 from my CSS hacks and add IE7-specific 
hacks without changing every page on my site. If they say yes, then I 
will continue to code as if IE7 will render it like Firefox, or will 
recognize the hacks for IE6.

And maybe they never thought of that and they answer yes, in which 
case the question just saved you a bunch of work, no?

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Search Engines/Spiders and SSIs

2005-01-04 Thread Ben Curtis

On search engines like Google there will be an adverse effect on
optimization when using coldfusion.  Remember Google is a
Hypertextual Web Search Engine
http://www-db.stanford.edu/~backrub/google.html
I was ignoring this thread as off-topic, but this brings up an on-topic 
point.

ColdFusion outputs html. As does PHP, JSP, ASP, shtml, and all the 
rest. Google and other search engines do not look at the file 
extension, but at the MIME-type that is delivered; ColdFusion is sent 
as text/html.

The reason they watch the MIME-type is that those are standardized, 
whereas file extensions are merely conventions. I could serve all my 
pages as .jpg and my images as .txt, and only a couple foolish browsers 
would have a problem (you are free to guess which).

In fact, I serve all my ColdFusion pages as .html because I migrated a 
static site to ColdFusion and it was easier to tell Apache to send 
.html file to ColdFusion than to change all the extensions and links.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] List decision tree [was: Gallery markup]

2005-01-04 Thread Ben Curtis

Tables wouldn't do this. Also, lists are just easier for me to use 
than tables, and tables create more code weight than do lists. 
Anybody have thoughts on this?
Well, for me, the deciding factor on using a table is if the 
elements contained in the table are 2 dimensional.
I agree with you, however for the sake of completeness let me add 
that two-dimensionality doesn't mandate tables per se.  A definition 
list is also two-dimensional -- N rows by N columns, with the 
structural peculiarity that first column is DT (inline) and the 
subsequent 1-N columns are DDs (block), structurally resembling a 
table in which the first cell of each row is a TH.
Very good catch, Paul.  I agree with you completely.  I guess I was so 
bent on pointing out that if the group of elements fails the test that 
it is not a table.  However, I did forget that other groups of 
elements may meet the two-dimensional status (such as definition 
lists as you point out) and are also not a table.  Almost sounds like 
we need to put together a decision tree :)

Re: decision tree.
I'd love to help with this.
One contribution (that may be off-base): definition lists are 
two-dimensional, but only with two columns and unlimited rows. This 
is because the dt's are all related (the are all terms), but the first 
dd of each block is no more related than any random dd from each block 
-- dd's are unordered, and so all the group of all dd's in a block are 
related to all dd's in another block as definition data.

My decision tree revolves around what relationships matter and have 
meaning. This is sort of what I go through:

Do otherwise separate-but-similar items gain meaning in a group? 
Consider a list.

	Are all items equivalent, and only relate to the group? Consider an 
unordered list.

	Are all items equivalent, and they all relate back to a single thing? 
Consider a definition list with a single definition term.

	Is there meaning contained in the order in which the items are listed? 
Does the meaning change if the order changes? Consider an ordered list.

If you have more than one list, and the lists relate to each other in 
some manner, consider nesting lists such that the relationship is 
represented by a list as per the above choices.

	Are all list groups equivalent, and each is a definition list? 
Consider making a single definition list with multiple terms.

	Are you considering ordered lists nested within an ordered list? Is 
there a relationship between items at the same depth but of different 
lists? Consider instead using a table and represent this meaning as 
rows and columns.

--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] FOUC in Safari was Slow loading of CSS

2005-01-03 Thread Ben Curtis

On Jan 3, 2005, at 8:43 AM, Lea de Groot wrote:
On Mon, 3 Jan 2005 14:20:02 +0100, Roger Johansson wrote:
Safari? I use it all the time, 10-15 hours a day, and I can't
remember ever seeing a FOUC in Safari. Could it be that it only
happens in the very first versions? I didn't use Safari full time
until late 2003, when Mac OS X 10.3 and Safari 1.1 were released, so
I may not have paid attention to any FOUC going on in releases before
that.
Hmmm, interesting - I'm running Panther, so I'm not running an early
version - 1.2.4 (v125.12)
Anyone else running Safari seeing this?
(I had assumed it was a general problem, not just me!)
Yes, I mentioned seeing it in my post a few days ago...
http://www.mail-archive.com/wsg%40webstandardsgroup.org/msg12581.html
Regarding the documents at:
http://itgtradingcards.bivia.com
I tested that some more and found that I could not reproduce it at 
will, nor did the FOUC solutions for IE work. Clearing the cache before 
viewing the page always *prevented* the FOUC (I though it would do the 
opposite), but it seemed to happen more when developing (downloading 
fresh stuff) than when viewing (seeing cached stuff). It never happened 
on my live server (so the above link won't show it), and occasionally 
happened on my development server, even though a traffic analysis shows 
they deliver nearly identical headers (the versions of PHP and Apache 
are slightly off) and content for all documents. I use a link tag to 
call a css doc with @import commands in it; the styles that are not 
there during the FOUC are in the imported sheets.

Possible causes I haven't fully tracked down:
- maybe caused when the HTML is cached but the CSS is new (I have 
tested by touching the css doc to change the last-modified date, but it 
did not cause the FOUC)

- the development server is on the same computer as Safari; therefore 
the HTML may be delivered incredibly fast, or the resources Safari was 
using to render the HTML slowed the delivery of the CSS, or something 
like that.

- I haven't tested whether this is due to the @import stuff
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


[WSG] Semantic Sanity Check

2004-12-30 Thread Ben Curtis
I'd like some insight as I compose instructional materials on something 
I'm learning myself. I have a philosophy/strategy statement, and sample 
pages I will pull code samples from. I'd like any feedback you wish on 
both or either.

I lead a couple teams of coders and designers. Primarily, they make 
sites with mixed tables and CSS rules. I'd like to introduce them to 
the ideas I've encountered in this group, where the XHTML can be 
semantically marked up to describe what it is, and then styles describe 
how it looks based on what it is.

Before I create code samples for them to gnaw on, I want to run the 
basic ideas past the thoughtful folks in this group.

http://www.bivia.com/sandbox/semantic_markup/
I hope to introduce them to these ideas:
- habitually validating documents
- defining classes and ID-selected styles based on what a thing is 
(thinking less about presentation)
- using h# tags instead of spans and styles
- restyling lists
- choosing when an image is content and should be in an img tag, or 
presentational and might be better as a background-image

These are smart people I'm working with, but they think solely about 
presentation. I'm looking to push them on just the right concepts. Did 
I miss any? Am I off base on some?

The companion pages where I worked out these concepts are here:
http://itgtradingcards.bivia.com/
http://itgtradingcards.bivia.com/page2.html
They validate as XHTML1.1, and the CSS hacks that would not validate 
are imported using @import code that the validator ignores -- so the 
CSS clears, and the browsers still are ok. I viewed them both at 
various default font sizes, and we target full design realization in 
these browsers:

Win XP: IE6, Firefox 1/Gecko, Opera 7.5
Win 98: IE5, IE5.5, IE6, Firefox 1/Gecko, Opera 7.5
MacOSX: IE5.2, Safari 1.2, Firefox 1/Gecko
MacOS9: IE5.2
Minor design bugs are allowed in IE5 (Win/Mac). The style-less display 
should be just as usable, although we don't put any effort into 
un-styling things for bad browsers. For style-less review, we test in 
Lynx and Firefox (Web Developer - disable CSS).

Some concerns I have (besides the designer insisting on images in the 
navbar):

- the method of importing the styles (causes a FOUC in Safari?)
- navigation code last, with a skip to link
- proper use of dl for the Events listing
- why I can't get the footer hr to display the same in Win IE as other 
browsers

Thanks for any tips.
--
   Ben Curtis : webwright
   bivia : a personal web studio
   http://www.bivia.com/
   v : 818 507 6613

**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


  1   2   >