Re: [WSG] Recommended screen size
At 5/31/2007 08:31 PM, Tim Offenstein wrote: Anyone have a recommendation on what size screen to use as a baseline when designing for a new site? 800x600 or 1024x768 or something else? Ideally, I believe the baseline should be no assumption of screen size. Look at the spectrum of user agents: screen readers, Braille readers, handhelds, PCs, Macs, etc. Which populations of users will you choose to deny access to your sites? Design your sites so that they can be read on any of these devices and you'll be at the top of your field. Sure, read the stats, but don't misinterpret them. They won't really show you who to target. All they'll show you is how many people you can exclude by building fancy stairs and no ramps. Even if you could predict the screen size of a visual user agent, you still wouldn't know how large the user will size their browser window. Window size is more significant than screen resolution. A lot of PC users (including myself) maximize their windows by default, but that's by no means universal. For some interesting stats analysis see: Actual Browser Sizes by Thomas Baekdal http://baekdal.com/reports/Actual-Browser-Sizes/ Even if you could predict screen size and window width, you still wouldn't know how large the user has sized their text. How easy is it to enlarge text so that it spills out of your column widths, overlaps with other text or disappears off-screen, and becomes unreadable? With ingenuity you can design a page that works well with a wide variety of window widths and text sizes. Consider sizing page width in ems and max-width at 100% to let the page expand up to but not exceeding window width. Consider floating columns side-by-side so that they stack vertically when the window is too narrow for a multi-column layout. There's much, much more, but that's a start. I strongly recommend you join the CSS-D listserve and read their wiki: http://css-discuss.incutio.com/ 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] Recommended screen size
Earlier I was suggesting that, instead of stats telling us who to target, they really tell us who to exclude. A fellow poster wrote: my blog 800x600 accounts for less than 2.5% of the traffic That poster appeared to be advocating for leniency, but let's take this example of screen resolution stats and turn them around. Let's say his stats apply to your website audience as well. 800x600: 2.5% = 100/2.5 = one in 40 visitors uses 800px-wide screen resolution (window width not mentioned). Let's say you design your site to look good at 1024 but crappy at 800. Every 40th visitor, on average, will have a bad experience. Is this what you want? Ask yourself not how many people you want to have a good experience on your site but rather how many people you want to have a crappy experience. What's your expected site traffic? 100 visitors a day? So two to three people every day will have a crappy experience on your site. 1,000 visitors a day? About 25 people every day will have a crappy experience on your site. 10,000 visitors a day? About 250 people every day will have a crappy experience on your site. Why would anyone want this? Why do web designers even think this way? For the most part, I think, they don't. They read the stats the other way around: they think, oh, great! 97.5% of my users will have a good experience! And they stop thinking there. Instead of trying to solve the problem they're relieved that the problem can be expressed as such a small number. Instead of thinking, "How can I make this work for everyone?" they're thinking, "Can I make this work for most?" "What's the cost of expediency?" "Can I afford to piss off a few people in order satisfy a lot?" So they don't actually perform the thought-experiments that lead to innovation and new design. This, I believe, is where you come in. 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] Recommended screen size
Paul Novitski wrote: >>Every 40th visitor, on average, will have a bad experience... >>800x600: 2.5% = 100/2.5 = one in 40 visitors uses 800px-wide screen resolution (window width not >>mentioned). ... At 5/31/2007 11:32 PM, kevin mcmonagle wrote: These visitors probably wouldnt notice the difference between an 800 and 1000 wide layout. So you're saying that someone using an 800-pixel-wide monitor probably wouldn't know what it's like to see the same page with a 1000-pixel-wide monitor? And therefore they don't deserve to see a decent page? What's your logic, and where's your compassion? In school the teacher has to teach for the dumbest kids in the class and that ruins it for everyone else. Oh, I see. So from your perspective life is really like an elementary school classroom, and we're really like little ten-year-olds pouting because we're too spoiled and lazy to advance ourselves when the teacher is paying attention to the stupid, mute, blind, and crippled kids. Oh my god. You're advocating a paradigm in which we can win only if someone else loses. "There ain't enuf pixels on this ranch fer the two of us, Jethro!" *Pow!* *pow!* *splat!* Unless, of course, it's possible that intelligent design can provide a decent page for everyone. That, however, requires a real winner. It takes the motivation to make everyone succeed and the intelligence to figure out how to make it work, the compassion to care about people different from ourselves and the brilliance to find solutions where others have failed. Are you up for the challenge? 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] ***
list etiquette [WAS: Re: [WSG] Recommended screen size]
At 6/1/2007 07:38 AM, Chris Williams wrote: "...the teacher is paying attention to the stupid, mute, blind, and crippled kids." Well, Mr. Compassion for the User... "stupid", "mute", "blind", "crippled"? Nice choice of words... Yes, I chose those offensive words deliberately to point up the attitude of the person to whom I was replying, who wrote, "...the dumbest kids in the class" However, I apologize to Kevin and to the list for posting such inflammatory sarcasm. I'm glad that folks are ignoring it and getting on with business. Warm regards, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommended screen size
n from a horizontal sequence to a vertical sequence. Both of these scenarios dramatically alter the original graphic design of the page, but that's inevitable if one is to avoid horizontal scrolling. A page that's engineered to survive text enlargement this way will also survive display in a wide variety of window widths (and screen resolutions). Obviously there are limits to accommodation: if you enlarge the text until a single long word won't fit in your window width, horizontal scrolling or hidden text is inevitable. It's my job to minimize those effects. I'm not too worried that a page optimized for 1024 will look very different, even homely, at 800 or 600. Readability comes first, layout second. At times this seems to put me at odds with graphic designers, but really I'm just trying to help them reach the audience with as much of their vision intact as possible. 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] Recommended screen size
At 6/1/2007 07:29 PM, Katrina wrote: However, the proactive stances also accepts that position is about to undergo a 360 degree change, with the advent of mobile devices with access to the internet. The iPhone will have a huge impact, not just because it can access the internet, but because it can access the internet with Safari, a HTML browser. And of course, the iPod have shown us just how 'cool' Apple gadgets are, and how quickly they are adopted. Kat, I appreciate your comments on proactive vs. reactive web engineering. Fortunately we can aim stylesheets specifically at handheld devices, at least. It's that enormous spectrum of larger monitors that are lumped together as one (media type "screen") that give designers such headaches. 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] layout/font site test - please
At 6/2/2007 03:06 AM, Designer wrote: Sparked partly by the recent discussions on elasticity, I've been attempting to put together a 'template', based on em's and with a max-width. I've used an expression for max-width in IE <7 (pinched from Georg!). I've tested it in FF1.5, IE6 IE7, Opera 9, and Netscape 4.02. To accommodate the latter I've used a simple table instead of floating, but ignore this please - my main concern at this point is that the basics work without falling apart in other browsers. If you have time to do a check and comment I'd be really grateful. The links are dummies, apart from 'projects'. You can see it at: http://www.marscovista.fsnet.co.uk/newtemplate/template.html Nice work! In FF2 I can narrow the window to about 348 pixels before I get a horizontal scrollbar. IE7 doesn't support text enlargement very well. I'm getting a horizontal scrollbar as soon as I start enlarging the text, even when the apparent content width doesn't require it. I've been wrestling with that in my own layouts; I'm sure the solution is close at hand. Did you experiment with floating the menu so that it flips underneath the content (or vice versa) when horizontal space is constrained beyond a certain point? I imagine that will be necessary to support people who want three or more columns. You chose a background image for the header that nicely repeats horizontally as the page expands. To be more versatile I think it ought to repeat vertically as well to support high enlargement in modest window widths. Real world logos are most often single fixed image rather than a repeating pattern, but in many cases it's easy enough to fade them to monochrome to the right and below or blend them to a lower-level background image that does repeat (such as a gradient). If you size the cartoon in ems as well, I think you might be pleasantly surprised at how well it survives. Tedd Sperling has been doing a lot of that lately (<http://sperling.com/examples/zoom/>) and it seems to work pretty well -- as long as the crispness of the images isn't crucial to the communication, as it might be for a photographer's or artist's website. 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] layout/font site test - please
Paul Novitski wrote:
You chose a background image for the header that nicely repeats
horizontally as the page expands. To be more versatile I think it
ought to repeat vertically as well to support high enlargement in
modest window widths.
At 6/2/2007 11:08 AM, Designer wrote:
I think I'm too tired. I simply can't get the thing to repeat on
enlargement. I've put it in a div and put it as the background
there, but it still won't go vertical as well. I'm Confused! It's
123 by 236px in size. Maybe it's too high for this.
You must be tired! I can totally relate to that. Your stylesheet says:
#header {background : #830 url(../graphics/fencing.jpg) repeat-x left top;}
Change "repeat-x" to simply "repeat" to go both directions.
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] layout/font site test - please
At 6/3/2007 08:36 PM, Felix Miata wrote: http://mrmazda.no-ip.com/auth/Sites/ksc/dancesrqb.html is the same basic layout, but without breaking IE's font resizer, with no special treatment for antique browsers, and without disrespecting the visitor's choice of font size. In Firefox 2, when the window width becomes too narrow and/or the text size becomes too large to allow the headline "The Dancer's Product Resource" to fit on one line, the headline wraps around with such a high line-length that the new line overlaps the content below the header. 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] layout/font site test - please
> At 6/3/2007 08:36 PM, Felix Miata wrote: >>http://mrmazda.no-ip.com/auth/Sites/ksc/dancesrqb.html On 2007/06/04 01:41 (GMT-0700) Paul Novitski apparently typed: > In Firefox 2, when the window width becomes too narrow and/or the > text size becomes too large to allow the headline "The Dancer's > Product Resource" to fit on one line, the headline wraps around with > such a high line-length that the new line overlaps the content below > the header. At 6/4/2007 09:13 AM, Felix Miata wrote: The question remains what, if anything, to do about that missing H1 content. One option is to simply dismiss it as a problem of inadequate consequence. As grounds to support this option: 1-Its title text contains the missing portion. 2-It's really only a subtitle to the real title contained in the graphic. 3-The dearth of people who actually need such giant text in proportion to the viewport width would likely be satisfied that the meat of the page is fully accessible. Another option would be to use JS to remove the graphic, reduce H1 font-size, and/or remove the added H1 letter-spacing when some chosen ratio of font-size to viewport width is found to be exceeded. Sorry, I don't see the problem. Why not simply allow the header block to naturally expand vertically when the headline wraps? The fact that the header contains both text and image isn't a show-stopper. In a case like this when the image has a monochrome background (here, white), simply apply that background color to the header block and position the image as desired (left top, left center, etc.). If the logo has a more complex background, simply extend the image to the side and below to give it a chance to fade to a repeatable monochrome or gradient which can be a repeating background image of its container. Here's a simple example: http://i-edu.org/ 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] ***
[WSG] reading the spec [WAS: Use of Fieldsets other than in form?]
At 6/4/2007 07:22 PM, Steve Green wrote:
Day after day in this forum some people seem to be hell-bent on abusing the
standards like this? Why?
I think the 'why' is important enough to merit mention; it's not just
a rhetorical question.
Most of us are trying to create the most sensible pages we can. To
do so we're using an incredibly sparse markup language with a few
very specific elements, a few vague ones, and enormous gaps between them.
We've all wished fruitlessly for HTML to support our efforts to mark
up content more semantically, and we're always looking for better
ways to do it. No wonder there are surges of effort to create the
next generation of HTML.
Some elements of markup must be taken quite literally ("horizontal
rule") while others are quite loose and metaphorical ("span"). Human
language at its very essence is metaphor. Depending on how you
squint at it, the spec can be read very loosely (the road to ruin) or
very strictly (the road to the padded cell). While the DTD is strict
in its stipulations of which elements can contain which others, the
spec's verbal descriptions of markup elements and the examples given
are often interpetable from a variety of angles, as we see every day
in this list. There's lots of wiggle-room in the HTML spec for
wishful, well-meaning web developers to seek elements that can be
comfortably stretched to cover a usage that might not have occurred to others.
I often wonder what the authors of the HTML spec feel when they
observe us web developers arguing over usage. A certain pride, for
sure, but also perhaps some embarrassment... on our behalf or their
own? So often we treat the document like it's a holy writ passed
down from on high, while it's really just a document written by some folks.
The description of the definition list is a prime example. Few of us
question the meanings of the words "definition" and "list" and yet
the atuhors of the HTML spec opened the door wide, first using the
alternative term "description" for the DD and then adding, "Another
application of DL, for example, is for marking up dialogues, with
each DT naming a speaker, and each DD containing his or her
words." The authors explicitly encouraged us to interpret the
element name "definition list" to include structures that are not
strictly definitions and even arguably lists. If a dialog can be
marked up as a list then why not use an unorderd list markup for a
series of paragraphs? (Please don't misunderstand me -- I'm not
arguing here that we ought to do so, I'm merely sketching the anatomy
of our disagreements.)
The vast majority of the debates of markup usage and semantics I read
-- and take part in -- turn on this very point: how metaphorically
may we interpret the spec? I have sympathy for those who want to
stretch the small, threadbare blanket of HTML to try to cover our
broad work; and I have sympathy for those who argue that a consistent
interpretation of the spec is necessary to build a solid body of
markup for the content-parsers of today and the future. We are all justified.
Perhaps our debates would be kinder if we ruminated longer on our
shared plight: abandoned on a barren planet with only fifty kinds of
parts with which to build everything we need.
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] Re: Use of Fieldsets other than in form?
At 6/5/2007 05:54 AM, Nick Fitzsimons wrote: It's only valid "by the DTD" in the sense that the DTD is incapable of expressing all the constraints imposed upon the usage of HTML elements; those constraints are made explicit in the spec by such means as the sentence you originally quoted. Hi Nick, I agree with most of the arguments for restricting FIELDSET to forms, including that the positioning of FIELDSET on the FORMS page of the spec appears to make the intended context of its usage quite clear. However, the DTD itself -- that rigid spine of the HTML spec -- is certainly capable of expressing descendant constraints. In this case it does not require that a FIELDSET contain any input controls at all, as I read it. Here's what it stipulates for HTML 4.01 Strict: http://www.w3.org/TR/html4/sgml/dtd.html ...which I believe says that it must contain %PCDATA (character data) followed by LEGEND followed by optional %flow. %flow can be %block and/or %inline which leaves the list of descendants wide open. LEGEND in turn must contain (%inline;)* -- zero or more inline elements -- therefore none of FIELDSET's descendants must contain an input control. The FIELDSET definition could easily have included: (INPUT|SELECT|TEXTAREA|BUTTON)+ or: (%formctrl)+ But it doesn't. The English language comment in the DTD says "form control group" but the SGML syntax itself explicitly permits a FIELDSET group to contain no input controls at all. We can speculate on the reasons for this presumably deliberate lack of specificity -- perhaps the DTD engineers were leaving room for us to markup "display versions" of input forms, for example -- but we cannot argue that the DTD omitted this because it was incapable of expressing such contraints. To confirm my interpretation of the DTD I referred to: On SGML and HTML http://www.w3.org/TR/html4/intro/sgmltut.html 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] Re: Use of Fieldsets other than in form?
At 6/6/2007 01:13 AM, David Dorward wrote: On 5 Jun 2007, at 19:22, Paul Novitski wrote: The FIELDSET definition could easily have included: (INPUT|SELECT|TEXTAREA|BUTTON)+ or: (%formctrl)+ But it doesn't. And if it did then the fieldset couldn't contain elements that add extra semantic information about the form controls, their labels, and their relationships to each other. Well, not really. The syntax allows us to eat our cake and have it, too: ((#PCDATA,LEGEND,(%flow;)*,(%formctrl)+) If I'm wielding the syntax right, that gives you all the flexibility of the current element definition while still requiring at least one form control per fieldset. Or maybe it needs room for more %flow elements, like: ((#PCDATA,LEGEND,(%flow;)*,(%formctrl,(%flow;)*)+) one chunk of character data, followed by: one legend, followed by: zero or more flow elements, followed by: one or more: form control, followed by: zero or more flow elements Mind you, FIELDSET's current content model definition doesn't look quite right to me: (#PCDATA,LEGEND,(%flow;)*) I read this to say, "required character data followed by a required LEGEND element followed by zero or more flow elements." This would appear to obviate the LEGEND coming first in the markup inside the FIELDSET: This is a legend... Where's the PCDATA between and ? Unless there's something about the syntax I'm not understanding, the content mode should make the PCDATA optional: ((#PCDATA)*,LEGEND,(%flow;)*) The DTD almost always errs towards the liberal, it is expected that documents be written according to the prose of the specification and not just the machine readable components of it. That's a very interesting assertion and gets right to the heart of many of the debates on this list. It sounds counter-intuitive to me: I would expect the prose to be more liberal than the machine-readable DTD. Can you recall the source of that expectation? If we could nail that one down it would certainly help clear up much of the apparent tension between the very specific DTD and the comparatively loose descriptive passages of the spec. I read the HTML spec as an annotated DTD, using prose to discuss and exemplify the element and attribute definitions for us mushy wetware types. Every section of the spec begins by quoting the DTD and then discussing those definitions. On a quick re-reading of the spec's introductory sections I don't see where we're advised to place more authority in the prose than in the DTD. Just to maintain perspective let me add that I'm pursuing this aspect of the discussion NOT as a campaign for fieldsets without form controls (I feel that part of the debate has been laid to rest) but rather because I want to better understand the DTD and its relationship to the spec, especially in a case like this where they appear to contradict. 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] Triggering POSTs with links?
At 6/20/2007 07:52 AM, Richard Ishida wrote:
I put together a box that expands to accommodate larger text in
translation, but I forgot that text on a submit button doesn't wrap :O
Original:
http://www.w3.org/International/questions/qa-css-charset.en.php#endlinks
(see the box to the right)
First problematic translation:
http://www.w3.org/International/questions/qa-css-charset.fr.php#endlinks
I want the text "Send us a comment" to look like a link, but trigger
a POST, so I put the text in a submit button and styled it.
Unfortunately the longer translations won't wrap that way.
Richard,
Another method is to create a transparent button image and place it
on top of the text (i.e. in a layer between the text and the viewer),
something like this:
Envoyez-nous un commentaire
name="sendcomment" />
/* make all three elements the same size & resizable */
div,
div p,
div input
{
font-size: 1em;
width: 10em;
height: 3em;
}
/* the div constrains the text & button */
div
{
position: relative;
}
/* superimpose the text & button within the div */
div p,
div input
{
position: absolute;
top: 0;
left: 0;
margin: 0;
}
http://juniperwebcraft.com/test/transparent-button.html
Warm regards,
Paul
__
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
+1-250-355-2541
skype juniperpaul
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Who's A "Front End" Developer?
The datastore/backend guys will just make sure the data is in a nice format (JSON or something) and that its accessible from a url - their job is done my friends. Ouch. For me this points up the absurdity of the demarcation between front-end and back-end developer. Unless each of us understands the whole sweep of it we're going to make stupid mistakes that will make everyone else in our team miserable. Spare me, please, from working with someone who believes that their job is done at the boundary of any particular technology or technique. In my experience everything in this field is too interconnected for that kind of separation to work. It drives me crazy when graphic designers hand me one Photoshop mockup per page and figure that their job of "designing the site" is done. To do a decent job, a web graphic designer needs to understand CSS which requires familiarity with HTML markup and browser technology, and it helps hugely if they understand the economies of scripting, the logic of database queries, and the fundamentals of many other technologies that superficially have nothing to do with graphic design. Just as a good print designer needs to understand papers, inks, and printing technologies, a web graphic designer needs to know the stuff that the page is made of in order to make competent decisions. Looking at it from the back end, there are convoluted handshakes between MySQL and PHP and HTML and JavaScript and CSS, and bingo you're doing graphic design. Even if we don't do all the work ourselves we have to maintain a healthy appreciation for the limits, requirements, and efficiencies of all the technologies in the daisy chain if we're going to produce really great work. Of course there's a difference between 'having an understanding' of a technology and actually practicing it. I'm familiar with many of the capabilities of Photoshop, for example, even while I acknowledge that I'm a novice user and pass the fine work along to my partner the graphics expert. But when I'm engineering the "back" end of a project my consciousness has to extend all the way to the very "front" or we'll end up with something that's lame at best, broken at worst, a disappointment to the client, and expensive to fix. I appreciate the efforts of the folks in the Netherlands to come up with some standards of expertise by which they can judge a worker's competence, but the front-end/back-end model that's driven this discussion waves warning flags for me. I think it's a potentially harmful paradigm if formalized into job categories with impermeable boundaries. Did anyone but me read A.E. van Vogt's Voyage of the Space Beagle as a kid? Specialists are handy appliances, but give me a nexialist any day if you want a brilliant solution. 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] Lower portion of lower case "y" does not appear in h1 in IE7
At 8/10/2007 05:01 PM, Joyce Evans wrote: When I view the following link (which Im working on) in IE7, the lower portion of the y in the word Physician does not appear. I see the entire y in IE 6 and FF 2 but not in IE7. This text is sitting within an h1 tag within a #title tag. Does anyone have an idea why I cant see the lower portion of y? http://www.nichemktghouston.com/mneiman/physician.html Also, in the content div, I have a background image bg_content.jpg that has graphics to the left and to the right, and the center is simply white. I have been told in the past that this type of background image is not a good idea meaning the white portion, but how could I get the left and the right graphics to appear and repeat as more content is added, without including the white portion of the graphic? Joyce, The problem of IE7 cropping off the font descenders is fascinating and I look forward to reading an explanation. Perhaps if you posted the problem to the CSS-D list you'd get an answer to that from the likes of Ingo Chao et al. Part of the overall problem you're having with this page is that the background image is just 35px tall so it can't accommodate text enlargement. The image includes its own top & side borders so it can't be repeated vertically or horizontally as the text expands: http://www.nichemktghouston.com/mneiman/images/bg_title.jpg You tried to suppress this problem by sizing the font in pixels, but of course that succeeds only in IE. In other browsers the font enlarges out of its container and becomes not just ugly but also a nearly unreadable white on pale grey. Two simple ways to change this situation are a) to make the background image much taller so that more of it will be revealed as the headline increases in size and b) to split the background image into two components: the unrepeatable top borders and the repeatable orange body. Taking a step back, however, I don't see the need for a background image at all. The background imagery consists entirely of rectlinear monochrome spaces and lines that can be reproduced exactly with background colors and borders. The only complication in reproducing your page precisely this way is that adjacent CSS borders meet on a diagonal at the corner of a box and your top grey border butts flat on top of the gray side borders. This detail can be sacrificed for easy layout or reproduced exactly by using an extra nested div. Your nav menu as rendered is another sticky wicket, with the light & dark grey pill shapes. Again you've created a fixed-height background that's inadequate to contain enlargeable text. An easy way to start solving this is to make that background image quite tall with a light grey body and the dark grey curves only at the bottom, and position the background image in the bottom of its container. It doesn't solve your menu's other problem which is that as the text enlarges the menu spills horizontally out of the page block. Allowing the menu items to wrap around within your fixed-width column will keep the menu on-screen while the font enlarges but you'll need to re-think its background image. One possibility is to use a segment of the light & dark grey background for each nav menu LI so that each menu item maintains its grey blobby background even as it wraps. This would almost certainly require you to re-visualize the menu's graphic design to keep it looking good as text enlarges. 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] CMS review
At 2/28/2008 03:57 PM, alysia hill wrote: I have just discovered this australian based company Powerfront. I am really interested in some feedback. ... Here is an example website which I think is pretty good http://www.goodshepvic.org.au/ Here is the company website http://www.powerfront.com/ Try validating their markup: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.goodshepvic.org.au Failed validation, 188 Errors http://validator.w3.org/check?uri=http%3A%2F%2Fwww.powerfront.com Failed validation, 160 Errors These results indicate, not the occasional slip-up to which we are all susceptible, but a significant misuse for the tools of their trade. In particular, there's little excuse for a CMS to produce markup this shoddy. While we might forgive a site hand-coded once, a CMS generates many sites and therefore bears a greater responsibility to do it properly. Broken markup can produce nightmares for styling, accessibility, machine-readability, and search engine optimization. In your search for a CMS I recommend you look for valid markup, versatility (not locked into limited templates), and ease of use. Good luck! Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re[2]: [WSG] Why is deprecated?
At 3/28/2008 01:14 PM, Àëåêñåé Íîâèêîâ wrote: Is underline really needed? What for? Underline is a method for highlighting (emphasizing) Roman text. As far as I know it was invented with the typewriter, being a way to highlight a bit of text using a machine that was limited to a single font family, style, and size. Underlined text in a manuscript is typically typeset in italics. A lot of designers today agree that it's quite ugly and defaces the descenders of the type it highlights, although some type designs use it as a way of getting attention (because it's so ugly) or evoking the historical era of the typewriter. Most aesthetically compassionate people limit its use to hyperlinks where it is the defacto standard; on web pages, any other underlining is discouraged because it makes people expect the underlined text to be hyperlinked. In case google is blocked from your region, here are a couple of references: http://en.wikipedia.org/wiki/Underline http://www.flyinglizard.co.nz/typography.php 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] ***
[WSG] seeking JavaScript Bible comments
I would love to get your critical comments on Danny Goodman's JavaScript Bible http://ca.wiley.com/WileyCDA/WileyTitle/productCd-0470069163.html I'm updating the book to its 7th edition and am making some significant changes, including upgrading it to include separation of layers & progressive enhancement. Do you have any other criticisms of the book, either minor or major, that I should consider in the rewrite? I would be grateful for your detailed remarks. Thanks, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Marking up news
At 2/19/2009 03:43 PM, Essential eBiz Solutions wrote: It's basically a page on my site just to put news snippets such as new client etc. I've gone with News Title (h1, h2 and h3 are already being used within the page for heading and sub heading) News Date News Content At the risk of reading too much into your wording... Don't avoid using a headline level just because it's "already being used within the page". Think of headlines as the items in a standard outline form. In general practice a page will have only one h1 restating its title; after that just increment the headline number as you drill into the content structure. If you've got a headline for the collection of news items on this page, e.g. News, then you'd use the next level down for the title of each news story within that section -- regardless of whether that same level of headline had been used anywhere else on the page. Rumors & News Rumors Dog Explodes in Microwave Intelligent Life Discovered on Earth News Obama Visits Ottawa Duchy of Grand Fenwick Invades New York ... And it's always a good idea to dip from the well for refreshment: http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 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: memberh...@webstandardsgroup.org ***
Re: [WSG] 3 column layout issue
At 3/18/2009 12:49 AM, Naveen Bhaskar wrote: Hi, I have a 3 column layout structure. My issue is the content of the center column is shifting down . pls help me to fix this.. First, test your markup and styling using these validators and make sure there are no errors. HTML: http://validator.w3.org/ CSS:http://jigsaw.w3.org/css-validator/ Second, give us a hyperlink to a page on a server where we can see the problem occurring. There are a number of reasons why this could be happening and we'd have to see your markup & styling to help troubleshoot. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Borders in liquid layouts
At 4/17/2009 11:18 AM, Stevio wrote: I have created a web site design, with a graphical border down the sides of the design (15px wide on each side). To implement this using CSS would be quite simple if the design had a fixed width, but I am looking to implement a liquid layout. Essentially I reckon it comes down to equal height columns in liquid layouts. Any suggestions on how to best accomplish this? You could wrap the columns in a nested pair of parent containers that stretch naturally to contain the widest & tallest of their children, then apply one border to the left side of outer parent and the other border to the right side of the inner parent. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Image mapping standards question
At 6/1/2009 07:34 AM, Brett Patterson wrote: It has recently come to my attention the struggles of an end-user when viewing images for any user. I have seen sites such as Facebook, MySpace, and other sites where pictures are hosted use roll-overs for recognizing certain parts of an image. I realize that this can be done using image maps as well as when using image mapping, I can add alternative text not only to the img tag itself, but the maps as well to show and describe certain features I feel are important. Are there recommendations for or against this approach? Also consider CSS image maps with pop-ups, e.g.: http://www.cssplay.co.uk/menu/imap by Stu Nicholls. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] What to do with buttons when a user copies text from a page.
At 6/12/2009 01:42 AM, James Ducker wrote: Something I've been pondering - how best to handle buttons and other purely functional content residing within a block of selected text? Often a user will select a bunch of text and get something like: > Some Headingminimiseclose > Some text etc etc. I was thinking about adding JS mouse drag detection to hide "minimise" and "close" (let's say they're elements) when the user is mouse-selecting text, but it would fail if a user used the text cursor to select. It sounds as though you've already answered your own question -- don't let the controls reside within the block of copyable text. In most circumstances the user will want to copy the header along with the body text of a given section, so rather than inserting the controls in the middle of copyable text I'd put them before or after. If you want the controls to appear to the right of the heading in a left-to-right text flow, you could try putting them first in the markup and then floating them right or absolutely positioning them so the heading and text are contiguous. A more elegant & bulletproof solution might be to rethink the page layout and visually place the controls above or to the left of the heading to allow the natural text flow to exclude them from selection. If the controls look like they're in the middle of the copyable text, a user with browsing experience will naturally worry that the controls will get copied along with the text, diminishing very slightly their sense of trust in the intuitiveness of the design. A layout that puts them outside the selection highlight altogether -- modelled by the resize & close buttons in pc & mac windows that everyone's familiar with -- would be more of a no-brainer to use. Finding a way to reliably make the controls disappear while the user selects text sounds cool -- I can imagine all the ads and navigation and chromy bits disappearing while copying a story from a news site, for example, leaving my clipboard with the story I'm after not needing to be cleaned up -- but it also sounds a bit paternalistic in deciding in advance for an unknown user what they're going to want to select. If you place the controls before the heading in the markup, you leave it to the user to decide whether to include them in the selection highlight. For all you know, their purpose in copying text from the page is to illustrate in a document that aspect of the page layout that includes the controls. There's such a thing as trying to be too helpful. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/13/2009 02:20 PM, Ido dekkers wrote: i'm trying to find a way to get back to the same position in a table that is nested in a fixed height div. only 4 lines of the table are showing and i need after post to the server to get back to the selected line any suggestions are welcome the case in question : http://test3.dekkers.net/policies/viewer.htm Just as you would in a broader context, give each TR a unique ID and add it to the URL to bring it to the top of the (div) window, e.g. http://test3.dekkers.net/policies/viewer.htm#tr4 By the way, the HTML validator caught an illegal < character on line 159 "<". And did you save the source file as utf-8? http://validator.w3.org/check?uri=http%3A%2F%2Ftest3.dekkers.net%2Fpolicies%2Fviewer.htm 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: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/14/2009 02:25 AM, Ido dekkers wrote: thanks for the help but for some reason, the #id works only for rows that are visible to start with? i added id="" to all rows and the #id works only up to row 4? In the earlier page you posted there were ids in only the first four TRs in the HTML source. In its current iteration, I see ids in all twenty rows, and the URI fragment approach does work, e.g. http://test3.dekkers.net/policies/viewer.htm#tr10 how do i get the scrollTop ? https://developer.mozilla.org/en/DOM/element.scrollTop Because scrollTop is pixel-based, does it fail to give you the effect you're looking for when the user changes text size in mid-process? If so, Keep in mind as always that a JavaScript solution will not work in user agents not running JavaScript, which can include search engines, mobile devices, assistive technology, browsers in certain corporate contexts in which JavaScript is globally turned off or stripped out of incoming pages by firewalls, old browsers, and modern browsers used by folks who turn it off for whatever reason. A developer embracing progressive enhancement (q.v.) will first make sure that the page works for everyone and then add client-side scripting to make it faster and cooler for people using script-enabled UAs. Your policies/viewer page is dead as a doornail without JavaScript running, but it doesn't have to be. It's like you've put all your energy into the icing but forgot to bake the cake. In my own experience, getting a page to work first without JavaScript leads me to such elegant solutions that I end up adding less JavaScript than I had originally thought I would, so everyone wins: the page works universally and it's lighter-weight and more bulletproof for JS-enabled users. Regards, Paul __ Paul Novitski +1 250-226-7050 skype juniperpaul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
I incompletely wrote: Because scrollTop is pixel-based, does it fail to give you the effect you're looking for when the user changes text size in mid-process? If so, If so, consider whether the auto-scrolling is critical to the functionality of the page and how confusing it might be if the table auto-scrolls to a different row than was just edited. If both answers are Yes, you may wish to consider a more bulletproof solution. Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
At 6/14/2009 11:28 AM, raven wrote: > Keep in mind as always that a JavaScript solution will not work in > user agents not running JavaScript, >which can include search engines, > mobile devices, assistive technology, browsers in certain corporate > contexts in which JavaScript is globally turned off or stripped out > of incoming pages by firewalls, old browsers, and modern browsers > used by folks who turn it off for whatever reason. Hmmm... what exactly problem can cause using of JavaScript *in this case* from SEO point of view? Not having seen the original poster's development plan, we can't judge whether any of the parts that are broken without JavaScript will deleteriously affect its search engine ranking. Because the page was SO dead without JavaScript, I made the assumption that the author wasn't considering scriptless UAs and therefore my remarks were intended generally. Or what browser, *witch you really support*, don't support JS? In my own work, my CSS support for mobile devices has lagged, but as my pages all work 100% in the absence of JavaScript (which I do use in every site I produce) I can say I do support to that extent all the JavaScript-disabled user agents listed at the beginning of this post. (Also I do support witches, but that's off-topic.) And what part of your target auditory even know how to disable JavaScript execution in their browsers? Don't use common words! Give us facts, numbers, tests. So, for example, if I could give you the number of individuals who would be unable to use a website because I built it to unnecessarily require JavaScript, then would you be able to tell me whether that was an acceptable sacrifice in terms of loss of revenue to the client, loss of good will, negative reviews, and negative viral spread? What percentage of your clients' target audiences have you decided to block from the sites you build for no reason other than that you enjoy building cool user interfaces in JavaScript? If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? But graceful degradation is good idea. Graceful degradation is better than nothing, but progressive enhancement rocks. http://en.wikipedia.org/wiki/Progressive_enhancement http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ If you have enough time and budget big enough you may look for solutions for case when JavaScript is disabled. I don't need to. I build sites to work well with server-side scripting, then I enhance the client-side experience with JavaScript. I don't have to justify extra work to make a site functional for any size of sub-market or worry about how many people it's OK to piss off if the site already works for every user agent. I don't provide core functionality with JavaScript. I learned the hard way that doing things the other way around is time-consuming, expensive, and frustrating. JavaScript is fun, but you aren't going to survive long if you consistently eat your dessert before your vegetables. No, first you build a car that runs well, then you add the chrome and fancy sound system. I'd better stop before I think of any more metaphors to throw in the pot. Oops, too late. P.S. In ordinar case if you can get functionality, you need, without JS do it. Exactly. To everyone, I apologize for indulging in a philosophical argument that has already seen so much traffic. Reviewing the wsg list guidelines, I hope this falls into the category of discussing best practices. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/14/2009 06:02 PM, Andrew Stewart wrote: If you can improve the user experience using JS (why else would you be spending time on it) then you must accept that the user experience for those 10% without JS is going to be worse and hence they are less likely to buy from you, or give you some kind of revenue. Is it really worth spending all this effort to cater for users that in the end may only account for a tiny percentage of sales? Conversely, if you start out by building a robust site with server-side scripting, and then add JavaScript as an enhancement on top, you'll be spending the extra time catering to those with JavaScript, not those without, and by your way of thinking those are the folks who are more likely to bring in more revenue, so the financial model would fit the demographics. However, if someone's not using JavaScript on your site, they probably aren't using it on sites in general. Rather than compare their likelihood to buy with others of your customers who do run JS, compare their experience on your site with their experience on other sites -- the folks you're competing with. If someone is driven to your site because the competing sites are broken or clumsy without JS, then making your own site work competently without JS is a revenue generator. If you try to cut costs by shutting out that 10% or whatever of potential buyers, you're simply driving them to competitors whose sites they can use. I don't see the bottom-line benefit of that. Ten percent, by the way, is an enormous number. I mean, you have to start out by building a robust site -- that's bottom-line, right? You don't go into it with a goal to build a broken one. Is it more time-consuming to build a site that works with and without JavaScript than to build one that breaks without it? Where would the time-savings come in the development plan? If you're validating a form with JS, you still have to validate it server-side so you don't invite hackers. If you're using Ajax to update the server, you still need to write those server-side modules to receive, validate, and process the data; whether the update mechanism is an HTML form submit or a JavaScript XMLHttpRequest you still have to write the same core back-end code. We can certainly imagine pages such as drag-&-drop layout modifiers whose user interfaces would likely have to be radically different if pulled off completely server-side, but by far most websites have user interfaces that can look very similar if not identical without JavaScript; it's just their response time that isn't as instantaneous when it comes to, say, forms morphing as the user drills into the options. That said, client-server round trips on broadband are pretty fast these days and people are accustomed to waiting for page refreshes on most sites, so I don't think most people would consider that aspect to be a sale-killer. I don't see, for example, Amazon.com suffering for lack of sales because people are too impatient to wait for page refreshes. I am not saying this is definitely the case, but plain statistics about how many users have JS or flash or siverlight etc don't tell you the full story. If a developer has X amount of hours to spend on a site, then it is possible that the most effective way to increase revenue of that site might be to forget about people without JS etc and just create the best experience for the majority of internet users. That's graceful degradation talking. Sit tight, we're sending over the deprogrammers. Sorry if this sounds a bit like heresy. No worries -- a) it ain't religion and b) thinking people welcome heresy. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Using background images on submit buttons
At 6/17/2009 06:45 PM, Jens-Uwe Korff wrote: on an ASP.NET-driven site we'd like to use background images for flexible-width submit inputs. Due to the .NET limitation we cannot use the tag and are stuck with the following syntax: Did you ever style these submit inputs with background images that allowed a flexible width? I have successfully applied a background image to input, for example the join-list form on this pre-launch site: http://innerpeaceyogatherapy.com.s9135.gridserver.com/ I consider the above solution, with its single background image, to be a mediocre, interim placeholder approach because this image with its rounded corners doesn't support text-resizing well. If you enlarge text separately from layout, the background image repeats, spoiling the cosmetic effect. (We're using a fixed width in this instance, but the same applies to horizontal repeats.) In this particular case our background image is such that input text remains legible on enlargement but we sacrifice the cosmetic single-pill appearance. If we were using a plain rectangle with at most say a uni-directional gradient but without special top- & side-caps, we could simply allow it to repeat vertically & horizontally without cosmetic penalty. To support rounded corners in an enlargeable context, I'd surround each input control with a matrix of divs and apply fragmented background images to those parts to allow for variable height & width. ...Pending universal implementation of CSS3's multiple backgrounds! One of the usability/accessibility problems with background images on input fields is that in order for the background image to display you need to override the default border & background color. Then if you disable images the input field disappears. I suppose a workaround would be possible in which the input field is positioned on top of a div with a border and/or background color that would show through if the input's background image were missing from the rendering. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Using background images on submit buttons
At 6/17/2009 06:45 PM, Jens-Uwe Korff wrote: on an ASP.NET-driven site we'd like to use background images for flexible-width submit inputs. (I apologize for getting off-topic and discussing text inputs instead. Too little sleep!) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] website fonts
At 6/22/2009 12:24 AM, matt andrews wrote:
2009/6/22 Mark Harris
> The biggest cost I have seen in web design since 1996, when I
started, is the perceived need to make the web like the printed
page. That, and the desire to make it pixel-identical in multiple browsers.
>
> Let the control go to the user, focus on getting information out
there. You can't control everything, just make it make sense.
Absolutely. This is probably old hat (where did *that* phrase come
from?) to most on this list, but if you haven't come across it before,
"A Dao of Web Design", a short article by John Allsopp (of Westciv
and Web Directions fame) is a must-read:
http://www.alistapart.com/articles/dao/
With respect, a few points:
- Allsop's article (which, although written in 2000 and out-dated in
some of its specific references to browser development, is completely
relevant today) primarily advises us not to try to control font-size.
With regard to font-family he writes, "With CSS, you can suggest a
number of fonts, and cover as many bases as possible. But don't rely
on a font being available regardless of how common it is." So his
philosophy DOES permit font-family suggestions and advises merely
against RELYING on any particular font being available. To me this is
a far cry from avoiding font-family suggestions in the stylesheet.
- If we don't "rely" on the presence of particular font-families and
let go of the desire to make the web pixel-identical in multiple
browsers, then the philosophical problem goes away, does it not?
- Even if we suggest fonts in the stylesheet, they're just
suggestions. I don't consider this to be "controlling" the user
agent. A suggested font will display if it's on the user's computer
and otherwise default to something that is. The user has ultimate
control in installing fonts of choice and overriding all stylesheets
(including the default stylesheet the comes packaged with the
browser) with their own.
- CSS font-family suggestions are a perfect case of both graceful
degradation and progressive enhancement. The browser ensures that the
text will render if there is at least one font installed on the
client computer, then the stylesheet can suggest a series of families
that more closely approach the designer's ideal. It's a system
guaranteed not to break on even the most rudimentary system, and will
look better and better the more of the desired software (fonts) are installed.
- I submit that suggesting serif and sans-serif in the stylesheet is
exactly as controlling (that is, NOT) as suggesting Georgia or Lucida
Sans. It is 'controlling' in the sense that it's suggesting to the
user agent whether to use a serif font or not, but with no control
whatsoever in determining whether a corresponding font resides on the
user's computer. If I install even one serif font on my computer,
your CSS rule of 'font-family: serif' will invoke that font unless I
override it. If I install only sans-serif fonts on my computer, your
CSS rule will ultimately be ignored and I'll see your "serif" text in
my Helvetica or Univers.
- There is no such thing as a web page without styling. Every browser
comes with its own default stylesheets which will determine things
like font-size, margins, and padding if not overridden by the
author's or the user's own stylesheets. So we're not really living in
a pure universe in which it's possible not to style. If you don't use
a stylesheet at all, you're just asking the browser to apply its own,
so by refusing to control you're not helping to create a situation of
no control, you're simply passing the buck. As a Buddhist you can
refuse to kill animals but as long as you're alive you can't avoid
killing vegetables and microorganisms and you can't prevent the lion
from taking down the antelope nor the spider the fly. Styling
Happens. Get used to it.
- Finally, if your relinquishing of control extends to not even
suggesting font-families, what do you use stylesheets for? Unlike
font-family suggestions, stipulations of color, margins, padding, and
other properties really are commands and will be carried out in most
browsers. {margin-left: 10px;} doesn't say to the browser "if you
feel like it," it says "just do it." If you do use stylesheets at
all, it strikes me as odd that you would take exception to named
font-families, the one aspect of CSS that is the least controlling of all.
Curiously,
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: memberh...@webstandardsgroup.org
***
Re: [WSG] more on fonts
At 6/22/2009 05:00 AM, Marvin Hunkin wrote:
hi.
well, the subject that i was taking, and the web page for pinciples of
visual design, my professor, said i have to had fonts, in the style sheet.
that was the requirmenet of this site i was doing for a fruit shop.
Just as a reality check, let me go over how this works.
You don't have to have any particular fonts on your own computer in
order to designate them in a web page.
You create a web page on your computer, upload it to the server, and
after that each visitor who sees the page downloads it to their
computer where it is displayed (rendered). It is the fonts installed
on each visitor's computer that determine how the text will be
displayed on their screens.
If you specify font-families in the stylesheet, you're not DICTATING
what font must appear, you're only SUGGESTING which fonts you'd like
to appear. If a font you've requested isn't installed, it doesn't
show up; that simple.
If you use the stylesheet to ask that some text be rendered in a very
common font such as Arial, it will be displayed in Arial on the vast
majority of visitors' computers. If you use a more unusual font, only
a small number of visitors might have that font and see it on the
page. Everyone else will see your 2nd or 3rd choice font for that text.
For example, if your stylesheet says:
h1
{
font-family: "Gothic Rare", Helvetica, Arial, sans-serif;
}
...then the visitor's browser checks to see if it can find a match
with any of the fonts in the list. "Gothic Rare" will not be found
anywhere because I just made it up. Helvetica is far from universally
installed, but Arial is extremely common so most people will see the
text in Arial. If none of those three fonts is found, 'sans-serif'
tells the browser to use whatever its default sans serif font is
which might easily be different on every computer.
A sans serif font is a font with no serifs. See also:
http://en.wikipedia.org/wiki/Sans_serif
Does that help clarify any of this?
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: memberh...@webstandardsgroup.org
***
Re: [WSG] website fonts
At 6/22/2009 08:49 PM, Felix Miata wrote: To put what you wrote another way, with a font family list such as your example, the visitor is at the designer's mercy to see only the designer's choice of fonts, instead of the visitor's, even if the visitor has spent big money on high quality but uncommon fonts and chosen as default one of them. To actually see his choice, the visitor will have to set is browser to completely ignore the designer's font choices throughout all documents. Like Mark, I say let the visitor's choice be the choice applied to most content, with the designer specifying otherwise only to highlight or provide character, as in headings, emphasis, or menuing. On body at least, it should be enough to specify either serif or sans-serif (partial deference to visitor), or nothing at all (total deference to visitor). If the visitor wants Comic Sans, let him have it. It's his puter, not yours. Oh, it doesn't stop with fonts! Some website producers are arrogant enough to force text and images on the visitor instead of allowing them to enjoy the default text and images they have written for their own browser. It's shocking; simply shocking. If people actually wanted to read the text, see the images, and enjoy the graphic and typographic design of other people (give me a break!), they would have connected these computers into a world-wide network and permitted us to browse around looking at one another's... hey... wait a minute... hmm, let me rethink this one. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] website fonts
At 6/22/2009 08:49 PM, Felix Miata wrote: To put what you wrote another way, with a font family list such as your example, the visitor is at the designer's mercy to see only the designer's choice of fonts, instead of the visitor's, even if the visitor has spent big money on high quality but uncommon fonts and chosen as default one of them. To actually see his choice, the visitor will have to set is browser to completely ignore the designer's font choices throughout all documents. Like Mark, I say let the visitor's choice be the choice applied to most content, with the designer specifying otherwise only to highlight or provide character, as in headings, emphasis, or menuing. On body at least, it should be enough to specify either serif or sans-serif (partial deference to visitor), or nothing at all (total deference to visitor). If the visitor wants Comic Sans, let him have it. It's his puter, not yours. I submit that installing a font on one's computer establishes a concrete desire to view text styled in that font to be displayed in that font. Conversely, if we don't wish to see text in a particular font, we can simply remove it or choose not to install it in the first place. We're still "at the mercy" of PDFs and word processing documents with embedded fonts and Flash movies and docs containing text-as-image, but plain text HTML cannot force fonts on us that we do not choose to see. The user has complete control over their own computer in this regard and cannot be forced or coerced by a document designer. I put it to you that all of the text on a page provides character to the page, not just headlines & menus. It is the relationship between different fonts on a page that gives it deeper character. Sans-serif heads are not the same when paired with either serif or sans-serif body text. Please explain the boundary you perceive between body text, which you feel should not be styled by the page designer, and headlines, emphasis, and menuing which you think are OK for a designer to design. Why should the page designer not influence the former and why should the font-sensitive end-user relinquish control over the latter? Further, why should we not influence letter forms but have our merry way with foreground & background colors, borders, images, surrounding margins & padding, line height, and other stylistic memes that can affect both readability and the reader's aesthetic context just as much as or more than font choice? I suggest we go ahead and suggest font-families but do it intelligently and compassionately, choosing fonts for a particular purpose for their grace and readability and compatibility with column-width and all the rest of the page design. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Expand width of container to fit content's width?
At 6/26/2009 12:58 PM, Stevio wrote: Is it possible to expand a container's width to fit its content? For example, if I have a page where the content is wider than the width available at the browser's current size, which means the horizontal scrollbar appear, I want the container to expand to fit the width of the content instead of having the content sticking out the side (because that makes the design of the page look poor when the user scrolls horizontally). It's always a good idea to include a link to a page where your problem is actually occurring so we can give you pertinent advice. Speaking in generalities, normal behavior is for a container to stretch to contain its content. However, if content is floated left or right or positioned absolutely or relatively, it's taken out of the flow and can visually extend beyond the boundaries of its containing block. The solution is often to float or relatively position the container. If the problem is that you've absolutely positioned your content, I would further recommend that you rethink that plan, as in most cases absolute positioning is an unnecessary, brute-force approach to solve a problem that can be handled much more gracefully with different styling. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] DIV Javascript Problem
At 6/29/2009 02:32 AM, Aaron Wheeler wrote: taken charge of maintaining a website for a client who uses divs to display data onto a .htm page. They do not want to use .php and mysql data basing as they are worried about losing their ranking in the search engines. Please tell the client that search engines do not use JavaScript, therefore all content that is displayed on the page by JavaScript will not be seen by search engines and will not improve their SEO. This sounds like a classic example of a non-technically-proficient client making low-level technical decisions that are simply outside of their purview. In my opinion the scope of their mandate should be to have a website created that furthers their business model, and to hire the expertise to make this happen. Exactly which technologies are used to reach their goal should not be decided by anyone with little or no experience using those technologies. For modern HTML support you'll want to enclose attribute values in quotation marks. http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2 To support modern coding principles such as progressive enhancement and graceful degradation you'll want to strip all JavaScript out of the HTML and confine it to the linked .js file where it belongs. http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ The W3C HTML Validator referred to previously can be found at http://validator.w3.org/ So I was wondering why this does not always work and especially when I seem to update pages using dreamweaver. I dunno how this works or why it even works. It's impossible to say without seeing the complete HTML page and JavaScript file. If you want help, I suggest you post links to where they're located. It's possible that the solution to your problem is simple; if not, it may be beyond the scope of this list to help you for free and you may have to hire some expertise. Good luck! You've got a long climb ahead of you, but achieving altitude to so worth it. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessible websites (was: accessible free web hosting account)
At 6/29/2009 11:46 PM, Jens-Uwe Korff wrote: I found that some of these elements take quite some time to integrate. Creating high-contrast CSS can take up to a day (or more if you're new to it), non-Javascript states usually more than an hour because you also have to edit the script. By "non-Javascript states" do you mean that the website should work in the absence of JavaScript? I like to think that this is where web development should begin, with JavaScript added to enhance, not to provide core functionality. For an example of a high-contrast version may I suggest to check out the Sydney Morning Herald's Travel section (http://www.smh.com.au/travel/). Click on "Low vision" in the navigation bar (We're going to replace "low vision" with "high contrast" since the former can be perceived as discriminatory). The styles you see then have been developed together with a vision-impaired person. FYI, when I click on "Low vision" and get the high-contrast stylesheet, that right-most menu pick changes to "High contrast" and is highlighted, indicating that I am now on the high-contrast page. I click it again and I return to the starting stylesheet and the menu pick changes to "Normal contrast." This is inconsistent -- first you're using the menu pick as a sign post to another state, and then you're using it as a current state indicator. Was this deliberate? It feels broken to me. Usually I click on menu items in order to go to the named item or to invoke the named change. You're using the menu pick initially in this way, but after you begin using it, it becomes an indicator of the current state rather than a sign post pointing off-stage. I would choose just one of those models, leaning toward sign post. If you want to indicate the current state, I would display both states and highlight the current one. Also, to ditto Jim Croft, it's terribly ironic that this menu pick becomes large enough for a person with limited vision to read only after it's been selected. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] javascript and accessibility [was: Accessible websites]
ser agents, Google will consider that cloaking -- directing different content to search engines than to human users -- which can get a site banned from Google. If you're going to supply the same content, it makes obvious sense to produce pages with all the content and then use JavaScript to selectively hide parts through DOM or CSS manipulation as part of the user interface, for example to implement tab controls. That's progressive enhancement. Hyperlinks that are simply hashes because their sole purpose is to trigger Ajax operations aren't registered by search engines as links to separate content, so that's shooting yourself in the foot SEOwise. Better to create real hyperlinks to real pages (or real page-reloads) with the different content, and then override the links with the Ajax logic. That's progressive enhancement. I'll be very interested to read other people's contributions to this topic. PS. Gut-feel tells me that non-JS should work, so thats how I prefer to code. Smart gut! 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: memberh...@webstandardsgroup.org ***
Re: [WSG] working with line-height
At 7/1/2009 07:19 PM, Ben Lau wrote:
This is what I'm trying to achieve:
<http://hellobenlau.net/wsg/eg.gif>http://hellobenlau.net/wsg/eg.gif
So there'll be a div with padding top and bottom of 20px, and with
text inside.
This doesn't look to me like a line-height topic at all. If you
increase the line-height, the lines of text within each paragraph
will separate from one another, and that isn't what your gif
illustrates. It looks more like a (default) line-height of 1.
Instead, this looks like a simple matter of applying padding &
margins to the wrapper div its paragraphs.
Now, if we're to take your gif literally, it looks like you've got
17px between the two paragraphs. That implies:
div
{
padding-top: 20px;
padding-bottom: 3px;
}
div p
{
margin-bottom: 17px;
}
20px
some text
17px
some more text
17px
3px
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: memberh...@webstandardsgroup.org
***
RE: [WSG] Back to basics!
Could anyone tell me where there is information regarding character code 'usage' that is simple. I always use UTF-8 and, e.g., if I want to put a left quote in my text I can use " or “ Which is recommended? ... One of the main points of using Unicode is that you don't need to use entities, other than for a handful of chars used by HTML. Yes! Using UTF-8 in your web pages means NOT having to use HTML entities for text such as ñ or ê. The only HTML entities you need to use in your character data are & for '&' ampersand, < for '<' less-than, and > for '>' greater-than so that those characters don't confuse the HTML parser. To get you started, two basic rules are: 1) Save your HTML/PHP files with UTF-8 character encoding. In many text editors there's a character encoding option in the Save As dialog. 2) Declare UTF-8 as the character encoding in the HTML header, e.g.: (XHTML has different character set declarations than HTML.) For more details see Richard Ishida's W3C Internationalization pages at http://www.w3.org/International/ 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Back to basics!
At 7/11/2009 04:44 AM, designer wrote: So you are really saying that typing "I have got �100 to spare" is OK, instead of: “I have got £100 to spare” Absolutely. As an example, look at the HTML source for this page: http://laurietobyedison.com/WOJwords_HanashiroIkuko.asp Scroll down past the nav menu and you'll see both Roman and Japanese text. There are HTML entities in the pages of this site that have survived from an earlier iteration, but none of the quotes and dashes need to be escaped with UTF-8. Just try it -- it will be a revelation. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Usability in Links
At 7/18/2009 12:58 PM, Bushidodeep wrote: I've a client wishing to call attention to (2) a: links, in a vertical list by simply reversing with the hover color. The a:links are now the hover color value and the a:hover is now the a:link color value. After reviewing the change I found it conflicting with the surrounding a:links, so did some of my flat-mates used for usability testing. Would someone suggest a method that doesn't cause disharmony, or is it just nit-picking on our part? What I would say to your client is this: Graphic designs communicate much like any language with the elements of the design comprising the vocabulary of meaning. A website design must actually teach us its own design language even as we're using it. While graphic design has a lot of flexibility for creating new terminology with each new design, designs must still abide by certain patterns of human language comprehension if they wish to communicate well. One of those patterns is that elements that look alike mean something similar. Unlike the richness of spoken language that can afford such luxuries as ambiguity, a page has only a few dozen design elements in its vocabulary and therefore each element should express a distinct, unique meaning in order to keep the design easy to understand and quick to apprehend. A page that's confusing leaves the visitor unsure, while a page that's clear helps us feel comfortable and confident while we're reading or using it. Using the same color combination for menu item hover state as to highlight an item the client feels is important is unnecessariliy confusing. Surely the color palette of the overall design is rich enough to come up with a unique combination to represent 'importance'. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] [Spam] :changing font sizes from within a page.
At 7/20/2009 06:49 AM, Brett Patterson wrote: I agree with James. Although, I find the best possible, all-around solution is to use all of the above! If the user does not have JavaScript/cookies enabled, then the user will use their browser, else they cannot view the text in large size. If the user does have JavaScript/cookies enabled, then the user can use that method to enlarge font size, whether they know or do not know how to use the browser to enlarge font size. To echo others, I'd like to chime in that any basic functionality that depends on JavaScript running can be considered to be inherently broken. First build the function to run as a client-server exchange, e.g. with hyperlinks to other pages or to the same page to be modified with a server-side script. Then add JavaScript to enhance the experience for those with a modern version of js running in their browser. Google progressive enhancement. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] legal list numbering
At 8/25/2009 10:11 PM, Andrew Harris wrote: How do people get around the problem of marking up ordered lists in legal documents, such as policies or terms and conditions? A typical structure might look like: 1 blah blah blah 1.1 blah blah blah 1.2 blah blah blah 1.2.1 blah blah blah 1.2.2 blah blah blah 1.3 blah blah blah 2 blah blah blah 2.1 blah blah blah 2.1.1 blah blah blah* In all of the discussions of this issue I've read, the final wisdom has been to actually hard-code the numbering of contracts, bylaws, etc. in nested lists, suppressing the normal list-style-type. That might seem retro, but you can't afford to have any of the numbering change because of an editing error. The whole point behind auto-numbering is thoughtless re-numbering, something a legal document cannot tolerate. It would be better to have an accidentally-deleted item leave a hole in the numbering that a proofreader could easily catch than to have HTML automatically close up the numbering sequentially over such an elision. Another advantage is that the numbering is manifest in the markup itself, rather than being a sequence of bare LIs. Someone can snip an excerpt from the markup with the numbering intact. (In this vein, implementing the numbering of a contract with JavaScript sounds about as smart as printing the contract on sheets of ice.) This decision is made easier, of course, by the limited auto-numbering options of HTML! Justification for hard-coding the numbering from a semantic perspective is that the numbering is actually integral to the content and not merely an incidental by-product of its sequence in the greater list. I believe the logic is that once the legal document is finalized, an item's number becomes part of its fixed name used in quoting and references and a great weight of legality rests on the accuracy and persistence of the numbering. Of course, when you're drafting a contract it's handy to use auto-numbering in word processing, but once you get to the final draft stage I'd freeze it for HTML. 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: memberh...@webstandardsgroup.org ***
RE: [WSG] Ordered List Best Practice
At 9/22/2009 08:43 AM, Kepler Gelotte wrote: First Subheading First First Subheading First First I find this solution problematic. Scrutinizing the markup, I would put a subhead at the beginning of the content it heads, not at the tail of whatever content precedes it. Semantically, if items d & e deserve their own subhead, to what extent are they really part of the same list as a, b, & c? They might be on the same nesting level, but are they really part of the same list? It would be interesting to see some of the actual content of this list to see why the original poster felt that all five items belong in one list. I guess the bottom line here is that today's HTML doesn't permit us to insert a headline into the middle of a list but gives us this solution: ol li ol li a /li li b /li li c /li /ol h3 subhead /h3 ol li d /li li e /li /ol /li /ol Subheading Aside, is the div really necessary? Could not any necessary styling be applied to the h3 itself? If complicated markup is deemed necessary, for example because of multiple background images < CSS3, I myself would rather nest structures inside the headline rather than hang them outside of it so as to reach for a greater semantic clarity. Also, I suggest you use class names that evoke the purpose of a structure and not its presentation. If your class names are going to be as explicit as "margin_left_minus_40px" then you're no better off than injecting style rules inline. Either way, if you change the graphic design you'll be changing your markup. In this particular example you likely don't need class names at all because you can specify the divs and h3s unambiguously from their position in the markup, e.g. ol.listName li h3 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: memberh...@webstandardsgroup.org ***
Re: [WSG] dl as paragraph?
At 10/12/2009 04:01 PM, nedlud wrote: I was just looking at a page on the National Library of Australia web site (<http://www.nla.gov.au/services/issnabout.html>http://www.nla.gov.au/services/issnabout.html) and noticed the font rendering was strange in my browser (Firefox 3.5.3). When I looked at the markup to try and understand why, I found that the site seem to be marked up using definition lists for paragraphs. I don't want to jump to conclusions, so can anyone suggest a legitimate reason for doing this? Each paragraph seems to be a new list (not a new list *item*. A whole new list). My guess is that the markup was engineered by someone still learning the ropes. The page content is in the form of a Q&A and they validly selected a definition list as the markup structure, but then they decided to use h3 for the questions and realized an h3 couldn't be the immediate child of a dl so they dropped out of the list structure for each question. I think a better solution would have been to make the whole FAQ a single dl and drop the h3's. And the text is in a dd tag with no dt. I believe that's valid markup. As I read the DTD, a definition list must contain at least one dt *OR* dd but doesn't require at least one of each: http://www.w3.org/TR/html4/struct/lists.html#h-10.3 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: memberh...@webstandardsgroup.org ***
Re: [WSG] a tiny usability question on web form
At 1/5/2010 06:19 AM, tee wrote: Was making a web form for a commercial software which clientele are mainly from EU countries, in the original form the order of the Country field. The order looks like this: address/street country state city zipcode Maybe I'd been making too many web forms for US and some Asian countries' clients, I find it creates a tiny usability issue for user to have the country field places above state, city and zipcode. From my own experience, I always use tabbing to navigate web form, in a few US sites that I did shopping and that has country, city, state and zipcode setup in a non-US format, I find them to be a usability problem because I didn't read carefully but out of habit (and this is something I expect many web users would do), entered my address expecting them to be in standard US format. My client thinks otherwise: ... from a usability standpoint it seems weird to me to for example show the "Country" field AFTER the "State" field. Why? Because the "State" field is depending on the Country field. I have often placed the nation before the state/province for exactly this reason, but nearly as often my clients protest that it's just too weird and unconventional and they don't want to confuse or put off their customers. One solution is to ask the nation first, perhaps in a form by itself or before the rest of the address fields are revealed. Another solution is the make the state/prov field a plain text field, not a drop-down, and then validate it after the nation is entered (or the default nation is accepted through form submission), and if invalid present a drop-down based on the nation. Another solution is to combine nation & prov in the same drop-down: Afghanistan Albania ... Aruba Australia - ACT Australia - New South Wales Australia - Northern Territory Australia - Queensland Australia - South Australia Australia - Tasmania Australia - Victoria Australia - Western Australia Austria ... This wouldn't be egregiously unwieldy unless you broke out a lot of nations rather than just a few. The most common break-downs I do are for Australia, Mexico, UK, and USA. Many nations don't require or prefer a state/province/canton as part of a mailing address. Has anyone here done the leg-work to determine which nations do? On quick google I found this chart of mailing address formats around the world: http://www.bitboost.com/ref/international-address-formats.html#Formats I don't know how up-to-date it is. On the note of US-myopia it's worth pointing out that in many countries (particiularly Europe) the postal code precedes the city, e.g. 00-940 Warszawa Poland ...and some countries such as Russia are "big-endians" and sequence the address as nation, postal code, city, street address, recipient (although naturally they cope with the little-endian format when processing international mail). Also, remember that "ZIP Code" refers to the US only; everyone else calls them postal codes or equivalent. "ZIP" is an all-caps acronym for Zone Improvement Plan coined by the US Postal Service in 1963. Yet more reasons to query the nation first~ 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: memberh...@webstandardsgroup.org ***
Re: [WSG] CSS off button
At 1/22/2010 12:22 PM, Erickson, Kevin (DOE) wrote: Could anyone please tell me if there is a right way to put a clickable button in a web page that will turn off all CSS? To be perhaps overly precise, I'm guessing that you probably don't want to turn off *all* styling because that would render your document as one long string of undifferentiated text, but instead you want to keep the browser's default styling and/or the user's custom styling and suppress the page author's additional styling. The approach would most likely be to strip out the style elements from the html head and the style attributes from all elements on the page. I think it would be unreasonable to ask a program to also suppress styling imposed by client-side scripting but if you were being paid enough this would be doable. The best practice way to do this would be, first of all, to provide a submit button or link that asked a server-side script to re-deliver the current page with style elements and attributes removed. Then you could add a JavaScript layer that intercepted the button click and stripped away styling on the fly. I don't think removing the style elements in the head after a page is rendered has the desired effect, so you'd probably have to delete all the children of the style object in addition to deleting the style attributes on the page. Depending on your purpose, you'd also want to decide whether to strip other presentational elements and attributes at the same time. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] :: makeready ::
At 1/26/2010 01:07 AM, David Laakso wrote: Comments and suggestions on this site appreciated. markup <http://chelseacreekstudio.com/mhr/> The blank alt attributes for the foreground images are brow-wrinklers for me. When an image is in the foreground I figure that it is "content" that contributes substantially to the comprehension of the site, and I see no reason to withhold that information from search engines and other sightless users. In contrast, when an image is purely "decor" and contributes aesthetically but not "informationally" then I like to see it as a background image where it hovers ghostlike, insubstantial, visible but not touching the content nor touchable by a parsing hand. (Of course the aesthetic components of any work are part of its total information, but in terms of the content/presentation dichotomy we work with every day we can usually separate them with little effort. For example, which foreground and background colors you use for a website featuring construction equipment are irrelevant to the product content at hand. The colors might well be relevant to the client if they echo the corporate palette, but not worthy of bringing to the attention of a screen-reader or search engine -- except in those cases where the cosmetic design is brought to the foreground in an article on corporate communication or web design.) 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
At 1/29/2010 06:09 AM, Jason Grant wrote: I feel there has been LOADS of 'accessibility is a must' type discussion on this list, but at the same time I feel that there is loads of arguments which are essentially 'accessibility for the sake of accessibility'. My point is that we are heading towards the times where 'relevant accessibility' is more important than 'accessibility' per se. Please have a read of my article and comment via email or on the blog itself. http://www.flexewebs.com/semantix/accessibility-does-not-matter/ Sorry, Jason, but your essay is so poorly thought out and poorly written that you've given critical readers little to work with. You're just throwing a cat into a dog pen to watch the fun, and it's not even a real cat. If you really think there are types of websites in which accessibility concerns are irrelevant, list or describe them, but really all you're doing is exposing your own lack of broad, deep, and empathetic thinking. When accessibility matters ... * A company cares about their users You could have stopped right there. Glumly, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] I need a professional eye.
At 1/29/2010 08:36 PM, PurencoolGmail wrote: The site is www.purencool.com All I want to know is there too much css? No. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com PS: Are you *sure* this is all you want to know? What does the question mean? Too much CSS for what? If you're concerned about the size of your stylesheets, the two supporting the home page are only 5 KB so I would say No. If you're worried about the number of CSS rules, perhaps because you're afraid it will be difficult to maintain or degrade browser response time, I would say flatly No. Or do you mean that you're worried that the site might be over-styled? I would say no, it looks simple and open (which I like). I'm not positive what over-styled might look like, perhaps with too much decorative detail, but your site doesn't have that problem. I do see some problems with the site most of which have nothing to do with CSS. (Yes, I know you didn't ask.) - Neither the image fader nor the calculator worked properly in my Win Firefox 3.6 or IE8. Shall we assume they're still under development? - The calculator breaks on text-only zoom enlargement. It would be simple enough to style its widths in ems so that it grows naturally with text zoom. - I dislike the fact that your nav menus don't have hover states or an indicator of which page we're currently on. - The footer menu text looks too high in the blue bar at normal zoom, and both menus quickly break cosmetically on text-only zoom. (It's easy to make menus with stretchable graphics.) - The demos aren't enough to "sell" your apps. I recommend that you take a few paragraphs to detail their functionality, scope, limitations, and flexibility. I don't want to have to download a script merely to find out whether I can use it; that feels pushy and invasive. - It's irritating that your demo pages lose the nav menus so the only way to get back to the rest of your site is by Backing up. Keep in mind that many people will land on a demo page right from a search engine or other link and you want to make it easy for them to browse your site from there. - I think you should let people view the demos immediately, either right there on your home page or on the Services page. Why do we need to go to a separate demo page at all? Far better to integrate the apps right into your own site as an implicit demonstration of their integratability. - Personally I think the delay on your fader is at least twice as long as it should be. Making people wait to watch a cosmetic effect is irritating. - Your home page headline "Latest Product or Service" is odd. First, the ambiguity of the headline is mysterious; after all, it's your site so you should know whether the content below is a product or a service which are two very different things. Second, you don't have a Products page listed in your nav menus, and the Product or Service featured on your home page is in fact a product, creating an unnecessary and off-putting confusion. Perhaps "Services" in the top nav menu should be P & S. Any feed back would be great and you don't have to be nice. *Whew!* Good luck with your site. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Assistance with flash example sites
At 1/31/2010 07:52 PM, Russ Weakley wrote: A colleague has just asked me for some examples of Flash sites: 1. examples of flash sites which are not keyboard accessible (and/or poor tab ordering) 2. examples of flash sites which ARE keyboard accessible A wrinkle in keyboard accessibility is what I think of as the Black Holes of Flash: when a Flash application swallows keystrokes that normally operate the browser such as the CTL and ALT combinations in Windows. It's commonplace in my experience that Flash developers will prevent me from using CTL-w to close the current tab, CTL-TAB to switch to the next tab, ALT-whatever to use the browser's menu, and so on. They're not even re-purposing the keystrokes for new uses in their applications, they're just eating them. Keyboard accessibility can therefore be seen as a matter of degree, not merely true/false. A Flash app might itself be keyboard-accessible but still be quite frustrating for a keyboard user for whom the Flash app is not the only activity in their day. If you can't leave the browser window running Flash without using a mouse, someone's botched their job. An example of a Flash application which itself is, alas, not keyboard-accessible but that does honor browser keystrokes is the jacket designer <http://tmathletics.com/designer.php> which we produced a few years ago. (The next-gen version we're producing this year will be accessible!) 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: memberh...@webstandardsgroup.org ***
Re: [WSG] e-mail link
At 2/1/2010 08:29 PM, Marvin Hunkin wrote: what is the correct code for the subject line to appear in e-mail. Marvin, here is a link to a summary of mailto syntax: http://www.ianr.unl.edu/internet/mailto.html For much more detail, here is a link to RFC 2368 "The mailto URL scheme" written in 1998: http://tools.ietf.org/html/rfc2368 As you may know, there are problems using mailto links on a website, one of which is that spam spiders look for them in order to harvest email addresses. There are ways to obfuscate or conceal an email address in a mailto link but many methods are inaccessible or require JavaScript to be running or both. One very low-tech but possibly effective method is to verbalize the email address, such as "chris at example dot com" with "at" and "dot" spelled out. In order to fool the spam bots, you need to conceal both the email address displayed for the visitor and the address within the HTML href attribute. Another problem with using mailto is that it assumes that the website visitor's browser can find an email client on their computer. Best practices urge us not to make assumptions about software installed on users' computers. Many people do not use an email client resident on their computer but instead use an online service such as gmail. Mailto will also fail or cause problems if the visitor is using a public computer at a library or internet cafe. One of the most common solutions is instead use a contact form that posts information to a server-side script which can validate the input, check for obvious spam, and if satisfied generate an email message containing the form input. There are many free contact form scripts kicking around the net in a variety of scripting languages to suit your server. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] FINAL VERSION OF MY SITE
At 2/3/2010 02:47 PM, Marvin Hunkin wrote: http://www.raulferrer.com/joe/html/ Hi Marvin, Overall I found this to be a clear and attractive site. Good work! A few quick notes: 1) Phone number formats vary from place to place, but in North America at least the convention is to insert spacing or punctuation between the first '1' and the area code. I would change "1800-Joe-Fruit" to "1-800-Joe-Fruit" unless the Australian convention differs. 2) Many people find phone numbers translated to letters annoying or difficult to use. I recommend that you repeat the phone number in all digits: "Phone 1-800-Joe-Fruit (1-800-563-37848)" 3) The address of the shop at the bottom of the home page looks odd because the lines are spaced apart, which is the default styling for paragraphs but not for addresses. I suggest using either a break tag between lines (addresses and poetry being two good opportunities for the poor unappreciated break tag to do its thing) or style those paragraphs with no margin-bottom. In order to separate the mailing address from the phone number lines, I would do this by enclosing the physical address in one div and the phone number lines in another: Joe's Fruit Shop 55 Main Road Anytown 2999 Phone: 9555-9876 For phone orders: 1800-Joe-Fruit That will leave a gap between clusters of paragraphs but no space between the paragraphs themselves inside each div. 4) On the Recipes page you are using break tags to insert space after the h3 subheads. Please remove them, and any other break tags you're using for spacing. The amount of space you've inserted here looks unattractive, it's confusing because it separates a headline so much from the text that belongs to it, and using break tags in this way contradicts the separation of content from presentation that is one of our industry's best practices today. If you want to present more space after h3's, do so using your stylesheet. 5) The Search page seems out of place and mis-named. It's really an index to the Produce page, not a search function. I would move the index to the top of the Produce page. If you want a true Search page you can do so easily using a common search engine. If you want to keep this page on its own the way it is now, at least consider renaming it "Produce Index". I would place it immediately before or after the Produce page in the menu. 6) In your main menu, "Fruit And Vegetable Recipes" might be better called "Fruit And Vegetable Recipe Links" 7) On the Credits page, you've inserted two break tags immediately inside the first list item, causing "Mike Levin's Photo Gallery" to site two lines below its bullet. The main navigation menu has the same problem, with break tags in the list item for the home page, causing the nav menu to look broken on this page. 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: memberh...@webstandardsgroup.org ***
RE: [WSG] CSS off button
At 2/4/2010 10:43 AM, Erickson, Kevin (DOE) wrote: Here is the page using your example: <http://www.doetest.vi.virginia.gov/z_testing_area/kevin/test-css-off-from-wsg2.shtml>http://www.doetest.vi.virginia.gov/z_testing_area/kevin/test-css-off-from-wsg2.shtml I recommend that you give folks a corresponding button to turn styling back on after they switch it off. 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: memberh...@webstandardsgroup.org ***
Re: [WSG] Minimal forms or marking up a search field
A practical distraction for the standardistas and accessibility gurus�
Hoping tap your brain for an alternative perspective on the simple and
common HTML scenario of a site search form.
...
To revisit this topic, I'm considering the
following and would appreciate feedback:
_
a) Submit button as label:
_
b) Label hidden from view:
Search:
label#search-label
{
position: absolute;
left: -1000em;
}
_
The rationale for both of these is that the
"Search" submit button serves as a clear and
unambiguous label for the input field. In listing
a) the button is literally the label; in b) there
is a separate literal label present in the markup
but hidden from cosmetic view.
Both validate for W3C HTML & Cynthia 528 & Accessibilty.
Can you see any problems with them?
I favor a) but it feels edgy.
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: memberh...@webstandardsgroup.org
***
Re: [WSG] blockquote
At 4/3/2010 07:39 PM, T. R. Valentine wrote: Apparently, cannot be used alone. It produces 'character data is not allowed here'. What does it need? Check the spec: HTML 4.01 Specification 9 Text 9.2 Structured text 9.2.2 Quotations: The BLOCKQUOTE and Q elements http://www.w3.org/TR/html4/struct/text.html#h-9.2.2 This excerpt from the Document Type Declaration specifies that the only children of blockquote permitted are block-type elements and script. In other words, text within the blockquote element must be enclosed in a p, div, list, or other block-type element. Also, can the tag have a class assigned to it? Let's find out. From the above reference: This specifies which attributes blockquote may have. The symbol %attrs is defined as: ...%coreattrs in turn is defined as: So yes, you may validly assign a class attribute to a blockquote element. 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: memberh...@webstandardsgroup.org ***
[WSG] seeking JavaScript Bible reviewers
Hi all, I'm looking for established reviewers of programming books to whom to send copies of the JavaScript Bible 7th Edition (Wiley, 2010). http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470526912,descCd-description.html If you're interested please write to me off-list, let me know what publications you write for, and include links to some of your published book reviews. Thanks, 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: memberh...@webstandardsgroup.org ***
Re: [WSG] commonly used order of styles within a css class
On Fri, 3 Sep 2004 15:19:12 +1200, Sean <[EMAIL PROTECTED]> wrote: > Does anyone know if there is a common way of listing styles in CSS? ... > For example, perhaps the font and inline information is first, the > block, padding and margin information next, and then the positioning. Sean, I've seen more styles of styling than there are stylers! My personal preference is to step from properties that are most likely to affect other elements on the page to properties that are least likely to do so: - first properties of position & visibility (position, display, visibility, z-index...) - then properties that affect dimension (height, width, margins, borders, font-size...) - finally properties that don't affect dimension (text-align, background, color...) I hold to this convention loosely; I also find it convenient to group related properties together, for example z-index with position and all the font properties together whether or not they affect box dimension, and I put padding immediately below margins because I tend to work with them simultaneously when I'm tweaking a page. Whatever system you develop, being consistent over time will help you quickly locate properties you need to adjust, and will help other programmers (and your future self!) to modify your code more easily down the road. Your own style of styling should make natural sense to yourself so you can move around in your files intuitively. Personally, I'd never sequence properties alphabetically because I suspect I'd constantly interrupting my thought processes of semantic and graphic organization to recall how property names are spelled -- whereas alphabetization might come as second nature to someone else with a differently wired brain. Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Overflow on select or options
At 01:47 PM 9/12/2004, [EMAIL PROTECTED] wrote:
I want the text to overflow if the value of the option is greater than the
width...
> select, option
> {
> width: 250px;
> overflow: visible;
> }
Taco,
I think the default for most browsers is to render the select list widely
enough to accommodate its option text, so won't you get what you want if
you don't specify a width?
Paul
**
The discussion list for http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Overflow on select or options
At 05:09 PM 9/12/2004, [EMAIL PROTECTED] wrote:
I want a default width, i.e. all selects to be 250px, if there is overflow
I want to see it...
Taco,
I think I accomplished your goal simply by nesting the select list inside a
div with a constrained width and overflow: hidden:
___
Apple
Banana
Cardomon and cinnamon are two spices that begin
with C
Demerera
#listwrap
{
width: 250px;
overflow: hidden;
border-right: 2px inset black;
}
___
I just tested this successfully on my five Windows browsers -- IE6, Opera
7.23, Mozilla 1.72, Mozilla Firefox 0.8, and Netscape 7.1.
One cosmetic flaw is that the select list's control button is hidden from
view, however the list opens and functions fine when clicked on even
without the control showing.
Another flaw is that the right-hand border of the list is hidden, however
I've quickly & dirtily remedied this by assigning the div wrapper a
right-border to compensate. This, however, will probably not look good
with the Macintosh's rounded style so a better solution is needed.
Paul
**
The discussion list for http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Free GMail Invites -- NOT
Friends, These gmail offers are cluttering every listserve I'm on. They're invariably off-topic and feel to me like some sort of good-natured spam. Is there a more appropriate forum for them? If not, could all responses to such offers be kept off-list? Thanks, Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] start attribute deprecated in XHTML 1.0 Strict and up.
At 12:33 AM 9/17/2004, Nick Lo wrote: 1. The Transitional doctypes for HTML 4.01 and XHTML 1.0 support the `start` attribute for ``, and a `value` attribute for ``. ... 2. The W3C deprecated both of these attributes; thus they're invalid in the Strict doctypes for HTML 4.01 or XHTML 1.0. ... Now I'm not using XHTML higher than 1.0 Transitional but I thought this was noteworthy ...if it is correct. For any of you using XHTML 1.0 Strict and up, it is possibly something that may influence your decision making. *Sigh* I'm not willing to give up on using XHTML Strict for all my new webwork, but the I do miss being able to renumber lists. I was banging my head against it this past week and ended up using a series of unordered lists in which each item contained its item number: First Section 1. Blah 2. Blah 3. Blah Second Section 4. Blah 5. Blah Embarrassing, but functional. Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Wrap I say Wrap! Down Boy! good IE dog, here's a biscuit
At 09:56 AM 9/17/2004, Ted Drake wrote:
p {margin: 1em 0 1em;padding: 0; text-align: left; width:90%;}
img {border:0;}
#maincontent img {float:right; margin:3px;}
When I view this in mozilla the paragraph wraps nicely but the IE
paragraph acts as if it has cleared and starts after the image.
...
I then noticed the paragraph width tag and said to myself:
"Could it be the width:90% that is doing it? I added the width to keep
the paragraphs from getting too long."
I then commented out the width and checked, sure enough IE began playing
nicely. So, how do I get the good browsers to show the narrower
paragraphs and IE the nicely floated image?
Ted,
Ironically, the way IE is behaving appears to be according to the CSS2.1 spec:
http://www.w3.org/TR/CSS21/visuren.html#floats
(I don't see that particular example of a float defeated by too wide
content in the CSS1 & CSS2 specs.)
This is actually the way I would have expected CSS to act, although maybe
that's just my own inexperience talking. I'm under the impression that
when you specify a width it overrides float requests. Note for example the
way floated columns fall apart when their combined widths are even a pixel
too wide for the window. The browsers are behaving
I would have expected your problem to be solved by declaring
max-width: 90%
Regards,
Paul
**
The discussion list for http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Footer stuff
At 06:22 PM 9/19/2004, Amit Karmakar wrote: What is better in terms of semantics and accessibility? stuff | more stuff stuff too | more stuff again or stuff | more stuff stuff too | more stuff again Amit, I suppose you need to ask yourself, why are you splitting the list visually into two rows? Is it because you're grouping the items in semantic pairs, or is it because two items are all that seem to fit, given your particular font size and container width? Guessing that your reason for splitting the list is presentational, not semantic, I'd go with the unordered list where the split into rows can be handled by CSS. One way to do this would be to assign the block LIs "float: left;" and the UL a constraining width. The list items will fill out the list width and then wrap to the next row. Depending on the width of their container, this might be one row or two or more. If you change your page layout in the future to make the container wider or narrower, you won't have to worry about moving that pesky line-break -- your list will break naturally at the new width. On the other hand, if you're splitting the list for semantic reasons, I'd still use UL/LI, but I'd make each sub-group of items its own unordered list: item 1 item 2 item 3 item 4 As to your list separators, I don't believe unordered lists are supposed to contain anything but LIs, so your " | " characters between LIs wouldn't validate. I've used various methods to get around this. One way is to include the delimiter in each list item: item 1 | item 2 item 3 | item 4 Another way is to give the delimiters their own list items: item 1 | item 2 item 3 | item 4 I don't really like either method when I'm considering the delimiter to be presentational, not semantic. I don't use the :after pseudo-element yet, only because it doesn't work cross-browser. An alternative that utilizes CSS is to introduce the delimiter as a background image for selected items. Of course, this doesn't advance one's CSS karma, because in order to assign the delimiter to selected items it's necessary to mark those items in HTML: item 1 item 2 item 3 item 4 This is, in fact, flagging presentation in HTML, so we haven't advanced much if any from the old school. Any suggestions for how to exit the box? Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] Is it possible...
At 03:20 PM 9/21/2004, Ted Drake wrote:
Here's the simplified version. You have 5 tabs, Forside, Services,
Produkter, Resume, and Kontakt.
...
Now, lets do the same for your other tabs
body.kontakt ul.tabs li.kontakt, body.forside ul.tabs li.forside,
body.services ul.tabs li.services, body.produkter ul.tabs li.produkter,
body.resume ul.tabs li.resume {current tab styles}
Nice explanation, Ted. Although I think your example would be easier to
read and understand if you stacked the selectors vertically:
body.kontakt ul.tabs li.kontakt,
body.forside ul.tabs li.forside,
body.services ul.tabs li.services,
body.produkter ul.tabs li.produkter,
body.resume ul.tabs li.resume
{
[current tab styles]
}
It's worth noting that the parent element whose class matches the list item
can be any container in which the list items reside -- the html body, a div
that contains the unordered list, or the unordered list itself.
This CSS selector:
.kontakt li#kontakt { ... }
(just the parent class, no element specified) works with any of the
following html nestings:
The remaining question, of course, is how to set the body class according
to what page you're on. I know of three ways:
1) you manually create the html pages with the body class names pre-set, or
2) you write a server-side script that creates the pages with the body
classes pre-set, or
3) you write a JavaScript function that sets the body class when the page
loads.
Kim, because those scripting methods are outside the boundaries of this
list, feel free to write to me directly if you'd like some suggestions in
this area.
Paul
**
The discussion list for http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
[WSG] CSS rules & quirks database
Friends, Drowning as I am in the unending flood of details about CSS -- what works and what doesn't on which browsers, and how to make a particular effect work cross-browser -- I've started conceiving a database to augment my maxed-out cerebrum. Such a database could be queried for suggestions of how to accomplish a given presentational task, to advise about the cross-browser issues of particular elements, and to provide links to source material and demos on the net. Ultimately it might be made into a validator to help folks pinpoint problems in their markup. It would contain the kinds of details that are imparted daily on this glorious list, although I cannot imagine it ever rendering CSS listserves obsolete because of the endless fountain of human invention they convey. Before I get too far into this project, I'm wondering: - Is anyone else working on this kind of thing? - Would you like to join a working group to discuss its feasibility and implementation? Thanks, Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] CSS rules & quirks database
At 05:00 PM 9/23/2004, Tony Aslett wrote: I created a list of CSS properties and browsers that support them http://www.csscreator.com/attributes/ Excellent work, Tony. Are you storing this in an SQL database? I'd like to see some other layers of information added to a database such as yours. For instance, in addition to generalizing None, Part, or Full support of a property by various browsers, I'd also like to specify exactly how they differ, since all browsers that "support" a particular feature may not do so in the same way. There are also quirks that don't quite come in the category of "support" but are critical nonetheless, such as the way IE requires there to be a background-color in order to render certain elements properly. Other quirks, such as IE's maverick box model, would be difficult to categorize in a listing of properties but could probably be referenced under such properties as margin & padding. There are certain phenomena that occur when several properties and elements interact, and it would be great to be able to find out what the database knows about, say, a UL nested inside a DIV when its LIs have float: left. Onward~ Paul ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Are empty divs okay?
At 11:35 AM 9/29/2004, Shane Helm wrote:
I have some empty div tags to be able to make a graphic a background image
since this presentation is common to all pages.
For example in my html:
My CSS for "header3"> is as follows:
#header3
{
position: relative;
width: 836px;
height: 37px;
margin: 0 auto;
padding: 0px;
background: #2A331F url(../img/header3.gif) no-repeat;
}
Since I this is only my second site using Web Standards, I'm unsure if
leaving a div tag empty is okay or not. Or is there another method I
should be using?
Shane,
Consider using h1-h6 for headlines on your page. Semantically they mean
"headings" while a div is merely an anonymous division. Your page should
make sense when your stylesheet is missing. If you view your page without
CSS or images, does it lose meaning without the headline showing? If so,
here's an alternative way to mark that up:
Frog Doggies
h3
{
background: ...;
}
h3 span
{
display: none;
}
If CSS is enabled, the image displays and the text is suppressed.
If CSS isn't enabled, the text displays but not the image.
Where this "image replacement" solution fails is in user agents in which
CSS is enabled but images are suppressed.
Paul
**
The discussion list for http://webstandardsgroup.org/
Proud presenters of Web Essentials 04 http://we04.com/
Web standards, accessibility, inspiration, knowledge
To be held in Sydney, September 30 and October 1, 2004
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re:_[WSG]_OL_or_UL? _It´s_rigth?
At 05:19 PM 10/4/2004, Parker Torrence wrote: Yes you can http://www.w3.org/TR/html4/struct/lists.html section 10.2 see DEPRECATED EXAMPLE: which is: ... Level one, number one... ... Level two, number one... ... Level two, number two... ... Level three, number one... ... Level two, number three... ... Level one, number two... It's my understanding that the LI tags remain open until closed either explicitly with or implicitly by the next or the final or . Because this example is HTML, not XHTML, and the LI tags are not explicitly closed, I believe that the OLs in that example are embedded in fact in the LIs and not the UL/OL elements. The same is true of the old-fashioned table markup. If you saw this: Here is a paragraph Here's another cell ...would you say the paragraph was embedded in the TD, the TR, or the TABLE? It's in the TD, of course. 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] Table-style admin layouts
At 11:22 PM 10/4/2004, Ryan Sabir wrote: Is there a best-practice way to build an item display with multiple columns, but without using tables? What I want to do is build something like this: Name Price Quantity EditDelete Apple $5.0025 [edit] [delete] Pear $4.00 3 [edit] [delete] Banana $12.00 5 [edit] [delete] But without cluttering the HTML with table layout data... Yes, use a table, but no, don't clutter your html with layout attributes. Move all the rules for how things should look to a separate CSS file, leaving your html clean & sleek. The most clutter you'll need to deal with are class names in your TD tags to deal with the variety of data formats you're presenting: Apple $5.00 25 This way you can make decisions about how each cell is formatted & aligned separately from your decisions about which data appear there. Cheers, 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: Re[2]: [WSG] Table-style admin layouts
At 12:26 AM 10/5/2004, Rick Faaberg wrote: But if those data are coming from a database and are being output via a script language for example, I think a table is the most convenient way to present the data and the buttons. It boggles my small intellect to think about outputting CSS positioning and stuff from PHP or whatever, although somebody's working on that I'm sure! Of course, the beauty of separated CSS & HTML files is that the PHP or ASP server-side script can pump out pure HTML without any regard for how it's supposed to look. The content can be dynamic while the stylesheets remain static. 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] anchors within a page
At 12:05 PM 10/6/2004, john wrote: I want to put a "top of page" link in the footer of one of my sites, so instead of using the tag, I to one of my ID's. The problem is, I've used "z-index" in the CSS so that the header and nav stay put when scrolling...but it doesn't work in IE. The result is that, in IE, when you hit the "to the top" link, it doesn't take you all the to the top of the page (where you can see the header and nav). John, Why not just put at the top of the page? Some browsers don't appear to need a corresponding named anchor if the link is to "#top". Here's a test page in which you can see how your various browsers behave. http://novitskisoftware.com/test/topofpageTest.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 **
Re: [WSG] li element with a sticky+remote rollover
At 09:48 AM 11/23/04, Ben Curtis wrote:
I want a list of products which on mouse over triggers a preview image to
the left of the list as well as an arrow pointing to the product currently
being previewed. The arrow and preview are sticky; if you mouse off of one
without hitting another, nothing will change.
...
Ben,
Just a quick note about the sticky aspect of your page: I too use
javascript in these cases because I don't know of a way to implement
'sticky' using CSS alone. To minimize the script, however, I use js merely
to copy the id of the hovered item to be the class name of the page body or
another box that contains the objects I want to toggle. Then, instead of
using script to swap images, etc., I let CSS handle all the presentational
manipulations.
Here's a stripped-down example of what I mean:
_
Bear
Cougar
Deer
_
/* javascript function applied to LI mouseover */
function jsItemHover()
{
body.className = this.id;
}
_
/* toggle image display */
img
{
display: none;
}
body.bear img.bear,
body.cougar img.cougar,
body.deer img.deer
{
display: block;
}
/* toggle menu selection */
li
{
color: #09c;
}
body.bear li#bear,
body.cougar li#cougar,
body.deer li#deer
{
color: #000;
}
_
In practice, I enhance this technique to fail relatively gracefully on
browsers lacking CSS and/or JavaScript support.
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] Sometimes you just cant help people ...
Since "navigation" presents a jargon problem, perhaps "menu" or another less techie term might work: Skip past menu Jump over menu What's an appropriate metaphor for a navigation menu if you're not a programmer and if your interaction with the menu is functional & auditory and not visual? Also I wonder whether a concise table of contents for the page would work: Jump to: - page content - page menu - website menu - page footer Once users became accustomed to such a convention, they would know to take the first option most of the time. And better than proceeding by speculation and trial & error, of course, would be to poll visually-impaired users to find out what metaphors & wording they'd prefer. I imagine this has already been done...? 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] Info on correct semantics
At 10:10 AM 12/3/04, Michael Vogt wrote: Some days ago I had a short discussion with a colleague about a display bug in (surprise) IE. The solution he found was to replace all tags (except html, head, body I guess) with and style the layout with CSS. He really means it, and he was proud that he has found a solution to all(!) display problems in IE. Michael, If I had to replace all the meaningful tags with a single meaningless tag, I'd choose before just because it's by default a block element and most of my page layout structures are blocks. Theoretically this might not matter because one can change block to inline and inline to block in CSS, but scary creaks from the attic of my memory tell me that such transformations don't occur the same cross-browser. (Does anything?) Besides, in the absence of CSS an all-span page would turn into a solid unbroken block of words whereas an all-div page in most user agents would at least be a series of separated text blocks. Yes, reducing down to a single tag for all structures would probably reduce your screen-painting headaches but it wouldn't eliminate them, because, for example, different browsers use different rules in rendering the box model. Of all the problems that people bring to CSS-D, I think the vast majority pertain to blocks. If you forsake all tags but one you'd gain only about an inch of ground. And lose a mile. If a web page were merely a palette of light perhaps it wouldn't matter what structure underlay the various shapes we see (and hear). But a web page is a structure of meaning. Rendering a page in a particular graphic layout is only one layer of the cake. The more meaning that can be derived from a page, the more function can result from its interaction with user agents, spiders, and other page-reading entities. Perhaps if your colleague could listen to a tag-less page with a screen reader he would be appalled by his own suggestion. Good luck, 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] Semantic Breadcrumbs
At 04:17 PM 12/3/04, Richard Spence wrote: In my opinion a simple string of would work just fine. The information that you are trying to display is not really a list. So a string of anchor links in a paragraph or span would work the best. 1) Homey thatched cottage with warm hearth 2) Known friendly forest with tweeting birds 3) Strange creepy forest with growling beasts 4) Gingerbread cottage with hot oven This looks like a list to me, and an ordered one at that. If Gretel and I stand any chance whatsoever of getting back to Father, we'd better find those breadcrumbs in sequence or our goose is cooked (so to speak). 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] a quick target question
At 10:03 AM 12/6/04, Patrick H. Lauke wrote: *Don't* use onkeypress, as Mozilla browsers - and rightly so - treat a TAB as a keypress as well. Using onkeypress makes it impossible for users to TAB beyond that particular link. Isn't it true that, if one did use onkeypress, the attached event handler could examine the key value and allow TAB to pass through untrapped? I'm not one to advocate unnecessarily complicated code when a simpler method is close at hand, but 'impossible' is a strong assertion. 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] a quick target question
At 10:11 AM 12/6/04, Ted Drake wrote: I'm a bit confused by the (this.href) code. Should I replace that with the page in the href="" section or is it looking back at the href and use that url? -Original Message- From: Veine K Vikberg [mailto:[EMAIL PROTECTED] Whatever.com The keyword 'this' refers to the object at hand: in this context, this refers to the element in the Document Object Model. You can find an excellent introduction to scripting events on Peter-Paul Koch's http://www.quirksmode.org/ Aside, while it may be convenient to embed javascript in HTML tags by way of illustration, let me reiterate the oft-made point that doing so in practice is a mistake, for at least these two reasons: 1) User agents that don't support the scripting language or any of the functions used in the script will throw an untrappable error. Better to apply behavior to objects on the page from a safe distance whereby nothing occurs when the script is unsupported. The most common way to do this is to engage an initialization script with the window.onload event which checks specifically for support before adding behavior to objects on the page. 2) Separating content (HTML markup) from behavior (script) from style (CSS) is A Good Thing because modular software is easier to maintain, and because old, cranky, or idiosyncratic browsers can more easily be protected from components they don't support. I would therefore mark up that tag (uniquely identified so a script can find it easily) simply as: Whatever.com or: Whatever.com and apply the behaviors separately from a linked script. 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 Windows
At 11:11 AM 12/6/04, Felix Miata wrote: Fresh meat: http://www.useit.com/alertbox/20041206.html Yes, but only 605 respondents?! Yikes, that's a small sample. Nielsen's results, satisfying as they are to one allergic to commercialism, would carry more weight if the sample size were significantly greater. Perhaps someone blessed with a memory for statistical math can confirm how large a website-viewing population can be significantly sampled by just 605 respondents. 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] Site Critique - do your worst...
At 10:19 AM 12/9/04, Sam Hutchinson wrote:
...I can take it because I value the opions of users of this list :)
http://www.sammyco.co.uk/acttrwebpre/PRE%20VALIDATION.htm
Sam,
Action Transport looks like a great project! Here are some very quick
comments:
I suggest making the left-hand thumbnails redundant links to each section,
so that you can navigate either by clicking on "read more" or by clicking
on the image next to it.
Your use of the same coloration for links and headlines is
confusing. Better I think to flag links uniquely so the visitor can learn
quickly what text is active and what isn't.
The Birdbox image has fallen down below the left column, probably because
you haven't allowed enough room for it to float next to the left col. Try
counting your pixels more carefully, or perhaps better yet design your
layout more loosely so it won't break as easily.
I find the white text on red background ("I was right to trust Action
Transport...") too difficult to read.
I find the slowly unfolding nav submenus clever and irritating, and show
off someone's javascript tricks more than they show off a concern for the
site visitor. I would greatly reduce the unfold duration or scrap it and
just let the submenus pop down instantly.
When I hover over items in your right-panel nav menu, the text disappears
(turns white?).
Resizing text larger in Firefox (whether using FF's controls or the a+
control on your page) garbles your page heading and renders the nav menu
unusable.
Personally I find the stark red & purple a turn-off, but that's personal
and I suspect I'm not your target audience.
Glancing at the front page I did catch a typo: "How can you get involed?"
missing a v.
Have fun
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] text-align problem.
At 01:26 PM 12/9/04, Joshua Leung wrote:
By Email:
Administration: [EMAIL PROTECTED]
Projects: [EMAIL PROTECTED]
Services: [EMAIL PROTECTED]
Scott Nicholson:[EMAIL PROTECTED]
Managing Director
I'd try a definition list:
Administration:
[EMAIL PROTECTED]
...
dt
{
float: left;/* position dds to the right of dts */
clear: left;/ return to the left margin for each new dt */
width: 10em;/* or whatever width works */
}
dd
{
float: left;
margin-left: 11em; /* align the right column */
}
There are ample examples of this on the web; sorry I'm momentarily without
my usual bookmarks but you can google
css "definition list" float left
and find tons.
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: Off with your JS (was Re: [WSG] Best approach (new question))
At 07:02 AM 12/10/04, Tom Livingston wrote: But I can't help wondering if these things, and others mentioned, are done by people who *know* about these things. In my mind, that is a small minority. Most likely only developers. Do the 'Bob-The-Office-Worker', and the 'Mary-The-Surfing-Homemaker' (or vise-versa ;) ) types really know about this stuff? Tom, Bottom line: it doesn't really matter what populations you think are turning off javascript the most. "Even" if it's "only developers" you still need to engineer your pages to be both accessible and functional whether scripting is turned on or off. Just as you need to make your pages graceful enough that they can continue to be useful in the absence of CSS, image display, mouse peripherals, and human visual perception. We don't know what sorts of users and user agents will be coming to our pages, and there's a great appeal -- if not a mandate -- to make them useable by everyone. Fortunately it's feasible, thanks to the communities of bright, problem-solving, self-critical thinkers we've got in WSG, CSS-D, and other groups. Cheers, 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] A standards compliant remake.
At 04:16 PM 12/10/04, Chris Stratford wrote:
Just thought I would show off my little standards compliant remake.
http://web.archive.org/web/20031219222155/www.matryoshkasandmore.com.au/index.html
that was the original crappy thing.
I remade it to this:
www.matryoshkasandmore.com.au/
The site works relativly well - and I used tables for the product listings.
I would concider that tabulated data - so I dont mind.
Chris,
Good for you, the world needs more XHTML-Strict. I do, however, have a few
criticisms of your work:
Your nav menu is marked up as a table. Perhaps this is simply a matter of
personal perspective, but I consider a one-dimensional series of items to
be a list, not a table. Since your nav menu doesn't contain any
two-dimensional correlation of rows & columns, either in its data or in its
presentation, I don't agree with your choice of table markup. It appears
that you were motivated by a desire to use the table's grid layout, not a
"standards compliant" decision in my view.
Your defense of marking up the product listing as a table is weakened, in
my view, by the fact that you've actually used the table to establish your
page layout. Again, the rows and columns don't establish any data
relationship among the products but rather merely demonstrates your desire
to arrange them in rows. There's nothing that connects the items in a
given row or column except their position on the screen except the matching
of each photo with its Buy button. The fact that you've devoted a middle
row of your table for "One Week Special Only" -- a message that seems to
refer to the data as a whole -- is a further warning flag that this is a
layout table.
Aesthetically, I actually prefer the first screenload of the original
website over your reworking, primarily because your large, multicolored nav
menu seems quite garish compared to the muted character of the background
color, fonts, and art. Also, from a practical standpoint, the original
page let the photo of the dolls (the primary subject of the website)
dominate the top screenload, while your over-sized nav menu pushes them
down so they're barely visible in the top screenload in a 800x600 display.
I suggest you use a shorter line length and/or larger font and/or greater
line-height to make the text blocks more readable. I'd scale the width of
the text column in ems to maintain the font-size-to-column-width proportion
as the text is resized.
I find white font on pale blue background nearly unreadable.
Glancing at your HTML source for the front page, I see that you're using
inline styles in the nav menu -- is this "standards compliant"? I'd move
them to the external stylesheet file.
You've given your images the class names "right" and "left" which are again
presentational attributes embedded in the HTML. I'd change those to unique
ids or functional class names ("odd" and "even"?) and then assign their
right & left positions in CSS. The way your page is marked up now, if your
client decides tomorrow that she'd prefer the alternating photos to begin
on the left and not the right, you'll either have to change your HTML to
effect a presentational change (=warning flag) or change your CSS to the
silliness of:
.left {float: right;}
.right {float: left;}
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] Gallery markup
At 11:34 AM 1/4/05, Charles Martin wrote: Tables wouldn't do this. Also, lists are just easier for me to use than tables, and tables create more code weight than do lists. Anybody have thoughts on this? Well, for me, the deciding factor on using a table is if the elements contained in the table are 2 dimensional. Charles, I agree with you, however for the sake of completeness let me add that two-dimensionality doesn't mandate tables per se. A definition list is also two-dimensional -- N rows by N columns, with the structural peculiarity that first column is DT (inline) and the subsequent 1-N columns are DDs (block), structurally resembling a table in which the first cell of each row is a TH. 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] Class -vs- ID
At 06:23 PM 1/12/05, Chris Stratford wrote: I was asked for the first time yesterday, what the big difference and advantage to using an ID over a CLASS was... Chris, With regard to our intentions as scripters, what you and everyone else has said applies: ids are unique, classes are generic, and we should apply one or the other according to our understanding of the uniqueness of the object in the page structure. At the same time, if I'm in an ambiguous situation in which I'm not sure whether to use id or class -- say because I've only got one instance of the object and I'm not sure whether there will ever be siblings -- I might choose id simply for reasons of speculative browser efficiency: From a software mechanic's point of view, using id might be much faster than using class even if only one object is involved. [This difference in speed might or might not be too slim to be humanly perceptible.] I can easily imagine a browser resolving an id more quickly than a class. Within its memory structure there's likely just one position reserved for a given id, so that, when an id is referred to and the browser searches its internal index for a match, it will stop at the first match. In contrast, depending on how efficiently or inefficiently the browser has indexed objects by class, it may have to search the entire document object tree each time a classname is referenced to ensure that it catches all instances. Even if it's created a length-tagged array of objects with a given class, it's probably going to require a bit more processing to walk an array of even one member than it will have done to match a single unique id. But pay no mind: this kind of thinking is very Old School. Why, way back in dem olden times, we had to pay attention to machine cycles because it really affected response time on a human scale. Nowadays everything runs so fast we can just focus on how to do things right and not worry about how long it takes the computer to do it. Mmm, hmm! 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] Popups
At 11:58 AM 1/13/05, Jeffrey Hardy wrote: ... Here's an example of a call to window.open with the 'properties' argument: onclick="window.open(this.href, '_blank', 'width=500, height=500, menubar=no'); return false;" Nice summary, Jeff. One correction: you're not supposed to embed spaces in the properties list, so your example should read: 'width=500,height=500,menubar=no' Also, while it's convenient to insert javascript event handlers into HTML markup when demonstrating an example, in practice it's probably best to leave the script out of the markup and apply it from a separate script file at window.onload. 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] Popups
At 01:20 PM 1/13/05, Seona Bellamy wrote:
> -Original Message-
> [mailto:[EMAIL PROTECTED] Behalf Of Paul Novitski
> Subject: Re: [WSG] Popups
> Also, while it's convenient to insert javascript event handlers into HTML
> markup when demonstrating an example, in practice it's probably best to
> leave the script out of the markup and apply it from a separate
> script file
> at window.onload.
I'm curious as to how you do that, because to my mind it's a great idea.
Keeping it out of the markup would make sure that the code of the page
itself remains nice and lean and would also make it easier to remove the
popups altogether if such a feat was necessary.
Seona,
Here's a quickie example in which I assign Jeff's href event handler to a
single specific hyperlink:
===
HTML:
http://example.com";>Open the example site
===
JavaScript:
// this file is "assignevent.js"
// Tell javascript to run a function when the page finishes loading:
window.onload = jsAssignEvent;
// When the page loads, assign the event handler to the object:
function jsAssignEvent()
{
// don't run code the browser can't handle
if (document.getElementById)
{
// get the object
var oAnchor = document.getElementById("anchor1");
// assign the event handler
oAnchor.onclick = jsOpenLinkWindow;
}
}
// When the link is clicked, open the new window:
function jsOpenLinkWindow(evt)
{
// stop event propagation
if (!evt) var evt = window.event;
evt.cancelBubble = true;
if (evt.stopPropagation) evt.stopPropagation();
// open the link in a new window
window.open(this.href, '_blank', 'width=500,height=500,menubar=no');
// cancel the click event so the parent window location doesn't change
return false;
}
===
I recommend Peter Paul Koch's articles on event handlers & javascript at
http://www.quirksmode.org/
Cheers,
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] Two CSS Question
At 02:14 PM 1/13/05, Carl Reynolds wrote: If I have a section of HTML that is the same in all my files, is there a way to put it in a file by itself and include it into each page? Carl, Here are two ways (I'll be interested to learn about others): 1) Use a server-side scripting language such as ASP, Perl, or PHP to include component files into one downloaded page. ASP can do this either with the #INCLUDE directive or through file I/O using the FileSystemObject object, and I'm sure the other server-side scripting languages have comparable methods. 2) Use a JavaScript inclusion directive in your HTML headers, e.g.: ...in which navmenu.js contains something like this: var navMenu = ' Aardvark Bananafish ' ...and then write the value of navMenu into your document structure. 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] Popups (plus, standards-based event handling)
At 02:39 PM 1/13/05, Ben Curtis wrote:
Also, while it's convenient to insert javascript event handlers into
HTML
markup when demonstrating an example, in practice it's probably best
to
leave the script out of the markup and apply it from a separate
script file
at window.onload.
One beef I have with this code, and most code of this nature, is that
it uses this to trigger it:
window.onload = externalLinks;
This is fine, if it's the only code you are assigning to onload, but it
overwrites any previous onloads and is overwritten by subsequent
onloads.
Ben,
Wow, your method looks elaborate. When I have some more time I'll go
through it in detail and try to give you some feedback.
In the meantime, the way I get around the one-function-onload problem is
simply to load a generically-named function at the global level:
window.onload = jsInit;
Then, jsInit() can be defined differently by each page to load its own
batch of functions:
function jsInit()
{
var x = doThis();
var x = doThat();
}
This method isn't *ideal* because I have to list all of the onload
functions manually for each page, instead of simply attaching the functions
to the html file with
Re: [WSG] avoid Verdana -> I cant get the whole point.
At 08:32 PM 10/3/2005, Buddy Quaid wrote: I'm not trying to offend anybody here at all but so many posts about whether or not to use Verdana is just boring. Boring! Holy smokes, every technical field is boring unless the details happen to fascinate you. Boring isn't an attribute of information, it's an attitude of the perceiver. I don't read every posting in the web design listserves I belong to, but I'm glad I followed this particular thread because it yielded a gem I value highly when James Bennett wrote: I've found that the following works well for providing compatibility to Linux users (and as a full-time Linux user for a number of years, I can personally attest to its effectiveness): Verdana, "Bitstream Vera Sans", "Lucida Sans", sans-serif ** 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] Background Alignment
At 11:45 PM 10/3/2005, Helmut Granda wrote: I have a background that is centered horizontally but tiled vertically. ... Everything looks fine the only difference is 1 pixel between IE and FF. Has anyone encounter a similar problem? Note: The background is 700px in width. How wide is the background image? Perhaps it's simply a rounding issue that can be resolved by making the image an even number of pixels wide. 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] Background Alignment
Sorry, my misreading. What I ought to have said was, make sure that both the background image and its container are both an even number of pixels wide. Paul At 12:11 AM 10/4/2005, Rick Faaberg wrote: On 10/4/05 12:00 AM "Paul Novitski" <[EMAIL PROTECTED]> sent this out: >> Everything looks fine the only difference is 1 pixel between IE and FF. Has >> anyone encounter a similar problem? >> >> Note: The background is 700px in width. > > > How wide is the background image? Perhaps it's simply a rounding > issue that can be resolved by making the image an even number of pixels wide. 700px is even... Rick Faaberg ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] List Headers?
At 11:15 PM 11/5/2005, Christian Montoya wrote: What I would like to do is have a list header, much like tables have table headers. I wrote more about this here: http://montoya.rdpdesign.com/2005/11/06/list-headers-an-idea/ But what it basically boils down to is having a tag I call "list header" so you can do: header item 1 ... Great idea, Christian, but you've been scooped: LH was part of the 1993 HTML3 specification in the UL, OL, and DL definitions, such as: http://www.w3.org/MarkUp/html3/deflists.html LH appears to have disappeared from the specs between HTML 3.0 and 3.2, but I wasn't able to discover when or why it was deprecated. Does anyone here recall? 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] Claiming compliance when a site doesn't' actually comply
At 10:24 PM 1/4/2006, Nic wrote: You go to a site, and it proudly claims xhtml/css/wai compliance. You do a quick check, and discover that the code wouldn't pass xhtml 1.0 compliance, let alone the 1.1 strict they claim! Their css is a mess. ... This upsets me on several levels. ... Nic, If you run into developers who are clearly flaunting W3C tags to attract naive clients but who have no intention of following through, what can you do? Start a blog pointing out the worst offenders? Pass them along to Vincent Flanders of http://webpagesthatsuck.com/? Will the subsequent traffic to their sites help or hinder them? You'll need to decide if they're really worth your time, when you could be out there creating elegant websites that work. My suggestion is, don't get mad, get helpful. If a website bugs you, write to its developer pointing out its flaws. Most web developers in my experience are open to criticism because we're all always trying to improve our craft. Don't be too quick to judge -- many of us are so over-extended that we don't have time to do everything on our to-do lists. (I don't know about you, but I'm so busy working on my clients' sites that my own suffers from inattention.) If there's anything about an erroneous site that you LIKE, I'd point that out as well so your comments will more likely be seen as friendly. 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] Site Check - ShetlandCoffee.com
At 12:09 PM 1/11/2006, David Nicol wrote: I'd appreciate it very much if you could take a quick look at: http://www.shetlandcoffee.com/ David, You've got an XHTML-Strict doctype, and yet you've got a great whack of whitespace above the doctype tag. If I'm not mistaken, this will cause browsers to fall back to quirksmode/transitional rendering. I suggest eliminating the whitespace and check the site in all your browsers again. As I navigate the site using your top nav menu, I would expect each menu item to have an "active" state when I'm on the corresponding page. Doing this gives the user additional clues as to which page they're currently on. The Contact page contains the client's email address in plain text for all spammers' robots to find. I suggest presenting it as an image or obfuscating it with _javascript_ to lessen their vulnerability to address mining. When contact forms are presented, I think it's much less important to provide the email address in a form that's machine-readable. 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: Re; Re: [WSG] the correct use.
At 01:26 PM 1/13/2006, denAnden.dk wrote: in the sence that in address example, the meaning a Br-tag would carrie could instead be carried by commas or seperate p tags, which would be more correct and should be used? This is one of those points we'll never all agree on but love to argue. Personally I think the use of BR to separate address lines is problematic, is functioning as a presentational element, and should Most Properly be replaced by individually tagged elements. This becomes most clear when presenting addresses from a variety of nations: name address city province postal code or: name address city province postal code or: name address county city postal code or: name address city county postal code or: name address postal code city province or: name address postal code city province or: province postal code city address name It's not merely where the lines break but also the sequence of address elements that varies from place to place, clarifying the fact that an address is an ordered sequence of semantically unique elements and isn't just some kind of postal blank verse. I suspect that most of us who still mark up addresses with BR tags do so because we feel silly adding so much bloody markup to what's ordinarily a very spare text block. Just get over it and break the damn lines ! 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] Active Links
At 07:18 AM 1/14/2006, Patrick H. Lauke wrote:
assign an id or class to each navigation bar link, and also assign
an id or class to the body element. then, in your css, define rules
that match up the two.
...
home
portfolio
contact
...
...
...
body#home a#navhome { /* styling for active page */ }
body#portfolio a#navportfolio { /* styling for active page */ }
body#contact a#navcontact { /* styling for active page */ }
Patrick,
I've used this technique a lot over the past year or so and I love it.
One minor annoyance is that it forces us to reproduce all those named
item ids in the stylesheet for each new project, and to modify the
stylesheet every time the menu is tweaked.
I've recently started using this more generic approach:
...
home
portfolio
contact
...
...
body.navitem01 li#navitem01,
body.navitem02 li#navitem02,
body.navitem03 li#navitem03,
...
{
/* styling for active page */
}
Notes:
I use body class, not id, allowing me to use this technique for more
than one structure on a given page.
I put my ids into the parent LI, not the child A, for greater styling control.
One advantage of using numbered ids is that you can import a generic
block of selectors for a new project and merely update the styling
rules, with fewer issues mis-proofreading selectors at 2:30 am.
One disadvantage of this level of abstraction is that you have to
remember that "navitem03" is the contact page, not the portfolio
page, during development.
I clean this up by using server-side scripting to generate the block
of menu styling rules (in which case it doesn't matter if they're
names or numbers) or to auto-number the menu item ids on the fly.
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] Article: MIME and Content Negotiation
At 04:02 AM 1/16/2006, Lachlan Hunt wrote: (The charset parameter is only really needed for text/* media types, for XML served with an application/* media type, the XML declaration is recommended for use instead which may be omitted for UTF-8 and UTF-16) http://lachy.id.au/log/2006/01/content-type For clarification, was your first clause above a sentence in its own right? I assume you meant, "(The charset parameter is only really needed for text/* media types. For XML served with an application/* media type, the XML declaration is recommended for use instead which may be omitted for UTF-8 and UTF-16)." Thanks very much for the article, Lachlan. 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 **
