[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] 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 ***
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] 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] 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] 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] 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] 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] 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] :: 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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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 ***
[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
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 ***
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
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] 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] 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] 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] 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] 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 ***
[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[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] ***
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: [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] 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] 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] 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] 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] ***
[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] 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] ***
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
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/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] 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] 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] ***
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
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] ***
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
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] Converting font size from pt to % or em
At 5/27/2007 07:44 PM, Andrew Cunningham wrote: The practice of setting body font size to 62.5% has some very interesting assumptions built in. Any style sheet designed using this supposition would be inappropriate for a fully internationalised site. Please elaborate on this point. Is your statement based on the assumption that body text will be sized at 1em, or that the column widths will be fixed? 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: [EMAIL PROTECTED] ***
RE: [WSG] The use of asterisks in forms to indicate required fields
At 5/27/2007 11:41 AM, Thierry Koblentz wrote: I like Mike's use of the legend element, but the problem I see with that approach is that "Required Contact Info" is read before every single label... What if it were simply the word "required"? Enter your contact information: Required: Name: ... That would vocalize "required name," "required email address," "required password," etc. That doesn't seem so egregious to me, and all of the suggestions of adding a "required" markup to each input field will surely produce at least that much baggage to the aural experience. (I've shortened Mike's suggested labels, e.g. "Enter your full name" to simply "Name." Doesn't the aural user agent make it amply clear that this is a form and that each input field is an input field? On that assumption I wouldn't consider it necessary to repeat "Enter your" each time, but I'm open to being corrected on that point.) 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] The use of asterisks in forms to indicate required fields
Thierry Koblentz wrote: Some clients do not want [required on the end of each label], they think it "pollutes the visual". I'm sure the origin of the asterisk to indicate required fields was literally that of a footnote: Name:* Email:* * Required field As Thierry indicates, the original rationale behind this structure was undoubtedly simply to avoid cluttering a form occupying limited real estate with the word 'required' beside every required field. However, it would be clumsy and irritating to mark this up so that each asterisk were literally a hyperlink that jumped to the footnote explaining that it was required. At the same time, the word 'required' (at least in English) is so short that I don't think its repetition would be irritating on an aural page (which I suppose might be just my lack of sensitivity as I'm not a screen reader user). All this makes me try to come up with a way to present the asterisks as footnote indicators visually but not aurally. One could present the asterisks as background images on the abbrev elements, but as such they wouldn't scale. If they were scalable foreground images, they'd need an alt: img.required {width: 1em;} The problem would then be how to mark this up: * Required fields As plain text it would make sense to the visual users as the referent for the asterisks but would seem a bit nonsensical to listeners. Musingly, 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] semantic HTML for intro text
At 5/26/2007 10:04 AM, Designer wrote: Presumably, and would do the trick also? My own preference would be for the latter. Of course, if you are referring to a GROUP of paragraphs constituting the introduction, then Paul's class would have to be used. Yes, either an introduction consisting of multiple paragraphs or multiple introductions on the same page. Since we don't really know the present and future architecture of the site in question, either of those possibilities seems so likely to occur, particularly the former, that painting oneself into a corner with id seems to beg for the busywork of modifying markup & stylesheet down the road. 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] semantic HTML for intro text
At 5/26/2007 05:59 AM, Paul Collins wrote: OK, thanks for your help, I just thought there may be some kind of HTML tag that adds seperate semantic value to the introductory paragraph, to differentiate it from the strong text in the body, like the tag for example. I will probably use the tag then. I think the problem with using to demarcate your introduction isn't that is presentational (it's not) but rather that it does nothing to express what's different semantically about an introduction. You may wish to present the introductory paragraph in a "stronger font" than the body of the article, but that's of course a matter of presentation and doesn't belong in the markup. The introductory text itself isn't stronger than the article body, is it? It's just the introduction. Since HTML doesn't contain an element that expresses the introductory nature of a text block, I second the motion to use class="introduction">. It correctly marks up the introductory paragraph(s) as paragraphs, identifies them for styling purposes, and indicates to anyone or anything peering under the hood at the HTML what's different about this part of the article. If any more explicit demarcation is felt necessary, I suggest using a subhead Introduction to indicate the nature of the block to follow. 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] Converting font size from pt to % or em
At 5/25/2007 03:10 PM, Christian Montoya wrote: >The point that Felix is making is that >setting the body to something small like 62.5% is very destructive, >since user stylesheets and user settings usually just override the >body rule (and ruin all your specific rules). On 5/25/07, Paul Novitski <[EMAIL PROTECTED]> wrote: "ruin"? Wouldn't it just make everything larger if they overrode the stylesheet with, say, body {font-size: 100%}? At 5/25/2007 06:16 PM, Christian Montoya wrote: It can ruin text if it means that things suddenly get much bigger than the user or designer ever expected and (sometimes) breaks out of containers. If I enforce 18px as a default because I have a high resolution display and no elegant way of scaling fonts, I would expect all text to be just a step larger than the default 16px that most users at 96 dpi would get. But then you are talking about a page where the default was intended to start at 10px getting enlarged by a factor of 1.4, for example, on a container, and with my default of 18px suddenly I'm getting 25 or 26 px, much much bigger than what I wanted and bigger than what the designer expected. That's ruined in my book. IMO it's not hard to just leave the default body size alone and size from there, which is why I do that in my own stylesheets. OK, I'm being persuaded. I have a high resolution display and no elegant way of scaling fonts Do you mean no elegant way to scale them in a user stylesheet or no elegant way to scale them in real time, e.g. with a mouse wheel? In either case I'm curious for an elaboration on this. (I assume you're talking about a hypothetical user here and not yourself...) 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] Converting font size from pt to % or em
At 5/25/2007 03:10 PM, Christian Montoya wrote: I hate to make a quick reply to a long post, but not all designers set body font size to 62.5% when creating websites. It's enough to start at 100% and set nested containers to fractions of that... just do the math starting off from 16px. The point that Felix is making is that setting the body to something small like 62.5% is very destructive, since user stylesheets and user settings usually just override the body rule (and ruin all your specific rules). "ruin"? Wouldn't it just make everything larger if they overrode the stylesheet with, say, body {font-size: 100%}? I guess it will depend on which aspects of the layout are widthed in ems, but for most pages I'd think it would just start you out at a larger degree of [text and/or layout] magnification. (The past tense of the verb "to width" I just coined is so difficult to pronounce I just had to use it.) Regardth, 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] Converting font size from pt to % or em
On 2007/05/25 00:58 (GMT-0700) Paul Novitski apparently typed: > In my efforts to build zoomable layouts [max-width at window width] > I've found it convenient to declare a body font-size of 62.5% At 5/25/2007 10:16 AM, Felix Miata wrote: The Clagnutt 62.5% scourge or bane of user stylesheets. :-( Felix, thanks for your lucid reply, but you apparently didn't actually read my posting even as you quoted it. I'm talking about creating zoomable pages and you lecture me about the disadvantages of fixed width! Sheesh. The reason I'm needing to convert from pixels to ems is that I'm implementing designs mocked up as bitmapped images in Photoshop & InDesign. The designer creates the mockup to depict the page as they want to see it, which I interpret as the way the page should look at normal zoom. I translate all their pixel measurements to ems so that the page is zoomable. The arithmetic on this gets tedious, so I use 62.5% to make 1em = 10px to make my life easier. I could as easily have set the body font-size to 6.25% so that 1 page em = 1 mockup pixel but I thought I might break something. The pages I craft this way are not absolutely zoomable -- I halt the layout zoom at window width to avoid the pitfalls of horizontal scrollbar and hidden content which I consider to be accessibility concerns. But I want the pages to be zoomable within that constraint to enable people to enlarge their text to the greatest extent possible without breaking the layout (i.e. enlarging single words beyond the width of their containers). 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] Converting font size from pt to % or em
At 5/25/2007 12:15 AM, Felix Miata wrote: On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: > Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, even though you don't have a clue what it was to start with. Isn't that true only if you then use 1em as your base font size? In my efforts to build zoomable layouts [max-width at window width] I've found it convenient to declare a body font-size of 62.5% so that, on a PC with a default font size of 16px, 1em = 10px at normal zoom. It makes calculations very easy. For example, if you begin with a content column of 790px, that converts to 79em and becomes zoomable. An image that's 100px wide becomes 10em wide. In that context, one can make one's base font size 1.6em (16px at normal zoom on a PC). This presents body text at the same size it would have been had font-size not been styled, yet at the same time makes scaling calculations much easier for the designer. It seems like a win-win situation. Can you see a flaw? Even on Mac monitors running at 96dpi, reducing the text to 62.5% and then increasing to 1.6 should bring it back to 100% of the default size, whatever that may be. 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] Map of Australia Image Map
At 5/24/2007 09:49 PM, Geoff Pack wrote: If the image is a map, and you want to link areas of it, then an image map is the semantically correct solution. Faking them with lists and CSS is no better than using tables for layout IMHO. Wouldn't that depend on whether you thought of the map as the semantic content itself or merely the graphic presentation of a list? To my surprise, the presentational result might not depend on which markup is chosen. Undoubtedly the reason Pete chose CSS for the <http://www.domain.com.au/> job was to make the states highlight on hover. I was about to say that image map areas wouldn't work for this because IE6 won't support area:hover, but rereading the HTML spec I'm reminded that a map can consist of a series of anchors as well. [1] It's entirely possible to style the Anchors (or AREAs) as blocks and absolutely position them on the image to make them do double duty as both image map polygons and sprite hover rectangles. Of course we're still left facing the sad fact that today's CSS can manipulate only rectangles and not circles or polygons, so it remains our noble quest to persuade our respective governments to redraw all political boundaries rectilinearly. [1] HTML 4.01 Specification 13 Objects, Images, and Applets 13.6 Image maps http://www.w3.org/TR/html4/struct/objects.html#h-13.6 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] Map of Australia Image Map
At 5/24/2007 09:14 PM, Sander Aarts wrote: Paul Novitski schreef: Of course the problem was made easier by the fact that most of the borders between Australian states are on the horizontal or vertical, ... Just what I thought. I whished that I lived in a country with borders like that ;-) Often clicked myself instant RSI creating clickable area's on a map of the Netherlands (to get an impression of the borders: http://www.jachthavens-nederland.nl/JN_images%5CnederlandGroot.gif). Don't think the CSS-only technique would be of much help here. Too bad. Yow! Talk about squiggly! Perhaps you could suggest to parliament that they straighten out those danged borders to make life easier for us web designers. 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] Map of Australia Image Map
At 5/24/2007 07:10 PM, Peter Ottery wrote: re -> Has anybody seen or created way of displaying States on hover using CSS only? have a look at the front of http://www.domain.com.au/ Very nicely done. Of course the problem was made easier by the fact that most of the borders between Australian states are on the horizontal or vertical, but you handled the major exception between NSW and VIC excellently by expressing ACT as a strategically-placed and -sized rectangle. Good work! I don't know that this would have been quite as effective at a larger scale where the discrepancies between wobbly borders and straight block sides would have been more obvious -- perhaps requiring some additional tiny blocks to mimic angles -- but at this scale the illusion works spendidly. 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] Tiling image problem
At 5/20/2007 10:18 PM, Cole Kuryakin wrote: I'm setting a 1px by 770px image to repeat vertically within a wrapper div. By the way, asking the browser to replicate a 1px-thick image will occupy a lot more CPU cycles than if you dimension your image to be fatter and replicate, for example, one that's 50px or 100px thick. In my experience the difference can be large enough to be perceptible by a human being, i.e. a significant fraction of a second or more for a large screen. Generating a fatter background image can therefore be seen as "pre-processing" with significant savings in real 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: [EMAIL PROTECTED] ***
Re: [WSG] Tiling image problem
At 5/20/2007 10:18 PM, Cole Kuryakin wrote: I'm setting a 1px by 770px image to repeat vertically within a wrapper div. Difference is that I need this repeat to START 300px from the top of the wrapper. I don't know a way to start a vertical tile 300px down the block. However, here are two workarounds: - Allow the tiling to begin at the top of the block, but begin the block 300px down the page. - Allow the tiling to begin at the top of the page, then overlay the top 300px with the alternate pattern. 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] css type loop
Lucien Stals wrote: Why aren't you just dealing with this server side and generating the desired classes and tags there? At 5/18/2007 02:25 AM, Mordechai Peller wrote: I see two reasons. First, by generating the CSS dynamically, browsers are unable to cache it, thereby loosing one of the benefits of external style sheets. Second, by adding all those extra classes (or ids), the HTML becomes bloated and looses semantic value. Mordechai, please elaborate on this point: how does HTML lose semantic value when ids & classes are added? I think of ids & classes as being semantically neutral or inert. I can see losing semantic value when meaningful elements such as Hn and CITE are replaced with DIV and P and SPAN, but how can the semantic value of a page change either negatively or positively by adding or subtracting ids & classes? 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: [EMAIL PROTECTED] ***
Re: [WSG] css type loop
At 5/17/2007 09:19 AM, Paul Novitski wrote: Yes, but what would make sense would be to combine all the numbers into a single image and then apply them to the list items with staggered positions, rather than applying a separate image to each list item. Here's a real-world example: http://marthagrenon.com/TheBringingOfTheBones/journey_tirana-1.html To anticipate Patrick's and others' retorts, my example of menu image replacement is (*sigh*) unresizable, not by technical necessity but by The Tyranny Of The 50-Foot Graphic Designer with whom I compromised on this site. The same sort of method can certainly be applied to a resizable menu. Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] css type loop
At 5/17/2007 02:25 AM, Paul Collins wrote: I recently had to add numerical bullet point graphics to an OL. This meant I had to add an individual class and style to each bullet point for each image, which can add up when you've got 20 bullets. I was wondering, does anyone know more clever way of doing this in some kind of a CSS loop, without using Jscript?! Example: CSS li.bullet1 {background:url(images/bullet1.gif} no-repeat;} li.bullet2 {background:url(images/bullet2.gif} no-repeat;} HTML lorem ipsum lorem ipsum Quoting Breton Slivka <[EMAIL PROTECTED]>: This might seem obvious, but have you considered combining them into a single image, and adding them as a single background to the OL instead? At 5/17/2007 02:58 AM, Patrick H. Lauke wrote: That would break apart as soon as the user changed text size, or the amount of content in each LI is variable. Yes, but what would make sense would be to combine all the numbers into a single image and then apply them to the list items with staggered positions, rather than applying a separate image to each list item. Here's a real-world example: http://marthagrenon.com/TheBringingOfTheBones/journey_tirana-1.html The page menu at the right is one large image combining all buttons in three states: http://marthagrenon.com/TheBringingOfTheBones/images/page_buttons.jpg Each menu item/state takes up a 42px square of the overall menu image. Here's an excerpt from the CSS: div#pageMenu li a { background: url("images/page_buttons.jpg") left top no-repeat; } /* normal state */ div#pageMenu li.page1 a { background-position: 0px -42px; } div#pageMenu li.page2 a { background-position: 0px -76px; } div#pageMenu li.page3 a { background-position: 0px -110px; } /* hover state */ div#pageMenu li.next a:hover{ background-position: -43px 0px; } div#pageMenu li.page1 a:hover { background-position: -43px -42px; } div#pageMenu li.page2 a:hover { background-position: -43px -76px; } div#pageMenu li.page3 a:hover { background-position: -43px -110px; } This is a variation on "CSS sprites" (q.v.). Its efficiency is based on the principle that every image file has its own header as overhead, therefore combining many similar images into one file makes for less weight to download than all the images separately. All the images appear at once, and in a case such as the Bringing of the Bones site the hover & active states are combined in the same image so there's no download delay when mousing over the menu and no need to pre-load images with javascript etc. This is a somewhat different application than what you're doing because in this case the images ARE the menu items, but the principle can still apply to image markers for text list items if done properly. 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] Semantics and
At 5/16/2007 04:04 AM, Blake Haswell wrote: We have two elements, EM and STRONG, to emphasise text as being more important than the text around it, but we don't seem to have any elements to show that text is less important than the surrounding text. What is the best way to show something is less important than the surrounding information (e.g. the date of a post or article, supplementary information at the bottom of a post or article)? Side-stepping your markup problem for a moment, I'd like to question your premise. In the HTML 4 spec[1], EM and STRONG are characterized as "emphasis" and "stronger emphasis" respectively. There's no mention of importance per se. At the risk of splitting hairs -- well, hey, let's split hairs; that's the nature of this work -- I don't read the spec as assigning relative "importance" values to content at all. In the expression No, it traveled sideways in time! the adverb is not any more important than the other words in the sentence, it's merely emphasized as a way of differentiating one among several possibilities. Specific to your situation, I question whether an article's date or its supplementary text is really best characterized as being "less important" than the article itself. That doesn't strike me as a useful semantic distinction. In the absence of markup elements and , you may be left without a semantically direct way of specifying your auxiliary content in today's HTML. Personally I don't think fits the bill. [1] HTML 4.01 Specification 9 Text 9.2.1 Phrase elements: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 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] markup for headline and tagline
At 5/6/2007 11:16 AM, ~davidLaakso wrote: My goal is still to learn what markup solutions others have settled on for headline/tagline and title/byline pairs. If you are interested in what others have settled on try the NYT <http://www.nytimes.com/2007/05/06/education/06montana.html?_r=1&oref=slogin> Urk -- The NY Times website is using H1 twice on this page, once for the name of the website section ('Education') and again for the name of the article ('Walking on the Wild Side of a Montana University'). Not to mention proprietary tags: Walking on the Wild Side of a Montana University That's why I'm asking WSG developers -- to get leading-edge, web-standards-compliant thinking. Relevant to my question, NYT is using this: By http://..."; title="More Articles by Jim Robbins">JIM ROBBINS 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] markup for headline and tagline
At 5/6/2007 09:41 AM, Patrick H. Lauke wrote: Paul Novitski wrote: Ah. It appears that you're reading it as: Contains [a citation or a reference] to other sources. and I read it as: Contains [a citation] or [a reference to other sources]. I have to say that the two examples given in the spec seem to support the latter interpretation: To me, they support the former As Harry S. Truman said, The buck stops here. Truman didn't say it here, for this document...he said it somewhere else. More information can be found in [ISO-]. The information is somewhere else...namely, in the ISO spec. So, by my interpretation, if you cited "a blog by blah", it would imply that the blog is actually somewhere else, and you're citing from it. Yes, I see your reasoning, thanks. By the way, even if one were to allow the use of CITE for a byline, I can see from the W3C example that the markup should not be: by Bob but rather: by Bob which doesn't help me decide what that should be. (Anyway, CITE's inline and I think I'm looking for something normally block.) My goal is still to learn what markup solutions others have settled on for headline/tagline and title/byline pairs. 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] markup for headline and tagline
At 5/6/2007 02:49 AM, Patrick H. Lauke wrote: Paul Novitski wrote: CITE: Contains a citation or a reference to other sources. As I read this definition and these examples, I find it defensible to use CITE to mark up a byline which is, after all, a citation of the author of the piece at hand. Note the "to other sources" part of the definition, though, compared to "of the piece at hand". Ah. It appears that you're reading it as: Contains [a citation or a reference] to other sources. and I read it as: Contains [a citation] or [a reference to other sources]. I have to say that the two examples given in the spec seem to support the latter interpretation: _ As Harry S. Truman said, The buck stops here. More information can be found in [ISO-]. _ http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 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] markup for headline and tagline
At 5/6/2007 12:43 AM, John Faulds wrote: What markup do you favor for a headline-tagline pair? (The second element could be a tagline or a byline.) Thundering Pigs a blog by Bob No, cite is for citations. A question on : is this an appropriate usage? The SitePoint book Build Your Own Web Site The Right Way, by Ian Lloyd, is a great primer for learning HTML and CSS. __ HTML 4.01 Specification 9 Text 9.2.1 Phrase elements: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 CITE: Contains a citation or a reference to other sources. As Harry S. Truman said, The buck stops here. More information can be found in [ISO-]. __ As I read this definition and these examples, I find it defensible to use CITE to mark up a byline which is, after all, a citation of the author of the piece at hand. A "citation" does indeed include the author: see http://google.com/search?q=define%3Acitation I suggested CITE in order to seed the discussion. I'm mostly interested in people's recommendations of other byline and tagline markup I might not already be considering. 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] markup for headline and tagline
At 5/5/2007 09:16 PM, Thierry Koblentz wrote: I've usually gone: Thundering Pigs a blog by Bob I do something very similar, but using a colon: Thundering Pigs: a blog by Bob Interesting. I see the title and the tagline as being semantic siblings, but I guess in some circumstances the tagline could be seen as a child of the title -- for example in the case of title & subtitle. If the second unit is a byline I feel an even stronger urge to individuate them: Thundering Pigs by Bob Any other suggestions? 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] markup for headline and tagline
What markup do you favor for a headline-tagline pair? (The second element could be a tagline or a byline.) Thundering Pigs a blog by Bob Thundering Pigs a blog by Bob Thundering Pigs a blog by Bob Thundering Pigs a blog by Bob or some other configuration? Thanks, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Template Review[Final]
At 4/30/2007 02:02 PM, Open Vision wrote: Spelling and punctuation is faulty too: Using javascript and AJAX behaviour is added to enhance user experience for a web applications, in compliance with web standards Better written as; Javascript and AJAX behavior (oh, we don't use the u here) is added to enhance user experience for Web aplications, in compliance with Web standards. I believe it's JavaScript: http://www.google.ca/search?q=define%3Ajavascript I didn't realize anyone capitalized "web" any more. Is that like "E-mail"? Devilishly, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] multiple-column definition list [WAS: Template Review]
On Apr 30, 2007, at 2:28 AM, Paul Novitski wrote: The method you're using to present the definition list in two columns is to split the markup into two lists. However, I believe it's really just one list, so you're changing the markup in a way that misrepresents the semantics of the page purely for presentational purposes. You can accomplish the dual-column list in CSS by moving the first DT in column 2 back up the page with a negative margin-top, then shifting all the items in column 2 over with a postive margin- left. This technique is illustrated in example 6 in my A List Apart article <http://www.alistapart.com/articles/multicolumnlists/ >. It does require that the height of column 1 is predictable if you're using static CSS or calculable if you're generating your CSS on the fly. At 4/30/2007 10:06 AM, CK wrote: Wonderful suggestion and article, should the have mark-up similar, then follow along with the CSS, from the article? Thanks! My examples in the article are all ordered & unordered lists, but technique #6 can certainly be applied to definition lists. ___ If you're generating your list markup from a script such as PHP you can probably add ids & classes precisely where you need them: identify the first item of column 2 uniquely, then identify each item in column 2 with a class: column 1, item 1 column 1, item 1 column 1, item 2 column 1, item 2 column 2, item 1 column 2, item 1 column 2, item 2 column 2, item 2 dt#col2 { margin-top: -6em; } dt.col2, dd.col2 { margin-left: 20em; } ___ If you're dealing with static html, you could give every list item a unique id and then generate the stylesheet to split it into columns: item 1 item 1 item 2 item 2 item 3 item 3 item 4 item 4 #c-t { margin-top: -6em; } #c-t, #c-d, #d-t, #d-d { margin-left: 20em; } ___ A script can obviously calculate where a new column begins by dividing the number of items by the number of columns, compensating for multiple-line items as needed, and bingo, Bob's your uncle. Since line-wrap is a client-side phenomenon in layouts that limit width, a server-side script can make a best-guess and a client-side script can refine the column breaks as the user resizes their text. I'd hate to have to produce extensive markup like this by hand, but then I generate pages by scripting almost exclusively and leave such mind-numbing markup details to the server that seems so content to wade through large boring jobs in mere milliseconds. When CSS3 is finally supported commonly we can dispense with all this and generate columnar markup more easily. W3C CSS3 module: Multi-column layout http://www.w3.org/TR/css3-multicol/ Introducing the CSS3 Multi-Column Module by Cédric Savarese http://www.alistapart.com/articles/css3multicolumn/ 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] Template Review
On Apr 30, 2007, at 10:04 AM, CK wrote: http://working.bushidodeep.com/dom_site/template.php On Apr 29, 2007, at 10:23 PM, Philippe Wittenbergh wrote: as Paul mentioned: why the pointer over the dt/headings ? At 4/29/2007 09:12 PM, CK wrote: For Show/Hide Dom Switching I strongly suggest you 1) mark up the DTs as hyperlinks that reload the page with the selected item expanded, then 2) add javascript that converts the links to show/hide DOM switches That way the page will function correctly whether javascript is enabled or not, and when javascript is enabled it will work faster & more smoothly. Everybody wins. [Google 'progressive enhancement'] See this <http://working.bushidodeep.com/dom_site/template_02.php> The method you're using to present the definition list in two columns is to split the markup into two lists. However, I believe it's really just one list, so you're changing the markup in a way that misrepresents the semantics of the page purely for presentational purposes. You can accomplish the dual-column list in CSS by moving the first DT in column 2 back up the page with a negative margin-top, then shifting all the items in column 2 over with a postive margin-left. This technique is illustrated in example 6 in my A List Apart article <http://www.alistapart.com/articles/multicolumnlists/>. It does require that the height of column 1 is predictable if you're using static CSS or calculable if you're generating your CSS on the fly. 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] Template Review
At 4/29/2007 06:04 PM, CK wrote: <http://working.bushidodeep.com/dom_site/template.php>http://working.bushidodeep.com/dom_site/template.php ... Typography is the emphasis of this creation, so a review for readability is desired. Please send along screen captures of any strange behavior. Concerned with the absolute placement of the navigation and the generated content. The 'READ MORE' links do not function as hyperlinks using Win Firefox 2 (and of course they don't show up in Internet Explorer 7). Oh, I see, they're not actually links; I assumed they were because the mouse changed to a pointer, but I see that you forced that in your stylesheet. Why? When I enlarge the text (which I need to do in order to read the 'READ MORE' links), it spills out of the white column background. With a layout this simple, why not make the white column resize with the text? Also with enlargement, when the text wraps at window width it overlaps the beginning of the body text. Why do you take the nav menu out of the flow? This seems to create problems unnecessarily. In Win Firefox 2 the validation select list seems too short, cutting off part of the final 'n' of Validation. I can't see where in your stylesheet you're constraining its width, but maybe some padding-right would help. My eye sees a busy page. I would increase the leading before each DT to let the page breathe. It's really just a big list, which I don't find interesting; even while reviewing this template I couldn't make myself actually read it. I would consider using a more engaging method of communicating with the reader. I like your color palette! 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] List with image and paragraph - help
At 4/18/2007 07:14 AM, Jim Callender wrote: I want to create an inline styled list, with two elements inside this list which are block level > 1st level: An image which will be coded, and 2nd Level: a line of text underneath the image. ie: A list with two elements, one sitting under the other in the same list item. Is it best to create a unordered list and have another list within this? Using nested lists for this seems like overly heavy markup to me. Many people use the definition list for image/caption pairs (although there's disagreement over whether an image and its caption qualify as a term and its description; personally I don't have a problem with the metaphor). Google CSS DEFINITION LIST GALLERY for many examples and discussions. An example using a definition list: http://juniperwebcraft.com/what_websites.php (This example has several differentiated text blocks per image, but the principal still applies to a simpler image-and-caption model.) An example of using an unordered list with an image and paragraph in each list item: http://tm-athletics.com/jackets_materialsLeather.php (scroll down to swatches) 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] nav menu help
At 4/9/2007 03:12 PM, kevin mcmonagle wrote: Just wondering what the best way set width and height on a horizontal list menu like this http://www.nwtc.ie/home.html so that a user-sizing the fonts wont break the layout but can still change font size. The simplistic answer is to set the width of blocks that contain text in ems so that they expand and contract with font-size. If your list items are sized in ems but the content column that contains the menu is fixed in pixels, you're going to fill up the space and... then what do you want to have happen? There are many scenarios, and you have to choose one according to your own design sensibilities. It helps to view a web page not as a still photograph but as a movie. Graphic designers are fond of coming up with a single mockup of a page and thinking their job finished, leaving the rest of the job to us -- to figure out how the page will morph on resize. The complete design exercise is to storyboard the whole movie. A few of your choices are: - Allow all text blocks on the page to zoom with text size without restriction -- creating a horizontal scroll bar when content width exceeds window width. - Allow the page to zoom but stop it at the window width (easy in browsers that recognize max-width). - Use fixed widths and allow text blocks to grow vertically. This strategy fails when a single unwrappable word exceeds the width of its container. - Float list items so that the row of items wraps around when too large for their container. Many people are disconcerted when nav menus wrap, at least in part because they're not used to seeing it. Notice that in all of this I'm not even mentioning height. I almost always let the browser work out the height as the text expands. 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] em-based layout test request
At 4/8/2007 09:18 PM, Joseph R. B. Taylor wrote: I've been working on an em-based layout and wanted to see what your user experiences were like on this test page. ... http://sitesbyjoe.foodzoomer.com/homepage.htm It seems to break apart a little in IE 7 but as you know works fine in Firefox 2. Although I'm fond of absolute zoom like this, I get a lot of push-back from collaborators and clients because it triggers a horizontal scrollbar at high zoom. (I don't see anyone complaining about Word, PDF, Excel, and other document formats doing this, but maybe I get the push because I'm more accessible than Bill...) My compromise is to make layouts that expand up to but not exceeding window width, such as this http://i-edu.org/ and our own site http://juniperwebcraft.com/ I don't generally make images expand because they tend to shrink and expand badly, but your large image in this demo does OK. Did you save it in any special way for this purpose? 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] Client Side Development Process
At 4/7/2007 07:28 AM, Lee Powell wrote: I wonder if anyone can offer some advice. I've recently landed a new development position within a very credible digital agency as part of their client side development team. One of our things to do is develop a rock solid development process we work through for every project. Traditionally we don't get our hand dirty until a client signs off what the design team have produced, however we are going to try to change this and get involved from an earlier point in the project. Would anyone like to offer any advice on setting up this process, and any advice on things to take into consideration for inclusion of the process. It'd be great to compile some documentation, and share it with the rest of the community... We're starting from a blank canvas so any advice appreciated. Definitely add this book to your repertoire: Web Redesign 2.0 | Workflow that Works by Kelly Goto and Emily Cotler http://web-redesign.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] How to mark up a flowchart?
At 3/26/2007 09:19 AM, Kenny Graham wrote: I don't understand what you mean when you say this involves recursion. (a)<-+ | | (b) | | | (c)--+ | (d) If C takes the route back to A, the whole thing starts back over, so you'd end up with infinitely nested lists. The only way I can think of getting around that would be if there were an idref attribute to embed list items, so you could have at the top, and then for C you'd have . That'd be fun. Well, I'm not so sure this is an example of recursion, rather just a simple loop. We can certainly use anchors to link from one item to another, but you'd have to decide on a convention for linking to two different destinations. Perhaps something like this (caps used for visual clarity): A PROCEED TO B B PROCEED TO C C PROCEED TO D LOOP BACK TO A D 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] Brand logos with links to home
At 3/17/2007 07:27 AM, Lee Powell wrote: I was wondering what the general consensus was on whether the main logo on a site should always be a link back to the home page. Is this a general 'rule of thumb' or do many tend not to do this? We routinely link the logo to the home page, and we also include an explicit home page link in the navigation menu. The redundancy of having two home page links seems like a pedantic concern and much less onerous than either of the alternatives: having a linkless logo or omitting home from the nav menu, both of which can produce both client and user complaints. 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] Talking about tabular data...
At 3/9/2007 06:05 AM, Nick Fitzsimons wrote: On 8 Mar 2007, at 19:09:52, Paul Novitski wrote: The HTML spec makes it explicitly clear that the relationship between term and description can be interpreted more broadly than merely terms and their definitions: "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." [1] In a dialog, the speech does not define the speaker; rather, they mutually inform one another to constitute a data record of closely associated fields. I suggest that the DT/DD relationship is similar to the TH/TD relationship of "head" and "datum." In my view, the spec is far from clear at that point: it states that it is a definition list, explains how it is to be used to mark up terms and their definitions, and then suddenly turns around and gives us carte blanche to do pretty much anything we like with it. Note that this is mentioned as being "for example", so should IMHO be considered informative, not normative. In terms of the semantics of "term" and "definition", it makes no sense at all. That's right -- in order to make sense of the spec it's necessary to expand your thinking beyond "term definitions" literally to include other metaphorically similar data relationships. Also note that this "example" Your use of quotation marks implies that you don't consider the example provided in the HTML spec to be a real example. How so? It looks like an example, it smells like an example, and they use the expression "for example" when they give the example. How is it not an example? Or do your quotes mean that you are so resistant to the ramifications of accepting the example that you are denying that it really is an example? Would you have us believe that it is some other type of information masquerading as an example? I don't take the spec so literally that I assume the authors intended DLs appropriate for dictionaries and dialog only. I take the dialog example as explicit permission to regard the DL structure metaphorically and not restrict the usage to term definitions only. They use the term "description" as well as "definition," another hint that we might think -- if not outside the box -- at least inside of a larger box than "term" and "definition" by themselves would indicate. is not present in the current XHTML 2.0 Working Draft, which might reasonably be assumed to seek to clarify those areas of previous standards which have been found to be less than perfect expressions of the intent of the authors. It's interesting to speculate that the original authors somehow wrote the dialog example accidentally in contradiction to their own intent. Considering how much attention those documents receive from so many people, I find it much more likely that the example given fully expressed their consensus, and that the group of people working on the XHTML 2.0 spec have, presumably, come to different conclusions or at least have taken a more conservative approach to their own spec. As Jukka K. Korpela commented about this matter on the W3C's www-html list a couple of years ago, they name it a duck, and then say it can be used as a cow: "Another application of a duck is for milking..." [1] I'm an admirer of Jukka's colorful writing but I don't find the two usages (dictionary and dialog) as different as duck and cow. Rather than thinking that the spec "suddenly turns around and gives us carte blanche to do pretty much anything we like with it," I find the dialog example still remains within fairly clear bounds: a relationship of duality in which the term specifies the thing and the description provides some information about it. This pattern of duality is not mimicked by any other HTML structure I can think of off-hand except TH/TD table cell types, and I find it useful when marking up certain kinds of information. May I ask, do you use DL for anything other than dictionaries and glossaries in which terms are being defined? How broad is your application of the structure? What HTML markup would you choose for a dialog? What about a thumbnail gallery? Can you accept that an image could be a term and its caption the description or vice versa? Or a catalog with the title, author, ISBN, cover image, blurb, etc. as, variously, terms and descriptions? What else? If we are willing to apply DL not just to dictionaries but also to other structures that metaphorically resemble dictionaries, the question remains where we draw the boundaries around that usage. With such a sparse semantic landscape as HTML provides, I resist the effort to confine DLs to dictionaries alone. I want to take advantage of its st
Re: [WSG] Alpha transparency problem
At 3/8/2007 10:48 AM, Keryx Web wrote: Is it possible to get MSIE 6 to have a repeated alpha-transparent png background? Check this page http://ne.keryx.se/~gorgnut/new_site/ It is made by a student of mine and the faded border is supposed to stretch and the hacks for MSIE I know can't be used if the image gets repeated. Lars, I believe it isn't possible to repeat a PNG using Microsoft's alpha transparency filter by itself. ('scale' would work if the imagery could survive stretching without distortion.) On the other hand, it would be possible to tile the image using javascript, targetting IE <= 6 only. Doing so would not be difficult programmatically; you'd just need to prepare a fall-back contingency so the page looked decent when javascript weren't enabled. 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] Talking about tabular data...
At 3/8/2007 09:40 AM, Nick Fitzsimons wrote: On the other hand, I personally believe that the use of a dl in this example would make no *semantic* sense. After all, given the term "President", the definition of that term would be something like "The individual in charge of the organisation". "John Smith" simply cannot be seen as a *definition* of the term "President", but is rather the personal name of that entity which is *denoted* by the term "President". If it was called a "denotation list", then fair enough; but it's a definition list, for grouping terms with their definitions (whatever vague examples may be given in the standard). In the example you aren't defining any terms: you are specifying that a key is bound to a value, and *that* is what a table may usefully be used for. The HTML spec makes it explicitly clear that the relationship between term and description can be interpreted more broadly than merely terms and their definitions: "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." [1] In a dialog, the speech does not define the speaker; rather, they mutually inform one another to constitute a data record of closely associated fields. I suggest that the DT/DD relationship is similar to the TH/TD relationship of "head" and "datum." Regards, Paul [1] http://www.w3.org/TR/html4/struct/lists.html#h-10.3 HTML 4.01 Specification 10.3 Definition lists: the DL, DT, and DD elements *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Talking about tabular data...
At 3/7/2007 11:13 PM, Thierry Koblentz wrote: What's your definition of tabular data? Actually, what if there was only one row for our example? Would you consider marking up the following with a table? President..John Smith What for you makes a list of "name/value" pairs tabular data? Pairs, triplets... the number of columns doesn't matter. For me a table is a dataset naturally structured in rows and columns -- in which everything in each column belongs to one class of data and everything in each row is one associated group. In your example, the two columns appear to be Position and Name. It's the fact that everything in the first column belongs to the class of Positions and everything in the second column belongs to the class of Names that's my clue that this is a regular dataset, and therefore a likely candidate for table markup in HTML. The fact that it can also be marked up as a definition list is great -- that gives me two tools to choose from. "what if there was only one row for our example?" OK, I'll bite. Would I bother marking up a single row as a table? For that matter, would I bother marking up a single row as a definition list? Or any kind of list? I guess it would depend on the circumstances. From where does the data originate? What's its purpose and function? Does this single row belong to a family of similar datasets elsewhere on the site that have more than one row? For easy, consistent styling I'd likely choose a single markup for all those datasets that have a similar look and feel and function. One of the most important criteria for choosing table or list markup is going to be flexibility of styling. Tables can be restyled a bit but they have more restrictive limits than lists which are wonderfully malleable. I might choose DL simply to give myself and future designers more latitude in styling. Today's leader dots might yield to tomorrow's vertical stack of bold position over normal name. To continue probing the edges of the problem, what if you strip the positions from your dataset and leave just the names? Is that single column tabular data? I say yes because everything in that one column belongs to a single data class. Would I mark up such a dataset as a table? Not usually, but I might if it belonged to a family of datasets that were marked up as tables. If it stood by itself I could choose among table, UL, and OL, and would likely choose list markup to provide the greatest freedom of styling. Thierry, I understand that you're looking for simple criteria for deciding when to use table markup and when not to. Personally I don't think hingeing it on the number of columns is the way to go. I think the reality of HTML is that, when a dataset is sufficiently simple in structure and number of columns, there's more than one way to mark it up that can be equally effective structurally. A single-column table can be an unordered list. A two-column table in which the first column contains sequential numbers can be an ordered list. A multiple-column table in which the first column(s) contains row heads can be a definition list. In the absence of any strong semantic cues, I'll choose a structure for its stylability. That might sound like semantic heresy, but I think it's inevitable when even so sparse a language as HTML gives us choices. 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] Talking about tabular data...
At 3/6/2007 05:51 PM, Thierry Koblentz wrote: President..John Smith Vice-president.Janet Jones In other words, the items in the two columns line up horizontally, and the cell on the left is filled out with dots. I'm curious to know what members of this group think about this. Should this be considered tabular data or not? Do you consider a table the best tool to mark this up? Or at least as good as anything else? The example you present here is clearly two-column tabular data (whether marked up as a table or not). We live in that golden universe where markup and presentation are very (never completely) separate. The question of whether your table of officers is tabular data (duh) is independent of how it's presented. Is anyone actually suggesting that the presence or absence of the dots influences the determination of the semantic structure of the information? Yikes, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] PopUp windows
At 3/7/2007 01:23 PM, John Faulds wrote: Can I ask what people view as the best option for presenting additional information on a form you're filling out? Ideally it would be visible on the page itself, but sometimes that's not possible and making the user click a link to another page and then back again can be an inconvenience if some of the info they've entered is removed (passwords etc.) Perhaps the most common rationale for pop-ups is to add new temporary content to an already-full page. To solve the problem without using pop-ups, one can link to blocks of content at the bottom of the current page, with reciprocal links to bring the user back to their starting sections (or they can simply click Back). This can be a good fundamental model for a non-visual interface, with visual enhancements added progressively. When javascript is running, morph the link to display the temporary content either in a sidebar or in an absolutely-positioned block that acts like a pop-up but is really just part of the current page, such as the larger image display in browsercam. 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] PopUp windows
At 3/7/2007 02:05 AM, Bob Schwartz wrote: Problem: client wants (insists on having) popup windows. Question: can they be made "OK" according to all canons of WSG? (ie served in a different/alternative manner for people, devices, etc. - leave aside the js argument, as that I have solved). You'll want to warn users, e.g. with a title/tooltip that says something like "(Opens in a new window)." I've been told by a small number of screen-reader users that this solves for them the disconcerting problem of windows popping open with back buttons disabled. Aside from the usability issues, for me the most persuasive argument against pop-up windows is that they're bloody irritating. I open links in new windows when I want to and I don't when I don't want to, and I resent efforts to subvert my decisions because some innane marketing managers think that if their sites remain open on my desktop a few moments longer I'm more likely to buy their friggin product. In fact it has the opposite effect. If they force me to make an extra effort to close their windows I'm less likely to ever open them again. You don't sell more stuff by shoving your foot in the door, you just motivate the customer to push back harder. 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] ***