Re: [WSG] Targeting specific images with overflow:hidden

[Paul Novitski]

At 2/2/2007 05:44 PM, Cole Kuryakin wrote:

What I want to do is target any "img" within the site

img {

...

overflow:hidden;
}

with overflow:hidden - but for some reason, it's not working.



Overflow applies to the contents of a block, not to the block 
itself.  img{overflow:hidden} would make sense only if an image could 
have content, e.g.:



   


but that's not HTML.

See:

CSS 2.1 Specification
11 Visual effects
11.1 Overflow and clipping
http://www.w3.org/TR/CSS21/visufx.html#overflow-clipping

Regards,

Paul
__

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Creating link arrows/icons in css

[Paul Novitski]

At 1/31/2007 03:39 PM, Jason Bayly wrote:
Thanks that works a treat across both major browsers.. Following on 
from this, is there a way (that u can think of) that would prevent 
the icon becoming an orphan on a new line? It would visually look 
better if when wrapping to a new line that the icon forced the last 
word to be wrapped with it and not end all be its lonesome on the new line.


http://www.newgency.com/test/css_temp.htm



You could always enclose the last word of the link text and the icon 
(regardless of which markup is used to tie in the icon) together in a 
span with {white-space: nowrap;}.


Again this is markup added expressly for the purpose of a particular 
presentation, but at least it's semantically inert.


Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Creating link arrows/icons in css

[Paul Novitski]

At 1/31/2007 10:15 AM, Dan Dorman wrote:

On 1/31/07, Paul Novitski <[EMAIL PROTECTED]> wrote:

This is a very very ... very long link

[snipped]

 is deplorably extraneous in the markup, but at least
it's semantically transparent.


Since a background image in the parent  won't render properly in
IE, I'm not sure I understand why a superfluous empty  is
semantically superior to a superfluous  properly attributed.



This page demonstrates that the background image will render properly 
in IE 6 as well as Firefox 2:

http://juniperwebcraft.com/test/test_anchoricon.html

I hear your argument and I can't really disagree with it.  I don't 
think the empty span is superior.  About the highest compliment I can 
pay it is that it's semantically neutral or transparent and thus 
causes no harm to the semantic content of the document.


But is the link icon content or decor?  That's usually how I decide 
whether to make images foreground or background.  In this particular 
case I see the image as cosmetic dressing for the hyperlink and not a 
piece of content that's interesting or valuable unto itself.  I 
imagine the image will be reported by a screen-reader (IFF it's got a 
non-blank alt?) but the span won't.


I don't see a strong right or wrong way on this issue.  Either way 
we're adding about the same amount of extra gunk to the markup merely 
to support an image that we really want to depend from the simple 
anchor markup itself.


Regards,

Paul
__

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Creating link arrows/icons in css

[Paul Novitski]

At 1/30/2007 05:50 PM, Jason Bayly wrote:

Thanks Paul,

I've implemented what you suggest..
http://www.newgency.com/test/css_temp.htm

The css technique doesn't seem to work too well.

I also have a non css example of what I'm trying to achieve. If you 
resize the browser window so that the link wraps, you will see the end result.


Any thoughts on a nice css based solution?



Oops, sorry, forgot to test in Explorer.

So here's a solution that does work in both Firefox and Explorer:
_

This is a very very ... very long link

a span
{
padding: 0 8px;
background: url("folder.gif") right center no-repeat;
height: 1%;
}
_

The 8px horizontal padding makes room for a 16px-wide image.

 is deplorably extraneous in the markup, but at least 
it's semantically transparent.


height: 1%; is a harmless hack to force Explorer to give the span 
"layout," without which it's necessary to insert a space inside the span.


Regards,

Paul
__

Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Creating link arrows/icons in css

[Paul Novitski]

At 1/30/2007 03:26 PM, Jason Bayly wrote:
Has anyone got any examples or techniques to add 
an icon/image to the right of an anchor tag, 
specifically when the text wraps to a second 
line. Google doesn’t want to help today….



You can apply a padding-right to your anchor and 
a background-image in that space.


a.with-icon
{
padding-right: 20px;/* a few pixels wider than the image */
background: url("icon.gif") right center no-repeat;
}

I suggest background-position: right center; to 
keep the icon vertically centered as font-size expands.


Regards,

Paul
__

Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Styling a Code Listing

[Paul Novitski]

At 1/25/2007 08:12 AM, Thierry Koblentz wrote:

http://www.tjkdesign.com/articles/how_to_style_a_code_listing.asp



You say, "With images off, the numbering would disappear because of 
lack of contrast between foreground and background color."


This problem wouldn't exist if you simply chose the foreground & 
background (image) colors more wisely.  Pick a text color that works 
with or without the background -- either a mid-gray text that shows 
up well on both white and dark gutter, or a dark text that shows up 
well on both white and a pale gutter.


Consider also that the gutter, instead of having a background color 
at all, could simply be separated from the body of the listing with a 
vertical rule.

__

If I may stray topiclogically, I've never been able to figure out why 
this style of bracketing has become standard and apparently so well-loved:


label {
contents
}

I much prefer:

label
{
contents
}

which appeals to my sense of order and symmetry.  The label, be it an 
if-test or CSS selector, is on a line by itself, and both brackets 
lie in the same column, making the whole structure much easier for me 
to proofread and eyeball-search.


Suffice it to say that if I were to use a tool or script that 
pretty-printed CSS I'd want the option to place a carriage return 
before the opening bracket as well.  (And ensure a space after the 
colons in CSS rules.)  (And brew me a fair-trade espresso.)


Regards,

Paul
__

Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Legitimate uses of and

[Paul Novitski]

At 1/16/2007 08:55 AM, Andrew Ingram wrote:
I know these tags are only supposed to be used for presentational 
rather than semantic emphasis, but i've been struggling to come up 
with examples of when they would be used.


The only situation I can think of when there is an established 
visual standard for certain things that don't really have a semantic emphasis.


For example, when listing somebody's academic qualifications the 
standard is to display the institution in italics but i'd say that 
it's not appropriate to use .


A. Ingram, MEng Warw

Does anyone know of any other legitimate uses of these tags?



Andrew,

I differ with your assertion that the institution names in your 
documents don't have semantic emphasis.  It's precisely because of 
the semantic singularity of institution names that leads you to 
italicize them in the first place.


A strong argument against using such presentational elements as  
and  in markup is that thenceforth the markup, not the stylesheet, 
determines exactly how the information will be presented; you've lost 
some of the beauty and functionality of that separation we strive 
for, but without gaining anything significant from the sacrifice.


When you or your organization eventually changes this decision of how 
institution names (and potentially other terms) will be presented in 
the websites you've marked up, the then-current webmeisters will be 
faced with three unhappy choices:


- Replace selected  tags in the markup.  That's stupid manual work 
for overly qualified workers, resisted and economically 
prohibitive.  If you've used  for other terms in addition to 
institutions, a global replacement won't likely suffice.


- Not change the styling because it's too much work, sacrificing 
presentational goals that would otherwise be easy to meet.


- Apply non-italic styling to the italic tag.  This essentially means 
using the  tag to mean  which might not be practical 
if by then you've gone over to the dark side and have used  to 
mark up other types of text that you wish (today) to be 
italicized.  I feel uncomfortable with that kind of semantic 
re-purposing of HTML because it separates your markup from the public 
body of convention that gives our markup meaning in the first 
place.  Until we mark up our documents in pure XML I believe the 
smarter course is something along the lines of class="institution">.  That's future-friendly --  only does it make 
for flexible styling but also it indicates the semantic purpose of 
the text fragments in question, making your documents more machine-readable.


I find the argument that classed spans are 'too heavy' to be 
specious.  Disk space and bandwidth continue to grow and get cheaper; 
let's not sacrifice the meaning of our documents to either the 
almighty penny or the almighty millisecond.


Regards,

Paul
__

Juniper Webcraft Ltd.
http://juniperwebcraft.com  




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Shadows on a div?

[Paul Novitski]

At 1/13/2007 09:49 AM, Paul Novitski wrote:
Aside, when does a shadow fall on both sides of an object?  The 
answer is when the light source is between the observer and the 
object casting the shadow.  (If the light source were off to one 
side, the shadow would be on only one side; if the light source were 
behind the observer the shadows wouldn't be visible to the 
observer.)  Shadows on both sides constitute a fairly unusual 
circumstance in real life.  If your client were happy with a more 
realistic drop-shadow on one or two sides of the box, perhaps your 
problem would be easier to implement. ...


Of course I should have typed, "...a more realistic drop-shadow on 
only one side of the box"


Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Shadows on a div?

[Paul Novitski]

At 1/13/2007 05:10 AM, Tom Roper wrote:
The problem I've got a the minute is I've built a page for a client, 
but now she would like shadow on either side of the page

http://www.flickr.com/photos/tom_r07/355733167/


I don't see that this problem requires transparency at all.  Just 
create two tall skinny images that run down the sides of your main 
container that contain your drop-shadow on a vertical slice of your 
background pattern.


In order for this to work, your content block has to be in a fixed 
relationship to the background pattern so that the vertical slices of 
background with the drop-shadow will match up with the true 
background.  Because your content block is centered, you might think 
at first that you wouldn't be able to predict where the content block 
will intersect with the background pattern, but it turns out to be 
quite easy: just center the repeating background image.



Aside, when does a shadow fall on both sides of an object?  The 
answer is when the light source is between the observer and the 
object casting the shadow.  (If the light source were off to one 
side, the shadow would be on only one side; if the light source were 
behind the observer the shadows wouldn't be visible to the 
observer.)  Shadows on both sides constitute a fairly unusual 
circumstance in real life.  If your client were happy with a more 
realistic drop-shadow on one or two sides of the box, perhaps your 
problem would be easier to implement.  Or is the goal to create a 
'glow' and not a shadow per se?



At 1/13/2007 06:40 AM, Mihael Zadravec wrote:
One option would be a use of png image for shadows... but as they 
are not supported by all browsers (like IE6 of corse..) that would 
not be the best solution.


I beg to differ: PNG images are supported by IE6.  You just have to 
use Microsoft's proprietary triggers (e.g. filter: in the 
stylesheet).  There are dozens of essays on this subject locatable 
through Google; here are just a couple:


Microsoft:
http://msdn.microsoft.com/workshop/author/filter/reference/filters/alphaimageloader.asp

CSS-D wiki:
http://css-discuss.incutio.com/?page=AlphaBetaPngSupport

Ingo Chao:
http://www.satzansatz.de/cssd/tmp/alphatransparency.html


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] my world, my country.. :(

[Paul Novitski]

At 1/9/2007 10:15 AM, Mihael Zadravec wrote:
This is realy sad... but this is the website of 
a Blind peopele comunnity Škofja Loka from 
Slovenija (where I live, but in Ljubljana...)


Center slepih in slabovidnih Škofja Loka
http://www.css-sl.si/

any comments on the code, usabillity and accessability issues?



I don't have a screen-reader and can't determine 
whether the Flash application is in any way 
accessible, but on the surface the home page is 
wholly INaccessible as it doesn't contain any 
text or even any link to text.  The sub-pages I 
looked at are frame-based and table-based which 
also present accessibility issues.


It surprises me that anyone would design a 
website for a blind community that can't be 
easily read by blind people.  Now *that* is sad.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Image markup clarification

[Paul Novitski]

At 1/8/2007 11:23 AM, Robin @ Xplore.net wrote:
Could someone please clarify for me the best way to markup an image 
in a template, take a header image for example. In the interest of 
keeping structure from content I have recently been using background 
images wherever possible to keep my markup as clean as possible but 
I have been reading an article on the importance of the alt text for SEO.

Is there a definitive answer?
I want the best search engine rankings but I also want clean markup.



Background images, not being IMG elements, can't have ALT attributes, 
so that part's easy.  If you've decided that an image is truly decor 
and doesn't need to be a foreground image, it also doesn't need (and 
can't have) alt text.


Determining which images are decor and which are truly content can be 
difficult at times as there can be lots of grey area.  One could 
argue that if the image is not necessary to understanding the page 
content, it's decor.  It helps if you turn images off in your browser 
and see if the integrity of the page suffers as a result.


The correct markup will depend on whether you're using HTML or 
XHTML.  For XHTML it's:




Other attributes are available; see:

HTML 4.01 Specification
13 Objects, Images, and Applets
13.2 Including an image: the IMG element
http://www.w3.org/TR/html4/struct/objects.html#edef-IMG

Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ul indent in non-ie

[Paul Novitski]

At 1/5/2007 04:10 PM, Kevin McMonagle wrote:
what is it that makes non ie browsers put an indent of some kind on 
a vertical unordered navigation list?

i ve cleared all the padding and margins. seems to be about 35 pixels.
heres an example-still rough dont slag me for anything else on the page.
http://208.106.200.54/



After a quick look at your CSS, I don't see that you're clearing the 
padding on the UL element, just the LIs.


Every browser has a default stylesheet that determines, for example, 
that head elements don't display.  Many of us "zero out" or "reset" 
style defaults at the beginning of a stylesheet to bring browsers to 
the same starting line.  You can google [css global reset] and find a 
lot of resources such as 
http://leftjustified.net/journal/2004/10/19/global-ws-reset/  It's 
worth mentioning that some folks object to clearing padding globally, 
as they feel it adversely affects form buttons, but clearing padding 
for lists specifically seems harmless enough.


Always, the CSS-D wiki is your friend: http://css-discuss.incutio.com/

Regards,

Paul Novitski
__

Juniper Webcraft Ltd.
http://juniperwebcraft.com



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] HEC - Your Thoughts?

[Paul Novitski]

At 1/5/2007 04:33 AM, Svip wrote:

I discovered that anyone have yet to discuss HEC's.  So I thought I
might as well start this topic.  HEC stands for "HTML Encoded
CAPTCHA".  It's quite easy, it is using means of HTML and CSS to
create the image which was originally broadcasted in png/jpeg/gif or
perhaps even svg.

It is just about being creative.  I know what you're thinking.
Usually you would at maximum send 3 bytes per pixel, but now weren't
going to send like fifty time as much!  Yes, it is a waste of traffic,
but it has a large security scale I should imagine.

Anyway, here is a HEC, I created:
http://sviip.dk/tut/captcha.php



With respect, Svip, I think this is a terrible example of the 
technique you're demonstrating.  There's no reason for all the 
repetitive inline styling when a few rules in a stylesheet and a few 
unique class names would suffice.  You could reduce the weight of 
this glob of markup to a sliver of its current size.


And as long as you're using PHP's image functions, why not generate a 
complete single image server-side and deliver it whole to the client?


If you're going to settle for a captcha that's inaccessible to 
non-visual users -- which I think is a bad idea -- here's another 
approach:  output a string a characters, each in its own span, 
absolutely positioned to appear in a different sequence than the 
source markup.  In this simple model the characters themselves aren't 
obfuscated, merely their sequence.  The probability of guessing the 
correct sequence is fairly small -- the number of possible 
combinations is N! (N factorial), i.e. 120 for five characters, 720 
for six, 5040 for seven.  It's much less likely that a bot would 
choose the right combination than, say, select the correct item from 
a list of five options.  It is, however, another inaccessible 
technique.  We can do better.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] #div > #div

[Paul Novitski]

At 12/27/2006 06:47 PM, Helmut Granda wrote:

#id > #id

...

Does anyone has any information on why is ">" being used?



Read this:

W3C CSS 2.1 Specification
5 Selectors
5.6 Child selectors
http://www.w3.org/TR/CSS21/selector.html#child-selectors

By the way, I don't know if your example was symbolic or literal, but 
you should know that an id should be used only once on a page, so for example:






violates the spec:

7. The global structure of an HTML document - The HEAD and BODY of a document
7.5. The document body
7.5.2. Element identifiers: the id and class attributes
http://www.w3.org/TR/html4/struct/global.html#adef-id

"id = name [CS]
"This attribute assigns a name to an element. This name must be 
unique in a document."


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Multi language web sites

[Paul Novitski]

At 12/19/2006 07:03 AM, Kepler Gelotte wrote:

I had a question about creating multi-language web sites and best practices.
Is it better to create two separate directories with the pages and images
duplicated for each language, or is it best to try a database solution using
meta tags that will be replaced on the server depending on the language
selected? Maybe there is another approach all together?

I would think the database solution would be more flexible but could get out
of hand quickly just with the number of meta tags required. The web site I
am concerned about has to support 2 languages only (French/English).



The decision whether to generate web content from a database is often 
driven by the efficiency of doing so for middlin' to large 
applications.  However, once you build a good method for supplying 
multilingual content, it's there for you to use on even small jobs.


Here are two bilingual sites I've built using somewhat different techniques:

Partcon (English/French site)
http://partcon.ca/

With Partcon, the English & French are in separate records in the 
MySQL database.  I set a language field in the database table with 
(in this case) three possible values, "-", "EN", and "FR".  The 
hyphen stands for 'any language' and is used to output content that 
isn't language-dependent such as image src and anchor 
href.  Therefore I can select records:

WHERE lang='-' OR lang='$sSelectedLanguage'
and the Boolean overlap of recordsets works just fine.  When the user 
changes the language selection, a new page view is pulled down from 
the server with the requested language records plugged in.



Laurie Toby Edison - Women of Japan - The Models' Words 
(English/Japanese pages)

http://laurietobyedison.com/WOJwords.asp

With Laurie Edison's Women of Japan pages, both the English and the 
Japanese texts are present on every page of mark-up.  Which language 
is currently displayed depends on the body class ('langEN' or 
'langJP').  Each language-specific block of text, whether a single 
span or a div containing multiple paragraphs, is given a language 
code so that CSS can display or hide text selectively:


/* make English invisible on Japanese pages and vice versa */
body.langEN .langJP,
body.langJP .langEN
{
position: absolute;
left: -1000em;
}

With JavaScript disabled, changing language pulls down the same page 
from the server but with the body class reset.  With JavaScript 
enabled, the body class is changed immediately and no server 
round-trip is required.  Obviously this solution depends on a 
relatively limited amount of text on the page and/or a limited number 
of languages if you want to keep page size down.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie-only hack

[Paul Novitski]

At 12/18/2006 01:58 AM, Barney Carroll wrote:

Geoff Pack wrote:

Gunlaug Sørtun wrote:
So, old hacks like the 'star html' hack for 
IE6 (and older versions) is now "perfectly 
valid" IMO, while hacks relying on bugs that 
have survived into IE7, are extremely unsafe.
'extremely unsafe'? I'd say they are safe until 
Microsoft releases another IE version. With 
their track record, that could be *years*.
Given the choice between littering my html 
(thousands of pages) with conditional comments, 
or adding couple of hacks to a single CSS file, 
I'll take the hacks, thank you very much.
Despite all the doomsayers, I had zero problems 
with pages breaking when IE7 came out.

cheers
Geoff.


I agree with this. If we're going for zen 
purity, I agree that theoretically hacks could be a liability.


But seriously, how many years have you been 
telling yourself the star hack is unsafe? What 
did that lack of safety ever mean?


Same as it means now -- the likelihood that 
someday your code will fail because it depends on 
the coincidence of two unrelated bugs in an evolving software product.



Lack of support for multiple classes can hardly 
be called a 'bug' at this point. It's more like a 'feature'.


Only if you accept Microsoft's bugs as standards in preference to the W3C spec.


It's slightly arrogant to believe that you can 
exploit a program's invisible weaknesses to 
cover its visible others; but it's more naive to 
believe that Microsoft would tackle hacks like 
this. Seriously - if you're going to ascribe 
IE's dev team the virtue of wanting to tackle 
IE's problems, you'd think their priority list 
would start with rendering flaws and end with 
"let's see how css coders are fixing our browser and screw it up for them".


Given their recent work on IE7, I don't think 
it's too naive to ascribe to them a desire to fix 
their software to match the spec:

__

To match a subset of "class" values, each value must be preceded by a ".".

Example(s):

For example, the following rule matches any P 
element whose "class" attribute has been assigned 
a list of space-separated values that includes "pastoral" and "marine":


p.marine.pastoral { color: green }

This rule matches when class="pastoral blue aqua 
marine" but does not match for class="pastoral blue".


http://www.w3.org/TR/CSS21/selector.html#class-html
__

Lack of support for multiple classes can hardly 
be called a 'feature' at this point.  It's more like a 'bug'.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie-only hack

[Paul Novitski]

At 12/17/2006 01:17 PM, Thierry Koblentz wrote:

David Dorward wrote:
> On Sat, Dec 16, 2006 at 09:48:58PM -0800, Paul Novitski wrote:

>> I believe the reason it's an ie-only hack is that standards-compliant
>> browers won't apply the selector .ie-only.foo to any element because
>> no element has both classes ie-only and foo

> 
>   This element has both classes
> 

That's the way I saw it at first too, but in fact there would be no
"ie-only" class plugged anywhere in the markup.
It'd only appear in the styles sheet. I think it's a rather smart hack...
BTW, do we know if it works in IE Mac too?



Clever as it is, this hack is mis-named -- it should be:

.browsers-that-dont-support-multiple-class-selectors.foo {...}

It stops being "ie-only" as soon as Microsoft fixes this particular 
bug without fixing others.The reason it's a "hack" is that it 
doesn't actually address the problem directly -- the problem being 
IE's box model or whatever other IE bug you're working around with 
this selector.  It's highly unlikely that this multiple-class 
selector hack will ever be used to address the problem of IE not 
supporting multiple-class selectors, which is the only context in 
which it could be considered good engineering.


I'm with Rob -- use conditional comments if you don't want your hack 
to break one or two browser versions from now.It know it seems 
like tomorrow will never come, but it will, and when it does (as is 
happening even now with IE7) hacks will fail.  If you don't think the 
web pages you're creating today will still be here in five years, look around.


I am, by the way, the pot criticizing the kettle's soot -- I'm still 
weaning myself off * html selectors.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie-only hack

[Paul Novitski]

At 12/15/2006 09:14 AM, Rafael Mumme wrote:

.foo { background:red;width:100px;height:100px; }
.ie-only.foo { background:blue; }


At 12/15/2006 11:08 AM, Thierry Koblentz wrote:

Actually, unless I'm missing something, it should be ".non-ie"



I believe the reason it's an ie-only hack is that standards-compliant 
browers won't apply the selector .ie-only.foo to any element because 
no element has both classes ie-only and foo, while IE will apply it 
to any element with the class foo because it sees only the final 
class of a multiple-class selector.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] The Decline of Print Styles

[Paul Novitski]

At 12/2/2006 09:15 PM, Jesse Rodgers wrote:
...
a lot of internal folks had a hard time figuring out why what was on 
the screen was not what was coming out of their printer. Some people 
got really upset. They don't mind the click to a print version but 
the auto-format on print just freaks some people out.


I think print styles aren't as common because it is just not what 
people seem to want, they want to print what they see on the screen 
exactly as it appears.



My optimistic hope is that this kind of WYSINWYG shock is transitory, 
and after a while people will become accustomed to print styles 
differing from screen styles as more and more developers learn to 
style for print.


For example, the people referenced above, having once experienced the 
bee-zarre screen<>print phenomenon, will take it more in stride the 
next time it comes along and will be more likely to say, "Oh, yeah, 
I've seen that," rather than exclaim, "WTF!"


Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Vertical borders between inconsistent height divs

[Paul Novitski]

At 11/27/2006 02:25 PM, Nick Roper wrote:
I have a 3 column layout and want to display a vertical border 
between the columns. The problem is that the relative heights of the 
columns can change depending on how much content is in each at any 
time. I want the borders to always extend for the height of the 
currently tallest column, and for both borders to be the same height.


See http://dev.logical.co.uk/test/vertical_borders.html



This sounds like it could be a simple variation on equal height faux columns.
http://css-discuss.incutio.com/?page=AnyColumnLongest

Since your columns are fixed widths, you can create your borders as a 
single vertically-repeating background image applied to the container 
for all three columns.  In your markup you don't have such a 
container except the body element itself; if you need to accommodate 
further content on the page, wrap the three columns in a div and go from there.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] BG images in links

[Paul Novitski]

At 11/15/2006 03:43 PM, Nick Roper wrote:
I tried creating a new image file for the third link 
'home-administration.jpg'. This comprises both black & white and 
colour versions of the image next to each other, with the CSS 
changing the position when the link is hovered over. The page loads 
OK in IE, but when hovering over the last link for the first time, 
the whole link & image shifts vertically. It then remains in the 
same position subsequently.


See: http://dev.logical.co.uk/test/imglinktest.html

Any suggestions?



I'm sorry I'm in mid-deadline and can't research this properly, but 
very briefly I wonder if it might be related to IE's sanity-straining 
shift on hover, as described here:


Quirky Percentages in IE6's Visual Formatting Model
by Ingo Chao
http://www.positioniseverything.net/explorer/percentages.html

Why would setting and/or changing the background-position on hover 
would trigger this phenomenon?  I suspect it relates to the fact that 
you're making your list items inline even while they contain anchors 
made block:


#serviceNav ul li{
  display : inline;   /* Kludge to fix gaps between 
lines in IE/Win */

}

#serviceNav ul li a{
  display : block;
...

Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] BG images in links

[Paul Novitski]

Paul Novitski wrote:
> 2) Preload the hover-state images

...

At 11/15/2006 01:17 PM, Thierry Koblentz wrote:

4) Use CSS:
a:link,a:visited {background:url(up_image.gif) no-repeat 0
50%;background-image:url(down_image.gif)}
a:hover,a:active,a:focus {background-image:url(up_image.gif)}



Thanks, Thierry, that's very cool, I'll give it a try.  I didn't know 
that referencing two background images for the same selector in this 
way would download both of them.  (Do you recall if you stumbled on 
this yourself or got the idea from someone else?)


I still lean toward using a single composite background image and 
changing background-position on hover because of the lesser download 
weight, but I'll add this technique to my bag o' tricks.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] BG images in links

[Paul Novitski]

At 11/15/2006 09:23 AM, Nick Roper wrote:
I want a list menu that uses both text and images for the links. On 
hover the bg images should swap from b/w to colour versions, and the 
text colour should change.

...

See: http://dev.logical.co.uk/test/imglinktest.html



Now that you've got your IE hover problem fixed, I'd like to suggest 
that you consider rejigging your menu for faster response time.


The way you've got it set up now, your hover images are downloaded 
only when the first hover event occurs, creating an awkward delay in 
the user interface.  I can suggest a few ways to speed this up:


1) Include the normal and hover-state images in the same image file, 
and change the background-position on hover.  This technique was 
described in this article:


CSS Sprites: Image Slicing's Kiss of Death
by Dave Shea
http://alistapart.com/articles/sprites/

and amplified elsewhere on the web (google 'css sprites').

You could have one image for each menu item, each containing the 
normal and hover-state image; or you could have one image for your 
entire menu containing all the normal states and all the hover states together.


At first it might seem actually slower to combine several images in 
the same file, but that depends on your perspective.  Because each 
image file has a header, two separate images will tend to weigh more 
than one image file containing both.  Also, similar images can 
benefit from the same compression algorithm.  During the initial 
page-load it's a trade-off psychologically between seeing each image 
appear incrementally as the page renders and seeing all the images 
appear at once after a slightly shorter total wait-time.  In the case 
of your menu, with such small images to begin with, the difference in 
wait time will be slight.  The advantage will be that the hover-state 
images will appear instantly on mouseover.


2) Preload the hover-state images by marking them up on the page in a 
way that doesn't show -- such as shifting them off-screen with a 
large negative margin-left in CSS.  By the time the page finishes 
loading, they will already be in cache and will appear 
immediately.  One small disadvantage here is that your page might 
contain semantically unnecessary markup to support these image 
preloader elements.


3) Preload the hover-state images with javascript.  Disadvantages are 
the additional clutter of the script itself and the fact that 
preloading won't happen when scripting is disabled.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] CSS resources for Graphic designers?

[Paul Novitski]

Susie,

Graphic designers making a successful transition to the web need to 
let go of a lot of the fine control they exercise routinely in print 
design.  Suddenly the page becomes a rubbery thing, resizable by the 
user and morphable by changing content.  A single static image is to 
a web page as a single frame is to a movie.  Too often a graphic 
designer will create a snapshot and think their job is done, leaving 
the "petty details of implementation" to the coder who has to figure 
out how the page will stretch without breaking and with its look & 
feel intact -- an enormous job that entails a huge amount of graphic 
design skills.  If you can get your designers to provide a half a 
dozen snapshots of each page exploring variations in font size and 
content size your own job will be easier and you'll be much less 
likely to strangle one another down the road.


I'm leaning toward the opinion that Photoshop is not a good tool in 
web design, at least not the way it's used by most.  Fonts are 
anti-aliased, text is static, dimensions are measured in pixels, not 
ems, and things are often arranged on the page arbitrarily, eyeballed 
to look right to the designer, without regard to consistency of 
margins & gutters.  The result is something that looks like a 
finished product and sets expectations for HTML & CSS to mimic, while 
in reality it's only an approximation like a good pencil sketch.  My 
ideal graphic designer would be fluent in HTML, using Photoshop to 
prepare the component images but not to mock up the entire page.


Good luck with your meeting, and let us know how it goes.

Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Paul Novitski]

At 10/26/2006 06:31 PM, Thierry Koblentz wrote:

IMO, the goal should be to deliver the *cleanest* document possible, with
the least amount of structural hack, hook, etc.


You mean like 40 lines of JavaScript to morph the markup of a 16-item list?


In the example I posted, one can't get cleaner than that. The only issue I
see is that screen-readers end up with a table.


Oops.  Isn't accommodating non-visual user agents one of the primary 
reasons we're trying to drag the world wide web off that old table jones?


To be fair, though, using JavaScript to change semantic markup into 
arbitrary glop for the sake of presentation doesn't necessitate the 
use of tables; that was just the way you built this particular 
demo.  You could have simply split the list into two pieces and 
floated them left.




http://www.tjkdesign.com/test/
on top of that, it is possible to make the list display across different
number of columns without having to edit the markup nor the stylesheet;
actually, there is *no* stylesheet ;)


It gets better!  No more pesky separation of structure from 
presentation from behavior!  Now we can have them all neatly combined 
in a single file.  How... compact!




Disabling the script is all what is needed for screen-readers to speak the
links in the proper sequence.


So Jaws users have to disable your tool and all other JS helpers on 
the page in order to read the content in the proper sequence?  I'm 
sorry, but how is this a step ahead?




Think about it... ;-)


I'm thinking mostly that you are one of the brighter lights in our 
firmament, and I love your ingenuity.


Paul

At 10/26/2006 07:19 PM, Christian Montoya wrote:

3. How does this expect to deal with user agents that look at
*generated source* and not original source?




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Multi-Column List

[Paul Novitski]

At 10/26/2006 04:06 PM, Thierry Koblentz wrote:

Paul Novitski wrote:
> If you haven't already, please read my List Apart article
> <http://alistapart.com/articles/multicolumnlists/>.  I'd love it if
> you could improve on any of those techniques or come up with ones I
> hadn't considered.

Hi Paul,
What about this one?: http://www.tjkdesign.com/test/
;-)


Table-based markup!  How ingenious!  You're a regular pioneer of the 
untrod realms, Thierry.




BTW, there are typos in the "markup" box on
http://www.alistapart.com/d/multicolumnlists/example5.html
You're missing the opening A tags...


Thanks!

Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Multi-Column List

[Paul Novitski]

At 10/26/2006 11:54 AM, Mike at Green-Beast.com wrote:

Thanks for the feedback. I did note it was left - right - down so it was
more or less just an option for if wanting a presentational list in that
format (not sure if it's wrong or fractured per se).


Sure -- perhaps I shouldn't have used such prejudicial 
language!  There are instances in which horizontal list wrap is 
perfectly acceptable, e.g. gallery thumbnails.  It's when the 
designer (such as the OP for this thread) wants vertical sequences of 
list items that the horizontal format seems inappropriate.




That said, maybe I'll have to offer it the other way in a future experiment.
I do suspect I'll have to measure heights in EMs, though to prevent breakage
(assuming I'll end up using some negative margin-top).


If you haven't already, please read my List Apart article 
.  I'd love it if 
you could improve on any of those techniques or come up with ones I 
hadn't considered.


Warm regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Multi-Column List

[Paul Novitski]

At 10/26/2006 05:58 AM, Mike at Green-Beast.com wrote:

Not sure if this one's messed up on various platforms/browsers but I think
it's stable. It might yet another option for you. It's good and resizes well
in everything *I've* tested it in (including IE7). The ordering is left -
right - down, left - right - down, and so on. Very accessible.

Write-up: http://mikecherim.com/gbcms_xml/news_page.php?id=4#n4
Experiment/demo: http://mikecherim.com/experiments/css_double_lists.php



The main drawback of this technique is that, although the markup 
sequence is correct, the presentational sequence is fractured, with 
consecutive list items appearing in adjacent columns:


A   B
C   D
E   F

The challenge is to present the list items in two or more vertical sequences:

A   D
B   E
C   F

...while maintaining a single, correctly-sequenced list in the markup.

Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Multi-Column List

[Paul Novitski]

At 10/26/2006 01:44 AM, Sarah Peeke (XERT) wrote:

Basically I need to show a list of links in two columns, alphabetical
vertically (one column will not suffice as the list is too long).

I've seen a number of options for styling a list in two columns (or
more) using line-height and a negative margin, but they either don't
render well across a number of browsers, or rely on pixels etc.



The methods I describe in this article use ems for positioning, not pixels:
http://www.alistapart.com/articles/multicolumnlists/
My favorite method is the last (#6).  Have you found that it doesn't 
survive cross-browser?  I'd be interested in your findings.




The other option is to use two separate lists (part a and part b) - but
I imagine that this won't be as accessible.

eg

Sub Heading

  
Apples Oranges
BananasPineapples
   


It doesn't seem inaccessible to me, it's just not true to the actual 
content which is one list, not two.




I don't think DLs or tables are appropriate here. Does anyone disagree?


Not I.

How could a DL help you here?  You mean by putting half the list in 
one or more DTs and the other half in one or more DDs?  Unless the 
first half of the list defines the second half in some way, using a 
DL would be inappropriate.


Splitting the list in two with any markup purely for the sake of 
presentation seems inappropriate to me (of course, I'm not facing 
your deadline!).  I still think your best bet is working for better 
cross-browser styling of a single unordered list.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cleaning the body

[Paul Novitski]

At 10/16/2006 12:49 PM, [EMAIL PROTECTED] wrote:

I'm trying to clean as much JS crud from the body as I can. My JS skills
are still somewhat limited. I have a couple methods I wish to eliminate
from the body but still have available. How do I do it?



Google "unobtrusive javascript" to learn how you can (and arguably 
should) eliminate ALL scripting from your HTML file, leaving only the 
script tag 

Re: [WSG] programmmer said: difination list not a standard practise

[Paul Novitski]

At 10/11/2006 07:08 PM, Thierry Koblentz wrote:

I'd agree it is "rare" to see more than one DT but not to see multiple DDs.



Come on, you guys, revisit the spec:
___

W3C HTML 4.01 Specification
10 Lists
10.3 Definition lists: the DL, DT, and DD elements
http://www.w3.org/TR/html4/struct/lists.html#h-10.3


...
Here is an example with multiple terms and descriptions:


   Center
   Centre
A point equidistant from all points
  on the surface of a sphere.
In some field sports, the player who
  holds the middle position on the field, court,
  or forward line.

___

It's clear that multiple terms and multiple definitions are part of 
the spec.  It's all about a structure designed to describe 
multifaceted objects in linguistic space.  It's made for describing 
things in the real world of human endeavor.  It's simplistic because 
it's only got two types of facet, but it's not limited in the number 
of each it can support.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] In the 'Wow, if only everyone did this" category...

[Paul Novitski]

At 10/9/2006 08:52 AM, Tom Livingston wrote:

View this in WebKit browsers only. (Hence the subject of this post):
http://decaffeinated.org/archives/projects/multibg/background-image.html


http://decaffeinated.org/archives/projects/multibg/styles.css
body {
background-image: url(tigerdisc.png), url(spotlight.png), 
url(automator.png), url(dashboard.png), url(dictionary.png), 
url(ichat.png), url(mail.png), url(quicktime.png), url(safari.png), 
url(gradient.png);
background-position: 50% 40%, 20% 65%, 15% 40%, 20% 15%, 50% 
5%, 80% 15%, 85% 40%, 80% 65%, 50% 80%, bottom left;
background-repeat: no-repeat, no-repeat, no-repeat, 
no-repeat, no-repeat, no-repeat, no-repeat, no-repeat, no-repeat, repeat-x;

}


The demo says "Got Safari 1.3 or above?" but browsercam shows it 
works in 1.2 as well:

http://www.browsercam.com/public.aspx?proj_id=290246

Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Article: creating drop cap on the fly

[Paul Novitski]

Re:
http://tjkdesign.com/articles/a_perfect_Image_Replacement_technique.asp
I wrote:

The most obvious disadvantage of using JavaScript to modify markup is
the inevitable delay: scripts of this nature wait till download is
complete before manipulating the DOM.


At 10/6/2006 03:00 AM, Christian Heilmann replied:

True, but you can counteract this with newer techniques like
onAvailable instead of onload.
http://dean.edwards.name/weblog/2005/09/busted/


Thanks for this link!  Good old Dean!



I'd rather not have to download images for each header if
my browser doesn't support them anyway.


Maybe I'm missing something, but I don't see Thierry's script 
protecting you from unwanted images unless you disable JavaScript, 
which is about like burning down your house just to turn off your 
TV.*  My understanding is that if a browser doesn't support images 
then it simply displays the ALT text and doesn't bother downloading 
the unusable image files themselves.  Thierry's script downloads 
images (creates image tags) if JavaScript is running, no mention of 
whether the browser supports images.


One of the many clever aspects of Thierry's IR technique is that, in 
the absence of client-side scripting, it falls back gracefully to the 
plain text in the markup.  If the images are inserted before download 
instead of after download, the resultant markup is the same as it is 
when JavaScript executes, but the server-side solution works 
regardless of JS support in the client.


Warm regards,
Paul

* As everyone knows, the preferred technique is to throw the TV out 
an upper-floor window. 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Article: creating drop cap on the fly

[Paul Novitski]

At 10/4/2006 08:49 AM, Thierry Koblentz wrote:

I'd appreciate any comment that would help me improve this article:
http://www.tjkdesign.com/articles/the_perfect_image_replacement_technique.asp

and

http://www.tjkdesign.com/articles/the_perfect_drop_cap.asp



Thierry,

While of course I agree with the intentions and results of these 
image-replacement techniques, I disagree with one important aspect of 
their implementation: the use of JavaScript.  Using a client-side 
script to modify downloaded HTML is like editing a newspaper after 
the edition has hit the stands.  You have to send a gofer home with 
each copy of the paper and, painstakingly, with scissors and glue and 
while the erstwhile reader drums fingers, make the changes that 
should have been made before the paper ever went to print.


I assert that any Javascript routine that affects markup before the 
user has a chance to hover or click can and should be performed server-side.


Don't get me wrong, I love using JavaScript to enhance the user's 
experience on a page in response to their actions in real time.  But 
I prefer using server-side scripting (I am PHP's love-slave) to 
manipulate the fundamental markup.


The most obvious disadvantage of using JavaScript to modify markup is 
the inevitable delay: scripts of this nature wait till download is 
complete before manipulating the DOM.  The page renders with plain 
text and then morphs it into images, creating at minimum a flicker of 
un-imaged content for small pages and a more jarring transition for 
larger pages and/or slower connections.  It's unsightly.


Not to mention, JavaScript-dependent solutions depend, duh, on 
client-side scripting being enabled.  The conscientious developer 
must plan for a scriptless fallback (which you have done 
astutely).  But why not simply download the desired markup in the 
first place?  The more work is done server-side, the less relevant 
the question of whether the user has access to JavaScript.


I realize that JavaScript solutions like this can be handy when one 
doesn't have control over the markup and has to deal with legacy 
HTML, but how common are those nightmares really?  Most web designers 
have easy access to server-side scripting through either learning or 
networking.  And of course if you're replacing text heads with images 
then it's almost guaranteed that you can manipulate the markup enough 
to insert the necessary class and id triggers.  You've got the means 
and the opportunity; all you need now is the motivation.


If you groan at the thought of having to modify existing server-side 
scripts with markup changes, think about PHP's ability to output 
markup to a buffer and then manipulate it DOMwise before releasing it 
to the client.  That means that with tweaks at beginning and end, 
most any PHP script can be geared to buffer output to which we can 
attach a chain of markup manipulation routines as modularly and 
dynamically as you could want.  And of course if you're already 
crafting your own PHP page-generation, buffering output or tweaking 
markup on the fly is easy.


It's not like I'm asking you to defect.  Keep using JavaScript for 
interdependent lists, drag-&-drop, and other cool dynamics that 
today's HTML can't provide by itself.  But come over to the dark side 
for the behind-the-scenes schemes.


There's little excuse: having a common parent in C, JavaScript and 
PHP are syntactical siblings.  Making the transition a natural.  And 
PHP is so rich compared to JavaScript, it's like rising from a 
cramped coffin and flying off into the night sky (don't ask me how I 
know that).


Warm regards,

Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] p:first-line

[Paul Novitski]

At 9/5/2006 03:27 PM, Mike at Green-Beast.com wrote:

Yeah, I was just going along with what was posted in the original email; but
changing the pseudo element to a class. I always try to keep classes and IDs
as revealing as possible... makes going back to troubleshoot and such much
easier. I would have probably called it "indent"



Isn't that rather like classing a paragraph "red" or "left" or 
"large"?  I see the decision to indent the first line of a paragraph 
as a presentational one, not a semantic one.  I'd leave the class at 
"first" or "intro" something that indicated the role of the text in 
the structure, and indicate my intention to indent that text (or not) 
solely in the stylesheet.


Regards,
Paul 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] font standards today

[Paul Novitski]

At 8/24/2006 03:30 AM, Michael Persson wrote:
As a web developer and a designer i have been ok to use verdana, 
trebuchet and arial in my publications
all these years, now i am working with limits for the design and 
ineed to select from a list i found as standard

or websafe fontsat http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

Does anyone agreewith that this is the list of available fonts for 
online publishing as nowadays...???



Michael,

There's another technique you might want to explore that Stewart 
Rosenberger calls Dynamic Text Replacement in his A List Apart 
article .  I have come to 
disagree that part of the process should be coded in JavaScript, but 
the PHP core is fine.


The method uses PHP's GD function library that lets you convert text 
to a typographical image on the fly.  Here's an example in my own 
portfolio in which the burgandy heads in Formal BT were produced this 
way: .  We originally chose the technique 
because some of the heads change once a day or once a month.  For 
unchanging heads we've back-tweaked the HTML to download the 
typographic image files right from the start to avoid the rendering 
delay that comes with a javascript onload solution.


The images produced (PNGs in this case) are so small (1-2K) that it's 
a very practical technique for generating headlines, although I'd 
balk at using it for body text since any first-time visitor who 
didn't already have the images cached would experience a slow render.


The technique is nominally accessible because each typographic image 
has its text in the alt.


Of course you need to purchase the fonts you use with this technique.

Regards,

Paul



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Equal height divs

[Paul Novitski]

At 06:35 AM 8/16/2006, TuteC wrote:

Fast OT: It is not desirable to assign ids to each part of the site,
is it? Don´t want to open a new discussion, just a question.



You should give an id or class to enough elements 
that you can point unambiguously to every element 
on the page that needs individual styling or 
behavior.  This doesn't mean giving an id to 
everything; it's often possible to uniquely 
identify elements when they are a unique tag 
within a unique context, for example the only ul 
in div#header, the only p.byline in div#title, etc.


There's nothing technically incorrect about 
giving every element on the page an id.  For most 
production pages, it would merely be considered 
redundant and inelegant by many coders.  But it 
depends on your long-term goals.  For example the 
CSS Zen Garden, a hotbed of CSS expertise, 
features a densely encoded page because the 
intention is for it to be radically and frequently reskinned.


Regards,
Paul 




**
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] Equal height divs

[Paul Novitski]

At 09:41 PM 8/15/2006, TuteC wrote:

Again learning from your experience. I am trying to implement
http://www.projectseven.com/tutorials/css/pvii_columns/ to a design
where I need both (navigation and content) have the same height.

I try to do it because each div has a background color, and I want
them to reach the footer no matter their content.



Hi Tute,

There's a lot of material on this on the web -- try googling "css 
equal height columns" and "css faux columns" for example.


I also highly recommend the CSS-D wiki at 
http://css-discuss.incutio.com/ and in particular the two-column layout page:

http://css-discuss.incutio.com/?page=TwoColumnLayouts

If you're only dealing with two columns, consider this: you may not 
actually need the two column divs to be the same height, you may only 
need them to look like they're the same height.  If both columns are 
inside a wrapper, the wrapper will stretch to be the height of the 
longer of the two.  You can apply the background to one side of the 
wrapper and it will lie behind one of the columns, full height, 
regardless of which is the longer column.


That simple solution does work for some graphic treatments but gets 
tricky with others, as when you want a border around one of the 
columns and not merely a block of background color or image.


Regards,
Paul 




**
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] Branding - Accessible, Unobtrusive and Semantic

[Paul Novitski]

At 11:09 AM 8/11/2006, Designer wrote:

Richard Czeiger wrote:

Hi all  :o)

Just thought I'd throw a bit of code out there and see if anyone 
thinks it's useful..


Unobtrusive Semantic Branding
http://www.grafx.com.au/dik/branding.html

Yes, it's interesting - but is there an advantage over pure 
CSS?  see [1].  It seems simple, but I knocked it up very quickly, 
so someone may find a problem . . .


[1]  http://www.marscovista.fsnet.co.uk/template/branding_CSS.html



Bob, you're presenting the markup that Richard's script produces.  By 
the time his script has finished running, his and your solutions are 
both HTML & CSS.  He's just using javascript to automate the 
distribution of his solution throughout the markup.


Personally I think javascript is an odd choice for this.  The 
javascript solution won't execute until the page is loaded, so for 
heavy pages there will be a delayed rendering.  And of course the 
branding won't render at all in browsers not executing javascript.


It's a little like distributing a book with a black & white cover, 
plus a loose color cover.  Cool!  You can glue on your own color 
cover! ...if you've got glue...  But why not simply distribute the 
book bound in the color cover in the first place?


Javascript is great for immediate user interaction, but for page 
modification like this it seems slow, redundant, and inefficient.  If 
we're generating our pages server-side to begin with, why download an 
incomplete markup to the client and then complete the markup with 
javascript?  It makes sense when javascript executes differently 
based on user actions and on conditions found only after download, 
but I don't see that here.


What does make sense -- and this is the intelligence at the core of 
Richard's script -- is the separation of the brand name from the 
brand styling.  Because his method of branding (applying different 
colors to substrings within the whole) requires specific markup, he's 
inserting his classed spans into vanilla markup instead of 
hard-coding the whole thing in HTML.  This is smart.  It's the 
decision to perform this morph after download that I question.


In PHP, for example, it would be easy to assign a variable the 
requisite markup, then invoke it in the script whenever necessary:


$sOurCompanyName = 'class="b1">companyName ...';

...
echo "Our brand is $sOurCompanyName and we think it rocks.";

The specially marked-up company name is independent, easily 
modifiable, defined only once in the application.  It can be stored 
as plain, unquoted HTML in its own text file so it's completely 
separated from the PHP logic layer.


Additional food for thought:  With buffering it's possible for PHP to 
completely produce a page and only then release it for download to 
the browser, rather than downloading it incrementally during 
generation.  This means that after page-generation has completed, one 
can run additional processes on the complete, buffered markup before 
download.  Markup-tweaking functions can be slapped onto an existing 
script without having to be merged with the flow of page-generation 
-- one of the ways we've used javascript in the past.


Finally, although Richard's script is unobtrusive in the sense that 
it doesn't fundamentally break the page if javascript isn't running, 
I did find it obtrusive from a developer's persepective.  It's a big 
whack of bandwidth to effect a very small change in markup, and brand 
coloration -- the only goal of the script -- does in fact break in 
the absence of javascript support in the browser.


Downloading the customized markup from the server seems like a much 
more elegant approach.


Regards,
Paul 




**
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] Least ugly way to achieve multiple backgrounds

[Paul Novitski]

At 11:11 PM 8/8/2006, Pamela Jones wrote:

Thanks for your reply, Paul.  I'm not sure I understand what you mean.
My problem is not so
much with the visibility, stacking them in the right order will 
work, it's more a matter of I don't
know which elements / DIVs to attach them to because you can't 
attach more than one background
image to an element.  To be a bit more clear, you can see the design 
at http://www.creatingascene.com.au/design.html.


The background elements are the hand drawn blue lines that intersect 
at the top of the page (this I've attached
to the containing div that has the thick blue border) as well as the 
two scribbled areas - blue on the bottom
left and yellow on the bottom right.  I'm not sure what to attach 
those to without changing the HTML

specifically so that I can attach a background image.



Interesting page, Pamela.  In order to figure out the best 
arrangement of background images, you'll need to describe what 
happens when the user resizes their browser text.  Do all three 
columns and the outermost container expand both horizontally & 
vertically with font size?  Do you have the basic page marked up as 
HTML that we could see in action?


I can imagine the two scribbles (lower left & right) staying flush to 
the bottom and to each its side of the outer container.


I see the vertical blue line shifting to the right, as font size 
increases, in order to remain between columns 2 & 3.


The complicated bit is the horizontal blue line that changes to light 
blue where it intersects with the dark blue box at upper left.  As 
that dark blue box widens, I would expect more light blue line to be 
exposed, sliding in from the left side.  The point that must be fixed 
is where the blue line enters the blue box (at coordinates 170x76 in 
your page mockup gif).  That point of intersection will remain 
constant even as the dark blue box and the outer container expand horizontally.


I visualize the markup like so:

- outermost container with blue border.  The background image = 
horizontal blue line across the top + the blue scribble bottom 
left.  This image extends both farther to the right and lower than 
the normal-sized page, so that more blue line and scribble will be 
exposed as the box expands.  The background is positioned left top so 
that the intersection point with the blue box can remain fixed.


- an inner container, background = the vertical blue line, positioned 
in ems from left so it stays between columns 2 & 3.


- header block, the same width as column 1 and coming down to the top 
of column 1, containing the page headline.


- column 1, containing the blue boxes.  The background image for the 
top dark blue box is positioned right top and is much wider than the 
normal size, so that as the box expands laterally more of the 
background is exposed at the left edge.  This keeps the intersection 
point with the horizontal blue line fixed.


- column 2.

- column 3, with a left & bottom margin that shows the yellow 
scribble background image.


That would be my first draft, anyway!  I'll be interested to see how 
you've marked up the page.  With some further thought it might be 
possible to eliminate that inner container.  If present it would be 
semantically neutral, but it wouldn't exist in the most elegant of solutions.


Paul 




**
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] Least ugly way to achieve multiple backgrounds

[Paul Novitski]

At 09:24 PM 8/8/2006, Pamela Jones wrote:
I am working on a site for a client for which the design requires 
some different subtle images in
the background (e.g. top, bottom left and bottom right).  I'm facing 
difficulty because I have a
container div which contains three columns, each with a significant 
margin.  The backgrounds

are all within the outer container, crossing columns where necessary.
(e.g. the bottom left image
sits behind the first two columns, the top image spans all three 
columns and the bottom right image

sits behind only the right column).



I would imagine you could do this with PNG images with alpha 
transparency, with these provisos:


- To make the alpha transparency work in IE you'll need a second set 
of rules, e.g.:


div#a
{
background: url("images/logo.png") left top no-repeat;
}
/* for IE */
* html div#a
{
background: none;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, 
sizingMethod=image src='images/logo.png');

}

See:
http://msdn.microsoft.com/workshop/author/filter/reference/filters/alphaimageloader.asp
google "css png" for more


- I haven't found a way to automatically repeat a background image 
using the Microsoft.AlphaImageLoader.  Unless someone else can come 
to our rescue, you'll need to accomplish div-stretching using sliding 
doors, e.g.

http://alistapart.com/articles/slidingdoors/

For sliding pieces, sizingMethod=crop is the way to go.
sizingMethod=scale stretches an image to fit its container, OK for 
monochromatic blocks but distorts images with texture.

sizingMethod=image stretches the container to fit the natural image size.

Regards,
Paul 




**
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] Custom Bullets

[Paul Novitski]

On Aug 9, 2006, at 11:50 AM, Paul Novitski wrote:


PS:  Frankly, since the list-style properties apply only to
elements with {display: list-item}, I'm a little surprised that
it's correctly applicable to UL at all and not just LI, but I guess
it's just a quirk of CSS that we can give a LIST CONTAINER a LIST- 
ITEM display.  When it is applied to UL, I assume that its child

LIs inherit the property, but I don't see the inherent advantage to
a rule like ul {list-style...} over li {list-style...}.  Myself, I
always roll my own lists just with li {list-style-type: none;}.


At 08:09 PM 8/8/2006, Philippe Wittenbergh wrote:

li {list-style-type: none;} applies to all li on a page, in a  or
a 

Personally, I do ul li {list-style: whatever}. or ul.classname li {}

...

the keyword here is:
inherited: yes

The list-marker will be applied to the descendants of the , not
the  itself, as that on has display:block, unless otherwise
specified.



Yes, of course: I don't use the global rule

li {list-style-type: none;}

by itself as this would apply to OL LIs as well, but always in context, e.g.:

#navmenu li {list-style-type: none;}

What I meant was that I apply the rule to LI, not UL.  However, I 
think this is probably a point too fine to belabor as the rule works 
equally well applied to either element.


Regards,
Paul 




**
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] Custom Bullets

[Paul Novitski]

At 06:22 AM 8/8/2006, Christian Heilmann wrote:

Don't bother with list-style image but use list-style none on BOTH UL
and LI and then use padding + background image and all is fine.
http://css.maxdesign.com.au/listamatic/vertical05.htm



Hey Christian,

I've never seeen the need to apply list-style to *both* UL & LI -- 
and the listamatic example you cite applies it only to UL.  Could you 
please elaborate on this niggly little point?


Thanks,
Paul


PS:  Frankly, since the list-style properties apply only to elements 
with {display: list-item}, I'm a little surprised that it's correctly 
applicable to UL at all and not just LI, but I guess it's just a 
quirk of CSS that we can give a LIST CONTAINER a LIST-ITEM 
display.  When it is applied to UL, I assume that its child LIs 
inherit the property, but I don't see the inherent advantage to a 
rule like ul {list-style...} over li {list-style...}.  Myself, I 
always roll my own lists just with li {list-style-type: none;}.


CSS 2.1 Specification
12 Generated content, automatic numbering, and lists
12.5 Lists
http://www.w3.org/TR/CSS21/generate.html#q10

9 Visual formatting model
9.2.4 The 'display' property
http://www.w3.org/TR/CSS21/visuren.html#display-prop 




**
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 usage of th

[Paul Novitski]

At 10:09 AM 8/3/2006, Joe wrote:
I understand the  tag should be used on the items in the top 
row, but what about the row on the left?  Are they also considered a 
header of the row?  If so, wouldn't 'Food Type' be a header of a 
header?  What do you guys think?




More to the point, what do the authors of the HTML specification 
think?  Please read the spec, it's quite illuminating for anyone 
attempting website development.


HTML 4.01 Specification
11 Tables
http://www.w3.org/TR/html4/struct/tables.html

Notice, in various examples on this page, mid-table rows that begin 
, such as:



A test table with merged cells
Average
Redeyes
heightweight
Males1.90.00340%
Females1.70.00243%


So to answer your question, TH table header cells are good for both 
column heads and row heads.


Regards,
Paul 




**
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] proper image-content-image markup

[Paul Novitski]

At 04:38 PM 8/2/2006, Brian Cummiskey wrote:
I have a template from a designer for a background image to go 
behind the H2 category tags on a new layout.  It has distinct fixed 
left, center repeating (depending on text length), and fixed right 
portions to it.

(something like this:   ==text===Y)

Which is the more proper way to mark this up?

Foo1
vs.
Foo2
vs
Foo3



Until more browsers support CSS3 multiple background images I'm 
afraid you'll need a bit of extra markup.  Fortunately spans and divs 
are semantically inert (in my opinion) and are unlikely to interfere 
with a future parser.


Of your markup options, I prefer using the Hn tag as the outermost 
container because everything it contains constitutes the headline.


Because your outermost container can hold a background image, you'll 
need one less extraneous tag than you have images to deal with.


You don't actually have to have an empty tag like:

Headline

If it makes you feel better, you can mark it up like this with equal success:

Headline

Theoretically you might figure you need three images:  left, right, 
and repeating center.  However, realistically, does the center really 
need to repeat?  Or will it have a practical width limit in the 
context of the page?  If it were, say, 2000 or 3000 pixels wide, 
would a user ever plausibly discover its limits?


I'm suggesting you can style it like this:

#

where # is the background of the Hn tag and  
is the background of the span.  The two background images slide out 
from one another as the width of the pill increases.


With this model there's the potential for using a single background image.

Consider a pill-shaped graphic, 2000px wide, with rounded left and 
right ends.  (I just slapped one together in Photoshop, 2000x100 
monochromatic green that weighs in at 7k.)


This is a headline

The left cap of the image is applied to a fixed-width block of 
padding on the lefthand side of the headline, with the background 
image positioned left.  The rest of the headline takes the right-hand 
portion of the same background image, with enough right-padding to 
ensure the right cap curve is honored.  (This sliding door technique 
works with opaque images, not transparent ones.)


Here's a quick demo:
http://juniperwebcraft.com/demo/singleImagePill/

This example is very limited, just to show the fundamental 
concept.  To work well it should also stretch vertically, making it a 
stretchable rounded-corner box which you can accomplish with this 
same technique.


Regards,
Paul 




**
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] Div names

[Paul Novitski]

At 04:00 PM 8/1/2006, TuteC wrote:

Hello all!
I have a rather simple question: does it have any semantical meaning
the name of a div? For example, if I have a Distributors, will the search
engine understand the name of the div or di I need that h3 to do that?

I know it has little sense and certainly I use also the h3, but it was
just a question I had.

Also, as  means "Heading 3", what thas "div" mean?
Best regards and thanks in advance;
Eugenio.



Eugenio,

To my knowledge, no search engine attempts to parse the linguistic 
content of class names or Ids.


"div" is an abbreviation for "division."  It means an arbitrary 
grouping of other elements, without any semantic significance beyond that.


The HTML 4.1 spec says:

"The DIV and SPAN elements, in conjunction with the id and class 
attributes, offer a generic mechanism for adding structure to 
documents. These elements define content to be inline (SPAN) or 
block-level (DIV) but impose no other presentational idioms on the 
content. Thus, authors may use these elements in conjunction with 
style sheets, the lang attribute, etc., to tailor HTML to their own 
needs and tastes."


W3C HTML 4.01 Specification
7 The global structure of an HTML document
7.5.4 Grouping elements: the DIV and SPAN elements
http://www.w3.org/TR/html4/struct/global.html#h-7.5.4

I strongly recommend that you read this entire document -- you need 
to know your ingredients before you can work wonders in the kitchen.


There are translations available here:
http://www.w3.org/MarkUp/html4-updates/translations

Regards,
Paul 




**
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] Standards Table Layout

[Paul Novitski]

At 06:15 AM 7/30/2006, CK wrote:

A client who is clinging to the web of yore, is still insisting on
tables being used for layout.  It is the misconception tables provide
greater browser compatibility, the client supports IE 5.X for MAC OS.



Actually, I think table-based layout DOES provide cross-browser 
consistency as your client maintains.  The argument against tables 
for layout isn't that they don't render consistently cross-browser 
but that they don't fit non-tabular data semantically, they can 
obfuscate content for non-visual readers, their layouts are rigid and 
unresizable, and, because they hard-wire presentation in the HTML 
markup, they create a site-maintenance boondoggle down the road.


Even if your client doesn't care about semantics and is insensitive 
to the needs of the visually impaired, you might be able to persuade 
them that their long-term website expenses will be reduced 
significantly if they let you separate content from presentation today.


Unfortunately for your argument, your client's short-term web 
development expenses might be less if you use tables, unless you've 
already become good enough at CSS layout that you can whip Mac IE 5.x 
into line without hours of trial & error.


There are many sites that feature CSS layout examples.  To know which 
ones can replace tables effectively for this project you'll need to 
define your layout goals.  Which aspects of table-based layout does 
your client consider important?  A list of those attributes will help 
point you to the appropriate CSS layout techniques that will satisfy you both.


Regards,
Paul 




**
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] New with a ?

[Paul Novitski]

At 08:49 AM 7/30/2006, Tina wrote:
My question is this - the design that I am working on has carried to 
a fixed width of 900px for the page. Now I do know that this won't 
display correctly at 800x600 because of the width - but is this 
really something I should worry about? Most new computers are set at 
least 1024x768 out of the box, and I believe that the majority of my 
target audience will be on these settings as well.



Tina,

You can't limit or predict the resizing of browser text by the 
user.  If your text blocks are sized in pixels and the user zooms 
their text in or out, your beautifully-crafted layout is very quickly 
going to break, get ugly, or become difficult to read.


Neither can you limit or predict browser window size, regardless of 
monitor resolution.  Not every PC user maximizes windows, and I've 
rarely seen a Mac user do so.  Requiring people to maximize their 
windows goes way beyond the mandate of the web designer.  Personally 
I think it's reasonable to assume some minimum window width in order 
to accommodate fixed-width content such as images, and I think it's 
reasonable to aim for a minimum window size based on your 
understanding of market share: almost no one will expect you to 
support 640x480, and some developers have already turned their backs 
on those still using 800x600 (including a lot of people using older 
and hand-me-down computers in the world's poorer neighborhoods).


You'd go crazy if you tried to accommodate literally everyone, but 
fortunately today's technology enables us to accommodate an enormous 
majority with only minor medication & counselling required.


I suggest a flexible dimensioning algorithm that uses relative 
measurements whenever possible:


- Design your page to fit in your most narrow target window width 
when text zoom is set to normal.  I'll often mandate the Windows 
default font size of 16px in all browsers; then 800px / 16px = 
50em.  I usually reduce that to 48em to accommodate the width of the 
vertical scroll bar.


- Set your column widths in ems so they zoom in proportion to text size.

- Give a minimum pixel width to columns containing fixed-width images.

- Don't give any column of text a width greater than 30 or 40em for 
the sake of line-length readability.


- Limit your content width to 100% of window width to prevent 
horizontal scrolling.
(Or should we leave this up to the individual and not try to 
protect them from themselves?)


If you haven't yet, check out the CSS-D wiki for tips, techniques, 
and great links: http://css-discuss.incutio.com/


Paul 




**
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] non system fonts - WebDesign

[Paul Novitski]

At 11:39 AM 7/29/2006, Shlomi Asaf wrote:

i need to design a webPage right now, that uses different kind of fonts.
is there a way to integrate those fonts using CSS?
or we use only system fonts in webDesign

those fonts are like: Helvetica Condensed Bold; VTCSwitchbladeRomanceTall.



Shlomi,

In addition to suggesting font families in CSS, you can also mandate 
fonts using "Dynamic Text Replacement":


If you're using PHP you can create image files on the fly containing 
any font you install on your site.  It's not fast enough to be 
practical for body text, but it works fine for the occasional headline.


Your first step will be to purchase a copy of the font(s) you'll be using.

Here's an example, a site in which the burgandy-colored headlines are 
generated on the fly:

http://216.70.101.89/ (under construction)

The technique relies on JavaScript, converting text to images and 
storing the original text as img alt.  When either images or 
JavaScript is disabled, the headlines render as plain text.  It's 
accessible and it degrades gracefully.


This technique uses PHP image functions: http://php.net/image

I've modified a script written by Stewart Rosenberger and described here:

Dynamic Text Replacement
by Stewart Rosenberger
June 15, 2004
http://www.alistapart.com/articles/dynatext/

More details on his website: http://www.stewartspeak.com/projects/dtr/

Regards,
Paul 




**
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] IE7 news

[Paul Novitski]

At 07:32 AM 7/27/2006, Tom Livingston wrote:

http://blogs.msdn.com/ie/archive/2006/07/26/678149.aspx

IE7 will be out for XP after all. Good news, IMO.


Good news I suppose, although I groan to think that I need to add yet 
another browser to my routine testing list.  In my dreams, IE7 will 
be Firefox-compatible and won't require special treatment, but my 
nightmares (you know, the ones that bleed over into my waking hours) 
say otherwise.



At 09:46 AM 7/27/2006, Christian Montoya wrote:

Are there any stats on how many users have a bootleg copy of Windows
XP? I have a feeling it's a huge number.


Maybe I'm being naive, but I thought you "can't" bootleg XP because 
each copy of the software gets registered to a single computer.  When 
I moved from desktop to laptop a few years ago, and then six months 
later moved to another laptop, I actually had to persuade a dubious 
human being on the phone at Microsoft that I wasn't pirating their 
operating system.  Like all security systems this is no doubt 
hackable (by spoofing the software id and/or whatever adds up to be 
the computer id), but I imagine that's too sophisticated a hack for 
the average computer geek, much less for the average user.


Paul 




**
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] Rounded Corners

[Paul Novitski]

At 10:10 AM 7/23/2006, Gunlaug Sørtun wrote:

Is there a standard-compliant and 'semantically clean' way to generate
the extra elements/style-hooks needed for something like what's in this
test-page...

...that'll work in most browsers?


Georg,

Your basic structure looks like it would be easy 
to implement in JavaScript or PHP.  Using PHP, 
the expanded markup would be downloaded to the 
browser so it would render immediately and 
wouldn't be dependent on JavaScript.  Using 
either language you'd be able to mark up your 
pages without hard-coding the extra divs.














Easy borders











It looks like your seed markup might be this:




Easy borders




If every element that needs the t#s and b#s 
inserted has a common flag, say an additional 
class name (such as "rc" above), JavaScript could 
walk the DOM and insert the extra divs where needed.


Are "brdr-field bgnd1" and "hdl-field" part of 
the original page markup, or can they be generated too?


This is the technique I'm using on my site: 
http://juniperwebcraft.com/  Compare the page 
source with the generated source to see the difference.



More difficult still: how to integrate it all with a real
background-image on the box.


Tell me how you envision the background image 
looking.  Would the background image itself 
appear to have rounded corners as well?


Regards,
Paul 




**
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] Rounded Corners

[Paul Novitski]

At 06:13 AM 7/23/2006, Keryx webb wrote:

Perhaps you can try this one. No JS. No extra Markup.

http://www.sitepoint.com/blogs/2006/05/02/spanky-corners-10-rounded-corners-clean-html-no-javascript/



Nice technique, though I can see a few limitations:

- It's limited to solid monochrome rounded boxes because, while the 
corners are images, it relies on CSS borders to supply the top, 
bottom, and sides.


- This method wouldn't work with transparent corner images because it 
relies on images covering one another opaquely.


- These boxes shrink well but they expand poorly: in Firefox the 
boxes start breaking up on the fourth zoom.  That might be tweakble.


Otherwise, nice work!

Paul 




**
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] Rounded Corners

[Paul Novitski]

If you call me a conservativist you're right :) I hope we can find a
way to the realm of the rounded corners without solutions like this.


Sure -- we can just use SPAN or DIV instead.


At 04:51 AM 7/23/2006, Patrick H. Lauke wrote:
But that still litters the markup with empty, meaningless elements 
which are there purely to serve the visual layout...



I understand what you're saying, of course, Patrick.  I'm always 
looking for ways to coax sweet styling from minimalist markup, and 
only reluctantly do I add extra tags purely for the sake of 
layout.  I can do resizable rounded corners by adding four or five 
extra tags per box but I haven't been able to get it down lower than 
that.  As the extra tags don't interfere with a semantic reading of 
the page, I allow them for the sake of the effect.  I can live with 
this compromise until CSS-3's multiple background images become 
commonly supported.


Adding layout tags for rounded corners muddies the water, but it's 
not as though the pond were crystal clear to begin with.  Tags for 
the sake of layout are ubiquitous in our field.  We all use them 
routinely, such as the divs we use to float columns.  We justify 
their existence by matching them up with plausible groupings of the 
content, but the primary reason they're there is give us a skeleton 
to hang our stylesheets on.  If I weren't going to style a page at 
all, would I bother enclosing the site title, page title, and nav 
menu in a division called "header"?  Or split the main content into 
two or three "columns"?  Or enclose the entire content in a 
"wrapper"?  Most of the time those divs aren't required to make sense 
of a page, they're necessary only to our styling.


As long as we dare sully the markup with even one div that's not 
semantically mandated by the content, we're on the slippery 
slope.  Are two non-semantic tags per page OK?  Three?  Where's the 
edge of too many?  The energy our community has spent wrestling with 
these questions only confirms that it's a matter of personal 
programming taste and style, it depends on where we each lie along 
the spectrum from zeal to pragmatism, idealism to expediency, from 
copious spare time research & development to the quick & dirty 
mortgage-paying job.  How sensitive are we?  Can we sleep with a 
single pea buried under our mattresses?  With two?



Injecting them via javascript may seem a bit more cumbersome, but at 
least it would keep the content source devoid of non-content-carrying junk.


It's always struck me as ironic that so many of us who carry the 
banner of semantic, validated X/HTML are willing to inject all kinds 
of stuff into pages at runtime.  What is this -- we don't want to 
dirty our own hands typing non-semantic markup, but it's OK to build 
a robot to do the evil deed for us?  If we always saw the generated 
source of our pages instead of the pre-scripting markup, I'm sure 
we'd recoil, aghast, and mend our errant ways.


Or not...

Regards,
Paul 




**
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] Rounded Corners

[Paul Novitski]

At 12:39 AM 7/23/2006, Janos Hardi wrote:

I have no ultima ratio to discredit this solution I'm just saying the
 as a html markup tag was designed to an other purpose, namely
styling or modifying a content element. In this case the purpose
mentioned cant be fulfilled. This solution opens the way to style a
document, but  is for smaller content elements.

Thats all :)

If you call me a conservativist you're right :) I hope we can find a
way to the realm of the rounded corners without solutions like this.



Sure -- we can just use SPAN or DIV instead.

Regards,
Paul 




**
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] Rounded Corners

[Paul Novitski]

On 7/22/06, Al Kendall wrote:

try these   http://www.html.it/articoli/nifty/index.html


At 05:06 AM 7/22/2006, Janos Hardi wrote:

This solution has nothin to do with common semantics - not recommended.



Janos, may I assume that it's the use of the B tag you're objecting 
to, rather than the addition of DIVs to the markup to support the 
rounded corner effect?


Alessandro Fulciniti, the author of that technique, uses B tags 
simply for brevity of markup -- ironic, because while saving six 
characters for each element (using B instead of SPAN) he's adding a 
couple of dozen for inline styling.  He says, "A few words on the use 
of the  element. I needed an inline element to obtain the rounded 
corners, since it could be nested in almost every kind of tag 
mainting the markup valid. So the choice fell on b because it doesn't 
have semantical meaning and it's shorter than span, like Eric Meyer said."


We're currently using a different rounded corners technique on our 
site http://juniperwebcraft.com/ but similarly adding markup with 
JavaScript; we're adding classed DIVs to the markup and keeping all 
the styling in an external stylesheet.  (Look at the generated source 
with the Firefox webdev tool, not the simple page source, to see the 
resultant markup.)


I don't think Fulciniti's technique should be discarded simply 
because of his debatable tag choice when there are other neutral 
elements that can more innocuously substitute.


Regards,
Paul 




**
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] Hungarian notation for JavaScript and ActionScript?

[Paul Novitski]

At 09:28 AM 7/21/2006, Carl Reynolds wrote:
I think Hungarian notation should be avoided in any language, but is 
seems to me that it just becomes an extra annoyance with no added 
value in a typeless language like JavaScript.



Stating that Hungarian Notation "should be avoided" sounds like you 
know of some deleterious effects it has on software development.  Is 
this the case or is it merely a matter of personal taste for 
you?  For a few pro & con arguments see 
http://en.wikipedia.org/wiki/Hungarian_notation#Criticisms


I believe anything that helps a programmer write better code is a 
valuable tool for that individual.  I started using Hungarian 
Notation consistently a couple of years ago and I find it helps me 
write tighter code.  Typing my variables helps me remember their 
purpose and the range of values I'm using them to store, and makes it 
less likely that I'll run afoul of asymmetrical rules of usage which 
exist even in ostensibly "typeless" languages such as JavaScript.


In JavaScript, while conversion between types occurs silently, those 
types do exist in the underlying language structure -- hence the 
operator 'typeof':

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Special_Operators:typeof_Operator

JavaScript operators can have different effects on different types of 
values -- for example, compare the use of + to join strings with 
strings, strings with numerics, and numerics with numerics:


"37" - 7 // returns 30
"37" + 7 // returns "377"
37 + 7   // returns 42
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Values#Data_Type_Conversion

Also, methods vary significantly from one type of object to another; 
to use JavaScript without regard to type would mean avoiding objects 
such as Math, String, and RegExp and their methods.  I do use these 
objects, and I help myself remember the type of object by prefixing 
the variable name.


I can see that type-notating variables would be an annoyance if one 
used the same variable to store different types of value in the 
course of a single program.  I don't do this, so perhaps it's more a 
difference in programming style than notation that we're pointing to here.


Regards,
Paul 




**
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 is dead... use markup for presentation.

[Paul Novitski]

At 06:43 AM 5/23/2006, Gunlaug Sørtun wrote:


Looks like most efforts towards separation of content and presentation
may cause severe accessibility-failures[1] in the future.

...

[1]http://www.w3.org/TR/WCAG20-TECHS/#F1




My take on this passage is different.  The 
specific point that section is making is not that 
content & presentation shouldn't be separated but 
instead that a page will be considered invalid if 
CSS is used to change the presentational SEQUENCE 
of content from what it is in markup. [1]


The text goes on to give an exaggerated example 
of list items [marked up unsemantically with DIV 
& SPAN] marked up out of order and then visually 
resequenced into two lists in two columns using 
absolute positioning.  Presumably, though, this 
mandate also applies to everyday changes in 
content column sequence using {float: right} etc.


Their logic appears to be that a page is invalid 
if markup & presentational sequences differ among 
users; that the reading experience must be identical for all readers.


I find that premise to be extraordinary.  It's as 
though the success of mandating architectural 
ramps were insufficient and they now required the 
removal of stairs so that all users would 
experience the same entry into buildings.  Am I 
inadvertantly being insensitive, or is it over 
the top to make a single user experience 
normative?  Requiring one user experience for all 
suggests that different experiences must in some 
way be hierarchical, e.g. the visual presentation 
superior in some way to the markup sequence.  To 
the contrary, I commonly see developers marking 
up pages one way to be more functional for 
speech-browsers and styling them differently to 
be more attractive for light-browsers.  If the 
former functionality is not necessary for sighted 
users and the latter aesthetic appeal not 
applicable to unsighted users, surely neither 
party is missing out on anything they would need 
or want and therefore there is no sense in 
mandating an identical experience for both groups.


Web pages are of course flexible: there are many 
instances in which a page morphs either 
structurally or presentationally based on user 
action, for example pages of columnar content 
which font-resizing can reflow into 
vertically-stacked columns.  Perhaps the main 
purpose of parallel columns of content is to 
allow sighted users to select reading points 
quickly without having to scroll down 
sequentially through the content.  Providing an 
initial menu of headline links creates a similar 
experience for speech-browsers but needn't take 
up room in the viewport for light-browsers.  Different but similar, yes?


Curiously,
Paul
__

[1] "This describes the failure condition that 
results when CSS, rather than structural markup, 
is used to modify the visual layout of the 
content, and the modified layout changes the 
meaning of the content. Using the positioning 
properties of CSS2, content may be displayed at 
any position on the user's viewport. The order in 
which items appear on a screen may be different 
than the order they are found in the source 
document. Assistive technologies rely on the 
source code or other programmatically determined 
order to render the content in the correct 
sequence. Thus, it is important not to rely on 
CSS for a visual-only layout which differs from 
the source code or programmatically determined reading order."

http://www.w3.org/TR/WCAG20-TECHS/#F1

**
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] [Fwd: RE: [gawds_discuss] Expression Web Designer]

[Paul Novitski]

At 04:14 PM 5/18/2006, Peter Ottery wrote:


2) after i added the same amount of margin to each side of an element
in the visual view,  i switched to code view and it had written
   {margin-top: 20px; margin-right: 20px; margin-bottom: 20px;
margin-left: 20px;}
instead of 
   {margin: 20px}
so until they get that sort of thing sorted it seems to have some
pretty basic but fundamental shortcomings in constructing css.



I don't consider a lack of shorthand optimization to be a fatal 
flaw.  I don't often use shorthand properties in my own stylesheets, 
usually because I don't intend to specify all dimensions, preferring 
to stipulate the minimum necessary, and also because I often find it 
preferable to spell out individual properties for the sake of 
readability & searchability.


My experience with Microsoft's "helpful" software is not a glad one, 
and I have come to turn off most of their second-guessing 
routines.  To be candid, I should confess that I feel somewhat 
threatened by the introduction of a high-quality web page editor and 
am not overly eager for it to succeed even while I might 
intellectually celebrate its cleverness.  For my own sake, I want 
there to continue to be a need for human web crafters.  Does that 
make me merely the latest species of dinosaur?


How would we want optimization to work, exactly?  The example you 
cite, in which all (four) properties of a property group were 
specified, has got to be an exceptional circumstance.  I rarely 
specify all the properties in a group in my hand-coded 
stylesheets.  If you had explicitly changed only one or two of the 
group's properties, surely you wouldn't want the software to output a 
shorthand code.  To do so the software would have to assume that the 
unchanged properties had a zero value, whereas you may have intended 
them to be unspecified, perhaps to inherit from an ancestor or to 
give way to an earlier rule of weaker specificity.


I think that would be one of the greatest challenges of writing a 
decent WYSIWYG web page editor: how to differentiate between 
properties intended to have "zero" value from properties intended to 
be unspecified.  If Microsoft's new widget made CSS minimalism hard 
to achieve, I'd not be inclined to use or recommend it.


Regards,
Paul 


**
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] Validation Errors that don't exist - does the validator work?

[Paul Novitski]

At 10:14 PM 5/17/2006, Cole Kuryakin wrote:
I’m getting a number of errors from the W3C CSS 
validator that just aren’t there.

...
·   Line : 217 (Level : 1) You have no 
background-color with your color : a:visited

...

a:link, a:visited {
color: #CC3300;
background-color: transparent;
}



Cole, you're not the first to run into this:

W3C Bug / Issue Tracking Service
Bugzilla Bug 768
"Warn about background-color transparent"
http://www.w3.org/Bugs/Public/show_bug.cgi?id=768
from: http://www.w3.org/Bugs/Public/buglist.cgi?product=CSSValidator

If your client is twitchy about validator 
warnings (as contrasted with errors), show him 
that bug report and show him the spec:


Cascading Style Sheets, level 2
CSS2 Specification
14 Colors and Backgrounds
14.2.1 Background properties: 'background-color'
http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-color

(Although transparent is a legal value for the 
background-color property in CSS2, it's worth 
noting that the W3C Validator says that it 
validates for CSS2, not CSS2.1 which is the spec I rely on.)


Paul 


**
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] "Tables - you can still use them in web design" article

[Paul Novitski]

At 04:31 PM 5/16/2006, Andrew Cunningham wrote:
the real weak point of CSS layouts and the strength of table based 
layouts is that tables will handle UI mirroring while CSS currently doesn't.



Please elucidate.  It seems to me that you'd have to reverse the 
sequence of table markup going from LTR to RTL, and while you could 
do the same with CSS there's also the potential to reverse float 
direction and keep the markup the same, n'est ce pas?


Paul 


**
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] about css "pop up windows"

[Paul Novitski]

At 01:19 AM 5/14/2006, Breiterstrom [Cosmin Ciobanu] wrote:

Please take a look at my web site: http://www.cosmin-ciobanu.popconsulting.ro
The CSS is http://www.cosmin-ciobanu.popconsulting.ro/cssfolder/mystyle.css
I want you to study the portfolio page and tell me how do you think it looks.
I've used Only CSS rules, no JAVA script, for the windows that 
appears on mouse over on the ice thumbnails.
Is there a way to make that pop ups appear with some effects? Like 
fade in, for ex.?

Can anybody help me with a sugestion?



Cosmin,

For me your portfolio doesn't work:  when I hover over the menu of 
thumbnails, the larger screenshots appear in the same place and cover 
up the menu itself.  I find this very irritating.  It means that to 
view more than one screenshot I have to move my mouse completely out 
of the menu area and come back into it from another 
direction.  You're forcing me to use a lot of extreme mouse motion 
for no particular reason, and I think there's something fundamentally 
wrong about a user interface that covers itself up while the user is 
trying to use it.


The design is not only inconvenient, it's superfluous.  You have 
already allocated space on the page to display a thumbnail 
representing each portfolio item, however you're using the same ice 
image for each thumbnail.  That seems like a waste of space.  Why not 
put the website screenshots into the menu in the first place?  This 
doesn't make the hover images irrelevant -- it's OK to show a larger 
version of a thumbnail on hover.


Your menu design seems like an especially poor choice for a web 
designer's portfolio: I was not impressed with your ability to design 
a functional user interface and, at least on this basis, I would not 
be likely to approach you for help on a web project.  While I 
understand your desire to show off your abilities, I suggest you do 
so in a way that enhances functionality and doesn't detract from it.


My recommendation is that you use screenshot thumbnails for the menu 
itself and, on hover, display the larger screenshots on top of the 
big ice cube at left.  That way I could hover over different 
thumbnails until I found one I wanted to click on, and the thumbnail 
menu would remain usable throughout the selection process.


Regards,
Paul

**
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] content: ".";

[Paul Novitski]

At 03:50 PM 5/4/2006, =?GB2312?B?1qPT8ca8KFRlZSBHLiBQZW5nKQ==?= wrote:

Sorry for the ignorant, but what is this for? I saw it in someone esle
code sometimes ago and see it again in another site.

content: ".";

div {
content: ".";
clear: both;
}



It's the CSS 'content' property, explained here:
http://www.w3.org/TR/CSS21/generate.html#content

This whole document makes fascinating reading:

Cascading Style Sheets, level 2 revision 1
CSS 2.1 Specification
http://www.w3.org/TR/CSS21/ 


**
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] convert to XHTML

[Paul Novitski]

At 09:01 PM 5/3/2006, Stuart Sherwood wrote:
I'm wondering what is the best way to convert a large text file to 
XHTML? Preferably, I'd like the conversion to be performed to ignore 
styles, so the output is clean, semantic markup. I'd rather add my 
own stlying later.



I think it's impossible to say how challenging this would be without 
knowing anything about the content of the text file.  How organized 
and consistent are the content and styling?  What is there for a 
parser to grab onto?  What verbal and stylistic patterns can it 
orient itself by?  And what's the file format?


I love writing software that parses human language; it's the most fun 
of any programming I've done (which probably says something about my 
geek quotient).  Writing a parser for your document is probably going 
to be practical (cost-effective) only if it will be run repeatedly, 
say on a document that comes to you with fresh content each month, or 
one a single document that is truly huge.  If this is a small one-off 
job, it would probably be cheaper to do it by hand -- with the aid of 
macros perhaps, but not scripting the whole thing.


Any chance you can work with the originators of the document to 
change the way in which it's put together?  That could have an 
enormous effect on the parsing job, including potentially eliminating 
it altogether.


Paul 


**
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 placment

[Paul Novitski]

At 02:56 PM 5/1/2006, CK wrote:
At the following URI the navigation is in an unusual place, the 
"footer." Does this pose an issue, as the text will be tamed, 
keeping the design above the "fold". Also, the naming convention in 
the CSS, could it be more succinct?



http://working.bushidodeep.com/spring_2006/index_footerNav.php



I like the overall layout & graphic treatment.  With content this 
spare, the bottom placement of the nav menu doesn't seem vital for usability.


However, as I zoom larger in Firefox, the content cell grows 
vertically but not horizontally so the nav/footer sails downward and 
off the screen, and the nav menu text expands outside its fixed-width 
container.  Why not size your containers in ems and allow the layout 
to grow with a more consistent aspect ratio?  It would mean an 
expandable frame for your content, slicing it into pieces to enable 
it to grow horizontally and not just vertically, which would in turn 
mean a slightly more complicated markup.


Enlarging the font like that also makes it clear that the apparent 
centering of the nav menu in its box is spoofed; it only looks 
centered at a certain ("normal") font size.  I'd try for true 
centering so that it doesn't uglify.


With everything else centered, your subcontent menu looks mistakenly 
off-center.  Also, its text/background color contrast would probably 
fail WAI standards.  If it's your intention to obscure it or minimize 
its importance, why put it first in the markup and layout?


With regard to the succinctness of your markup & CSS, do you really 
need the div#header around your h1?  All you're doing with it is 
positioning it relative, which I'd think you could do with the h1 
itself.  Also I'd see if I could remove the divs from around the two menus.


Regards,
Paul 


**
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] Trubuchet MS font not showing in IE

[Paul Novitski]

At 05:16 PM 4/30/2006, [EMAIL PROTECTED] wrote:
I have a two test pages, they work great however I have noticed and 
oddity. I am goggling it now but so far found nothing that explains 
it. I don't work on a Mac, but on a PC.


On these page I used the font styles as such: font: 1em normal 
"Trebuchet MS", Arial, Helvetica, sans-serif;


FF see the Truebuchet MS font, but IE 6.029 will not. It refuses. 
Any idea why and is there a way around it other then just accepting 
that IE will not show my font of choice? Verdana is close, but too wide imo.


http://www.designbyatfb.com/designs/joetex/index.html 
only the home,(or logo) and about us links work.



Sharron,

Without having time to test, I wonder if your problem might have to 
do with the order in which you specify the font rules.  According to 
the spec [1], the font shorthand property takes these values:


[ [ <'font-style'> || <'font-variant'> || <'font-weight'> ]? 
<'font-size'> [ / <'line-height'> ]? <'font-family'> ] | caption | 
icon | menu | message-box | small-caption | status-bar | inherit


Your CSS rule:

font: 1em normal "Trebuchet MS", Arial, Helvetica, sans-serif;

provides an order of:

<'font-size'> <'font-weight'> <'font-family'>

Try resequencing these values (normal 1em "Trebuchet MS"...) and see 
if that helps.


Paul

[1] http://www.w3.org/TR/CSS21/fonts.html#font-shorthand

**
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] Setting focus in a form and screenreaders

[Paul Novitski]

At 05:45 PM 4/23/2006, Ian Anderson wrote:
But tabindex is horrendously cumbersome to apply in real sites - if 
you put it on one link or control, you really ought to put it on all 
of them on the page.


This is an interesting assertion.  It appeals to my sense of 
uniformity, but is it normative?  I can't find reference to it in the W3C spec.


Which does say:
__

"Elements that may receive focus should be navigated by user agents 
according to the following rules:


   "1. Those elements that support the tabindex attribute and assign 
a positive value to it are navigated first. Navigation proceeds from 
the element with the lowest tabindex value to the element with the 
highest value. Values need not be sequential nor must they begin with 
any particular value. Elements that have identical tabindex values 
should be navigated in the order they appear in the character stream.


   "2. Those elements that do not support the tabindex attribute or 
support it and assign it a value of "0" are navigated next. These 
elements are navigated in the order they appear in the character stream.


   "3. Elements that are disabled do not participate in the tabbing order."

Ref.: http://www.w3.org/TR/html4/interact/forms.html#h-17.11.1
__

Therefore, if you DID feel compelled to add a tabindex attribute to 
every input field, but wanted to begin with one field and progress 
thereafter in markup order, you could simply assign tabindex="0" as a 
default to all fields and assign tabindex="1" to the one field where 
you wanted to begin.



And as soon as you make the tab order different from the visual 
reading order, you have created a whole raft of different problems 
for other users.


If a whole raft of problems are created by assigning tabindex to even 
one field, then I guess this whole discussion is moot.  However, I'm 
not persuaded that that's the case.



Not to mention a maintenance nightmare in the future as options are 
added or removed.


Not really for me -- I generate my pages from server-side script 
which just LOVES busy-work like assigning incremental values to 
sequences of objects.




tabindex is a complete pain in the bahookie, in other words


...for manual work, perhaps.  But if it's a viable method for 
bringing focus to a starting field in a form and works well with 
Jaws, I'll definitely keep it in my toolbox.



By the way, I'd like to add that the JavaScript solution of assigning 
focus() on pageload that we hate so much could be made smarter and 
more polite:  it could assign that focus to the starting field IFF no 
other input field held focus AND nothing had been typed in the starting field.


But the advantages of tabindex remain that it's effortlessly 
unobtrusive and it functions in the absence of client-side scripting.


Warm regards,
Paul  


**
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] Setting focus in a form and screenreaders

[Paul Novitski]

At 03:21 PM 4/23/2006, Patrick H. Lauke wrote:

On a side note, I personally find sites that
take away my control and "helpfully" focus a form field for me very
irritating...



This is a pet peeve of mine as well.  I assume that it's perpetrated 
by web developers too busy showing off their JavaScript skills to 
read the HTML spec.


Why isn't it enough to use tabindex?
http://www.w3.org/TR/html4/interact/forms.html#h-17.11.1

Can anyone say whether Jaws' response to tabindex="1" is satisfactory 
or differs from the JavaScript focus() approach?


Paul 


**
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] [sitecheck] http://new.hopkinsprogramming.net/

[Paul Novitski]

At 10:06 AM 4/22/2006, Hopkins Programming wrote:
Hey, while I've got it on my mind, would you all mind taking a look 
at my newest website design that is set to go live on May 1st, 2006 
for the Spring CSS Reboot?


You can see it online at 
http://new.hopkinsprogramming.net/.
It is pretty much finalized, except for the Client Login area, and 
some additional text on the home page.


Please let me know what you think of it in terms of graphics, 
standards, semantics, and whatever else might come to mind!



Just one quick note:  your nav menu at top and your links menu at 
left teach us how to use your interface: that to active a link you 
hover over the big graphic box.  Then the main link in your content 
area (CSS Reboot) fails to follow through.  The graphic box isn't a 
link, and what appears to be hyperlinked text at right is merely an 
acronym.  It took me a moment to discover that the headline was the 
link.  Not obvious, because it's styled identically to the other 
non-link headlines.  I didn't notice till after that discovery that 
it's got a little 'external link' graphic next to it; ignored at 
first perhaps because my peripheral vision mistook it for a 
registered trademark symbol or sumthin' -- and because my experience 
with the web in general and your page in specific hadn't prepared me 
to expect a vanilla-looking headline to be a link.


Therefore I'd say that your user interface design lacks coherency of 
vision.  See if you can strip out at least one of those conventions 
(if not two) and make your usage more uniform in order to make your 
page more intuitively obvious.


Regards,
Paul 


**
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] Div DHTML Effects

[Paul Novitski]

At 07:29 AM 4/20/2006, Joseph Bernhardt wrote:
If you have an easier way I would love to hear it!  Keep in mind I 
wish to keep this cross-platform compliant.  Correct me if I am 
wrong, but aren't the background image and color basically the same 
thing?  They can both be changed through the CSS background: 
attribute.  Lemme know what you got!  Thanks!


BTW:  What I was doing is located at 
www.joughslife.com/Rockport.html - notice what the links on the 
right side of the page do onmouseover?  I didn't want to make the 
div change color on hover because the div itself is not a link.



Jough,

You can do exactly what you want to do by styling the anchors 
themselves: make them {display: block} and then you can assign them 
height & width like you're doing with your divs now.


Plus they'll have an advantage over your current system:  the hover 
effect will occur when you're anywhere within the block, not just 
over the hover text itself.


Listamatic is fun!  Check it out:
http://css.maxdesign.com.au/

Paul 


**
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] Single or Double Quotes

[Paul Novitski]

At 09:39 PM 4/19/2006, Richard Czeiger wrote:

What's the consensus on this one?
Should you use single or double quotes for background images in your CSS?

background-image: url('image.jpg');

or

background-image: url("image.jpg");

And here's the real question: why?



Single quotes, double quotes, and no quotes are all legal (see 
below).  I use double-quotes myself, mostly I suppose to be 
consistent with other resource pointers in my work such as anchor 
href and image src.


Paul


W3C  CSS 2.1 Specification
4 Syntax and basic data types
4.3 Values
4.3.4 URL + URN = URI
http://www.w3.org/TR/CSS21/syndata.html#value-def-uri

excerpt:
_

URI values in this specification are denoted by . The functional 
notation used to designate URIs in property values is "url()", as in:


Example(s):

body { background: url("http://www.example.com/pinkish.png";) }

The format of a URI value is 'url(' followed by optional whitespace 
followed by an optional single quote (') or double quote (") 
character followed by the URI itself, followed by an optional single 
quote (') or double quote (") character followed by optional 
whitespace followed by ')'. The two quote characters must be the same.


Example(s):

An example without quotes:

li { list-style: url(http://www.example.com/redball.png) disc }

Some characters appearing in an unquoted URI, such as parentheses, 
commas, whitespace characters, single quotes (') and double quotes 
("), must be escaped with a backslash: '\(', '\)', '\,'.


Depending on the type of URI, it might also be possible to write the 
above characters as URI-escapes (where "(" = %28, ")" = %29, etc.) as 
described in [RFC3986].

_

**
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 "detect" bottom of a page?

[Paul Novitski]

At 06:57 PM 4/19/2006, Bojana Lalic wrote:
I am working on a print stylesheet. What I need to do is display a 
url at the bottom of the last page.


I understand that this can be done with CSS3 "float: bottom;" but is 
there another way of doing this?



I wonder if you can simply mark up the URL at the bottom of your HTML 
page, then suppress it from screen display if desired.


Paul 


**
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] Div DHTML Effects

[Paul Novitski]

At 08:00 AM 4/19/2006, Joseph Bernhardt wrote:
I have a  with the background color of white.  I want to change 
the background color of that  through the onmouseover event on 
a  within the div.



Joseph, depending on the complexity of your application you may not 
even need scripting to do this, instead just CSS:



Toad


CSS:

div#frog a
{
display: block;
width: 20em;
height: 10em;
background-color: #FFF; /*white*/
}
div#frog a:hover
{
background-color: #F00; /*red*/
}

This utilizes the mouseover engine that's already built into the 
browser and eliminates a bit of extra baggage you're currently 
tacking on.  If you have other tasks to perform with JavaScript and 
want to change the element style at the same time, consider changing 
it by changing its className, then storing all the style details in 
your stylesheet.  That way you don't have to mess with your script to 
make cosmetic changes.


Paul 


**
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] Markup for an FAQ?

[Paul Novitski]

At 01:23 PM 4/17/2006, [EMAIL PROTECTED] wrote:

I'm marking up an FAQ for an XHTML 1.1/CSS Web page. What is the best way
to mark up the questions and answers so it will be semantically correct
and standards compliant?

Right now, the FAQ is in a table-based format using a numbered list.



If you don't need them numbered, I'd suggest DL:


Question
Answer

Question
Answer
Answer
(or:)
Question

Answer
Answer

...


If you need the items auto-numbered, I'd go OL:


Question
Answer


Question
Answer
Answer

...


Paul 


**
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] Definition List for Products/Items with Image

[Paul Novitski]

At 12:00 AM 4/5/2006, Richard Czeiger wrote:
After all, SOMETHING has to go in the  and it makes sense to 
make it the one thing that is MOST appropriate.
Taking your logic to the nth degree you might as well put everything 
in a .



Not really -- if everything's in DTs there's no point in using the DL 
in the first place; you might as well use an unordered list.  As you 
know, the DL has at least these advantages:


1) its semantic structure is that of a list of item/description pairs 
which matches up well with many of the lists we present;


2) it's an HTML list with two types of child element, making it easy 
to style them differently without using classes.  Unlike OL and UL, 
each DL list item can consist of multiple DT and DD tags, increasing 
the markup & styling possibilities.


When you're marking up a literal dictionary you usually know which is 
the term and which is the definition: the term is usually the short 
one, is usually listed alphabetically, and usually comes first; the 
definition is usually longer, is usually not alphabetical, and comes 
second.  Or the term is in vocabulary A and the definition is in 
vocabulary B.  The definition is often thought of as describing the 
term, but really they describe one another, collaborating in a common 
web of meaning.  Which is the DT and which is the DD depends on the 
author's purpose for the list and their perspective on its content.


With other types of collection that stray farther from the 
"dictionary" model, it's my assertion that which term goes in the DT 
and which in the DD can be even more arbitrary.  If you're marking up 
a collection of items in which no one element is definitively The 
Term but instead in which several items collaborate to form a single 
gestalt, then yes, you could put more than one item in DT and/or more 
than one item in DD.  (Multiple DTs are common even in literal 
dictionary lists, as illustrated in the W3C spec.)


Even a "description" can be a DT:

DT a large, quadrapedal, grazing ungulate
DD cow
DD deer
DD horse

If you'll grant me that flexibility, then I'll conclude that it's not 
incorrect to freely choose the one item for the DT that will make 
styling the list a breeze:


image   title
description
price

Doesn't the title describe the photo as much as the photo describes the title?


True: A photograph isn't a 'definition' but it's also not the 
primary identifer for most scenarios outside a Photo Gallery. The 
reason I know this is because if you pointed me to a URL and I first 
asked what I'd see there, you'd tell me "its a Mbira Dzavadzimu", 
you might even say "its a photo of a Mbira Dzavadzimu" if it was an 
especially spiffy photo but you wouldn't just say "a photo" which is 
exactly what  is interpreted as. It's technically correct but 
not especially helpful. Textual data, in this case and most others, 
seems to be the most appropriate way of initially identifying an 
object/concept, at leats in the telecommunciations medium.


No, I wouldn't likely say "a photo" any more than I would say "a 
headline."  An IMG tag by itself doesn't convey much meaning, but 
neither does H1 or P.  It's the content of those tags that conveys 
the most useful meaning to us.


What I hear you saying is that the crucial difference between text 
and image in this context is that text can be encoded in a defined 
character set and is therefore parsable but images are transmitted as 
bit-streams without a similarly simplistic symbolic encoding and are 
therefore unparsable.  I can imagine this argument for machines -- 
although image-search engines are going to blow that one out of the 
water in the next few years -- but more to the point when sighted 
humans look at a page they read, comprehend, and remember the 
meaning, content, and context of both the images and the text.  If 
I'm bookmarking pages about mbira I'll grab the ones with photos and 
drawings and scans of musical transcriptions as well as the ones with 
plain text.


According to your argument (I think), if I scan in text or produce it 
in Photoshop, then the meaning of that text is lost and it no longer 
qualifies as something that can go in a DT, unless the DL is, say, a 
gallery of font samples.


Imagine browsing through a catalog in which the webmaster has used 
Photoshop to render the product names as images of text but failed to 
provide alt attributes: you're still reading the text if you're able, 
it's just not ASCII-encoded.  Do the product names no longer go in 
the DT because of the method used to render the text?  But then if 
you add alt attributes they can go back in the DT?  Hmm.


I feel that an image can be a term to be defined even when it's a 
photo or drawing of a product in a catalog.  Imagine browsing through 
a clothing catalog: you see an outfit that catches your eye, then you 
read the item's name and description.  The text defines and describes 
the image.  Imagine you're lo

Re: [WSG] Definition List for Products/Items with Image

[Paul Novitski]

At 05:37 PM 4/4/2006, Richard Czeiger wrote:
In your example, "Chien", "Perro", "Inu" are representations of the 
concept of 'dog' and therefore would fall  into the category of 
signifiers ().
True: a photograph is not a definition of a dog, however, a 
photograph of a dog is not the dog itself, but rather a repsentation.



You guys crack me up!  You seem to be saying that, of all these 
signifiers -- "dog," "chien," [doggy photo], etc. -- it's the one 
that is most like a dog, or mostly IS a dog, that deserves to go in 
the DT.  What, you think the word "dog" is more like an actual dog 
than a photograph of a dog?  Doggone it, the word "dog" is no more a 
dog than a potato chip.  For proximity to the real thing, I'll put my 
money on the photograph of the dog which is at least a direct 
physical reflection of an actual dog.  Words like "dog" and "chien" 
are just indirect reflections of dogs in the murky, ripply human pond.


Until you figure out how to get an actual dog into a web page, all 
you have to work with is one representation or another.  There is no 
real dog on the page, you know, so all your dictionary list is doing 
is defining one symbol with other symbols.  You use DTs to say, "Here 
are some things you may not understand that I'm about to explain with 
the following ddefinitions."  In one dictionary list, "dog" will be 
the DT and "chien" will be the DD.  In another, [fidophoto] will be 
the DT and "My dog Binky" will be the DD.  It all has to do with what 
you intend to elucidate.


So here I've got a collection of items:

- photograph of a Zimbabwean mbira
- the title "Mbira Dzavadzimu"
- the caption "Hand-crafted by Fradreck Mujuru, Harare, 2005"

Does the title help define the photograph or does the photograph help 
define the title?  Does seeing the photo of the musical instrument 
help explain its name, or does its name help explain the 
photo?  Both, of course: they both contribute in different ways to 
our understanding of the whole.  Whether I write:



Mbira Dzavadzimu
Hand-crafted by Fradreck Mujuru, Harare, 2005
or:
Mbira Dzavadzimu

Hand-crafted by Fradreck Mujuru, Harare, 2005

the communication is nearly identical, and the difference so obscure 
as to be practicably irrelevant to the glossary of musical 
instruments or the product catalog or the website portfolio we're presenting.


Now, don't come whining to me that you can't put an image in a DT 
because an image isn't a "term."  Dang it, a photograph isn't a 
"definition" either.  We're using a semantic structure to help make 
metaphorical sense of information, fer crying out loud.  Don't be so 
gol-darned fiddly that you spend hours trying to figure out how to 
float one DD to the left and the DT and all the other DDs to the 
right!  Put the gol-danged image in the DT, float it left, and you're 
done.  Get on with your lives, now!  Scoot!


Your ornery ole Pa  


**
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] Definition List for Products/Items with Image

[Paul Novitski]

At 11:13 PM 4/3/2006, Samuel Richardson wrote:
Absolute positioning should position from the top/left of whatever 
absolute element is containing it, usually this is the body.


A parent can have either absolute or relative positioning to provide 
positional context for an absolute child.




Daniel Nitsche wrote:
I had a quick go, and this is what I came up with (assuming a 
100x100px image):


Product title
Product description - this can be as long as you like



dl { position: relative; }
dl dt { margin-left: 110px; font-weight: bold; }
dl dd { margin-left: 110px; }

Re: [WSG] Definition List for Products/Items with Image

[Paul Novitski]

At 04:49 AM 4/3/2006, Micky Mourelo wrote:

I always use a DL when dealing with scenarios like the one on
juniperwebcraft (photo with title and desc) but I do not find right to
have the image as a DT as I think the image is not what you are
defining, but the title you have as a DD, so I put the image on its
own DD or inside the desc text DD, and then position it on the left;
it's a little bit trickier  css wise but more semantic IMHO.



In a website portfolio, is the screenshot thumbnail one of the 
definitions of the website title?  Or is the textual title one of the 
definitions of the website itself as represented by the screenshot?


I can scrunch my brain around both perspectives, but I feel quite 
secure in the latter.


In a photo gallery, my first inclination might be to set the 
thumbnail as the term and the caption its definition, but I can 
easily imagine image sets where the reverse makes more 
sense.  Perhaps it depends on the purpose of the list, or one's sense 
of poetry & metaphor.


Regards,
Paul 


**
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] Definition List for Products/Items with Image

[Paul Novitski]

At 08:31 PM 4/2/2006, Richard Czeiger wrote:
Wondering if anyone has recommendations/code for a cross-browser 
solution to the following scenario..


There's a list of products/items that have the following characteristics:

Product Title
Product Image
Product Description
Possible Additional Information (let's say 'Price' or something)...

I'm thinking a Defintion List would be the way to go right?
Should the Image be a DT or a DD?

How would you style it to acheive the following layout?
www.grafx.com.au/wip/productList.gif



Richard, I believe this is what you're describing:
http://www.juniperwebcraft.com/what_websites.php

I've got the image in the DT and some descriptive text in consecutive 
DDs.  (I may change this to a single DD containing several Ps 
depending on which hemisphere of my brain ultiamtely wins that argument.)


Both DT and DD are floated left; DT also clears the float for each 
new item.  The width of both elements is defined, and DD is given a 
margin-left sufficient to keep it in its own column and not let it 
wrap around the DT.


It works in all my PC browsers (Firefox, IE, Mozilla, Netscape, and 
Opera) and according to browsercam works in current Mac 
browsers.  Looks like my stylesheet needs tweaking for IE 5.x, but it 
doesn't look serious.


Regards,
Paul  


**
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] Including CSS with JS

[Paul Novitski]

At 12:52 PM 3/29/2006, CK wrote:

While ogling the code of a favored site, it was discovered the CSS
was served with a JS function using document.write. What if any
advantage does this method offer. It was my humble observation, that
this could invite failure if JS was disabled, but using  or
@import would still "serve" the CSS.



In addition to it failing if javascript is disabled or not supported, 
it's incompatible with XHTML (should you go there).


What's the purpose of the logic?  If it's intended to serve different 
CSS to different browsers, then it's probably basing its decision on 
HTTP-Referer-sniffing which is arguably less reliable than basing the 
same kind of decision on browser capabilities.  You might be able to 
accomplish the same end more reliably by using one of the 
browser-specific rules listed here:

http://www.dithered.com/css_filters/css_only/

Paul 


**
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] clearing floating divs using

[Paul Novitski]

At 01:03 PM 3/27/2006, Julián Landerreche wrote:
Is there any information about (or advice 
against) using  to clear floating divs?



Good thinking, Julián.

I think it's a small but measureable improvement 
over using  to clear floats which has been my guilty indulgence.


One objection I can raise is that I can easily 
foresee the need to clear floats in places where 
dividing lines wouldn't make sense in a text 
document.  Then, if you add lines between minor 
elements merely to clear floats, do you need to 
add more, perhaps heavier, lines between major 
elements so that the minor separators aren't 
given too great a significance by the text-only 
reader?  Could be a slippery slope.


Using either  or  to clear floats 
still amounts to adding extra[neous] markup to a 
page for the sake of styling that you wouldn't 
add for its semantic sensibility, and many 
designers will eschew it for that reason alone.


Regards,
Paul 


**
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] Forward-slash suppresses word wrap in Windows IE

[Paul Novitski]

At 07:04 AM 3/22/2006, you wrote:

Paul Novitski wrote:
> Ah hah -- it took me a minute to see why this was working for you but
> not for me.  I'm using an XHTML Strict doctype and you're using HTML
> Transitional.

I think it is worse than that; my page puts IE in Quirks mode. I've used IE
to save a copy of your original document and it saved it with that broken
DTD. I only noticed this after you mentionned you're using a Strict Doctype
:-(


You know, I've been using XHTML Strict served as text for the past 
year or so because it's given me such beautifully consistent results 
cross-browser, but I think I'm finally about to yield to the 
arguments that that doctype is self-contradictory.  I want to use 
Strict but I'm reluctant to stop using XHTML-style markup.  What's 
your personal recommendation?




> Also, you were omitting the space before each slash.

That was on purpose. It was to show that the line breaks at the  with or
without the space in there. That technique could be used with long strings
of characters like URIs that would break just before the "/" for example (or
anywhere the author choose). I thought that was interesting.


I think it's great!  Seems like a good solution for wrapping URIs 
which comes up as a problem constantly on the listserves I belong to.


I'm really curious to learn why the Microsoft programmers coded IE to 
suppress word wrap with whitespace-slash.  I haven't found it [yet] 
documented on the MS website which makes to doubt that it was 
deliberate.  If it's accidental, it might have been logic that 
spilled over from another part of the parser, such as XHTML /> 
end-tag parsing, but that doesn't quite wash since the interior of a 
tag would only need to be parsed (and excluded from textual 
rendering) until the final >.  I think I'll bring it to the attention 
of the IE7 team just in case one of them can remember how it got that way.


Warm regards,
Paul  


**
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] Forward-slash suppresses word wrap in Windows IE

[Paul Novitski]

At 05:36 PM 3/21/2006, Thierry Koblentz wrote:

"Lorem /ipsum" seems to work for me:
http://www.tjkdesign.com/lab/paul.htm
I've removed the width on the P elements so you can better see how the line
breaks before each .


You scripted:
Lorem/ipsum/dolor...
* html i {height:0}

Ah hah -- it took me a minute to see why this was working for you but 
not for me.  I'm using an XHTML Strict doctype and you're using HTML 
Transitional.


Also, you were omitting the space before each slash.

When I come up for air after my current work crunch I'll document 
this little byway of Explorer dysfunction more thoroughly.


Regards,
Paul  


**
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] Forward-slash suppresses word wrap in Windows IE

[Paul Novitski]

At 03:22 PM 3/20/2006, Thierry Koblentz wrote:

What about:
HTML:


CSS:
* html i {width:0;overflow:hidden}



Alas, it doesn't solve the word wrap problem.  For these purposes, IE 
renders these expressions identically:

Lorem /ipsum
Lorem /ipsum
Lorem /ipsum
Lorem /ipsum

regardless of how they're styled, as far as I've been able to discover.

What DOES work is to insert some arbitrary content into the I tag, 
then suppress its size:

Lorem  /ipsum
i { font-size: 0px; }

See http://juniperwebcraft.com/demo/slashwrap.html for illustrations.

Paul 


**
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] Forward-slash suppresses word wrap in Windows IE

[Paul Novitski]

At 10:49 PM 3/20/2006, Lea de Groot wrote:

Paul Novitski wrote:
In Windows IE, a forward-slash (virgule) that follows whitespace 
suppresses word wrap:

http://juniperwebcraft.com/demo/slashwrap.html


Probably a foolish suggestion - have you tried replacing the slash 
with a character entity?

/ or /



Thanks Lea, but replacing the slash with an HTML entity doesn't have 
any effect.  I've added this test to my demo page in IE:

http://juniperwebcraft.com/demo/slashwrap.html

Paul 


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

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