[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, blockquote/blockquote 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 !ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- long quotation -- 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 blockquote tag have a class assigned to it? Let's find out. From the above reference: !ATTLIST BLOCKQUOTE %attrs; -- %coreattrs, %i18n, %events -- cite%URI; #IMPLIED -- URI for source document or msg -- This specifies which attributes blockquote may have. The symbol %attrs is defined as: !ENTITY % attrs %coreattrs; %i18n; %events; ...%coreattrs in turn is defined as: !ENTITY % coreattrs id ID #IMPLIED -- document-wide unique id -- class CDATA #IMPLIED -- space-separated list of classes -- style %StyleSheet; #IMPLIED -- associated style info -- title %Text; #IMPLIED -- advisory title -- 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:
form ...
div
input type=text id=search name=search /
label for=search
input type=submit value=Search /
/label
/div
/form
_
b) Label hidden from view:
form ...
div
label for=search id=search-labelSearch:/label
input type=text id=search name=search /
input type=submit value=Search /
/div
/form
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.shtmlhttp://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:
div class=contact
pJoe's Fruit Shop/p
p55 Main Road/p
pAnytown 2999/p
/div
div class=contact
pPhone: 9555-9876/p
pFor phone orders: 1800-Joe-Fruit/p
/div
with the styling rule:
div.contact
{
margin-bottom: 1em;
}
div.contact p
{
margin-bottom: 0;
}
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] Accessibility does not matter!
At 1/29/2010 06:09 AM, Jason Grant wrote: I feel there has been LOADS of 'accessibility is a must' type discussion on this list, but at the same time I feel that there is loads of arguments which are essentially 'accessibility for the sake of accessibility'. My point is that we are heading towards the times where 'relevant accessibility' is more important than 'accessibility' per se. Please have a read of my article and comment via email or on the blog itself. http://www.flexewebs.com/semantix/accessibility-does-not-matter/ Sorry, Jason, but your essay is so poorly thought out and poorly written that you've given critical readers little to work with. You're just throwing a cat into a dog pen to watch the fun, and it's not even a real cat. If you really think there are types of websites in which accessibility concerns are irrelevant, list or describe them, but really all you're doing is exposing your own lack of broad, deep, and empathetic thinking. When accessibility matters ... * A company cares about their users You could have stopped right there. Glumly, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] I need a professional eye.
At 1/29/2010 08:36 PM, PurencoolGmail wrote: The site is www.purencool.com All I want to know is there too much css? No. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com PS: Are you *sure* this is all you want to know? What does the question mean? Too much CSS for what? If you're concerned about the size of your stylesheets, the two supporting the home page are only 5 KB so I would say No. If you're worried about the number of CSS rules, perhaps because you're afraid it will be difficult to maintain or degrade browser response time, I would say flatly No. Or do you mean that you're worried that the site might be over-styled? I would say no, it looks simple and open (which I like). I'm not positive what over-styled might look like, perhaps with too much decorative detail, but your site doesn't have that problem. I do see some problems with the site most of which have nothing to do with CSS. (Yes, I know you didn't ask.) - Neither the image fader nor the calculator worked properly in my Win Firefox 3.6 or IE8. Shall we assume they're still under development? - The calculator breaks on text-only zoom enlargement. It would be simple enough to style its widths in ems so that it grows naturally with text zoom. - I dislike the fact that your nav menus don't have hover states or an indicator of which page we're currently on. - The footer menu text looks too high in the blue bar at normal zoom, and both menus quickly break cosmetically on text-only zoom. (It's easy to make menus with stretchable graphics.) - The demos aren't enough to sell your apps. I recommend that you take a few paragraphs to detail their functionality, scope, limitations, and flexibility. I don't want to have to download a script merely to find out whether I can use it; that feels pushy and invasive. - It's irritating that your demo pages lose the nav menus so the only way to get back to the rest of your site is by Backing up. Keep in mind that many people will land on a demo page right from a search engine or other link and you want to make it easy for them to browse your site from there. - I think you should let people view the demos immediately, either right there on your home page or on the Services page. Why do we need to go to a separate demo page at all? Far better to integrate the apps right into your own site as an implicit demonstration of their integratability. - Personally I think the delay on your fader is at least twice as long as it should be. Making people wait to watch a cosmetic effect is irritating. - Your home page headline Latest Product or Service is odd. First, the ambiguity of the headline is mysterious; after all, it's your site so you should know whether the content below is a product or a service which are two very different things. Second, you don't have a Products page listed in your nav menus, and the Product or Service featured on your home page is in fact a product, creating an unnecessary and off-putting confusion. Perhaps Services in the top nav menu should be P S. Any feed back would be great and you don't have to be nice. *Whew!* Good luck with your site. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] :: 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.htmlhttp://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 QA 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: !ELEMENT DL - - (DT|DD)+ -- definition list -- 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: ol type=A lia href=a.pdfFirst/a div class=margin_left_minus_40px h3Subheading/h3 /div /li lia href=b.pdfFirst/a/li lia href=c.pdfFirst/a div class=margin_left_minus_40px h3Subheading/h3 /div /li lia href=d.pdfFirst/a/li lia href=e.pdfFirst/a/li /ol 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 div class=margin_left_minus_40px h3Subheading/h3 /div 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] 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: #8220;I have got pound;100 to spare#8221; 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 quot; or #8220; 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 #241; or ecirc;. The only HTML entities you need to use in your character data are amp; for '' ampersand, lt; for '' less-than, and gt; 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.: meta http-equiv=Content-Type content=text/html; charset=utf-8 / (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.gifhttp://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;
}
div
20px
psome text/p
17px
psome more text/p
17px
3px
/div
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.
body onLoad=loadPrices('ox001, ment001 ,hvh001 ,vhw001')
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/
script language=javascript src=rates.js/script
body onLoad=loadPrices('ox001, ment001 ,hvh001 ,vhw001')
div id=hvh001/div
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. Oh, it doesn't stop with fonts! Some website producers are arrogant enough to force text and images on the visitor instead of allowing them to enjoy the default text and images they have written for their own browser. It's shocking; simply shocking. If people actually wanted to read the text, see the images, and enjoy the graphic and typographic design of other people (give me a break!), they would have connected these computers into a world-wide network and permitted us to browse around looking at one another's... hey... wait a minute... hmm, let me rethink this one. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] website fonts
At 6/22/2009 08:49 PM, Felix Miata wrote: To put what you wrote another way, with a font family list such as your example, the visitor is at the designer's mercy to see only the designer's choice of fonts, instead of the visitor's, even if the visitor has spent big money on high quality but uncommon fonts and chosen as default one of them. To actually see his choice, the visitor will have to set is browser to completely ignore the designer's font choices throughout all documents. Like Mark, I say let the visitor's choice be the choice applied to most content, with the designer specifying otherwise only to highlight or provide character, as in headings, emphasis, or menuing. On body at least, it should be enough to specify either serif or sans-serif (partial deference to visitor), or nothing at all (total deference to visitor). If the visitor wants Comic Sans, let him have it. It's his puter, not yours. I submit that installing a font on one's computer establishes a concrete desire to view text styled in that font to be displayed in that font. Conversely, if we don't wish to see text in a particular font, we can simply remove it or choose not to install it in the first place. We're still at the mercy of PDFs and word processing documents with embedded fonts and Flash movies and docs containing text-as-image, but plain text HTML cannot force fonts on us that we do not choose to see. The user has complete control over their own computer in this regard and cannot be forced or coerced by a document designer. I put it to you that all of the text on a page provides character to the page, not just headlines menus. It is the relationship between different fonts on a page that gives it deeper character. Sans-serif heads are not the same when paired with either serif or sans-serif body text. Please explain the boundary you perceive between body text, which you feel should not be styled by the page designer, and headlines, emphasis, and menuing which you think are OK for a designer to design. Why should the page designer not influence the former and why should the font-sensitive end-user relinquish control over the latter? Further, why should we not influence letter forms but have our merry way with foreground background colors, borders, images, surrounding margins padding, line height, and other stylistic memes that can affect both readability and the reader's aesthetic context just as much as or more than font choice? I suggest we go ahead and suggest font-families but do it intelligently and compassionately, choosing fonts for a particular purpose for their grace and readability and compatibility with column-width and all the rest of the page design. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] website fonts
At 6/22/2009 12:24 AM, matt andrews wrote:
2009/6/22 Mark Harris w...@tracs.co.nz
The biggest cost I have seen in web design since 1996, when I
started, is the perceived need to make the web like the printed
page. That, and the desire to make it pixel-identical in multiple browsers.
Let the control go to the user, focus on getting information out
there. You can't control everything, just make it make sense.
Absolutely. This is probably old hat (where did *that* phrase come
from?) to most on this list, but if you haven't come across it before,
A Dao of Web Design, a short article by John Allsopp (of Westciv
and Web Directions fame) is a must-read:
http://www.alistapart.com/articles/dao/
With respect, a few points:
- Allsop's article (which, although written in 2000 and out-dated in
some of its specific references to browser development, is completely
relevant today) primarily advises us not to try to control font-size.
With regard to font-family he writes, With CSS, you can suggest a
number of fonts, and cover as many bases as possible. But don't rely
on a font being available regardless of how common it is. So his
philosophy DOES permit font-family suggestions and advises merely
against RELYING on any particular font being available. To me this is
a far cry from avoiding font-family suggestions in the stylesheet.
- If we don't rely on the presence of particular font-families and
let go of the desire to make the web pixel-identical in multiple
browsers, then the philosophical problem goes away, does it not?
- Even if we suggest fonts in the stylesheet, they're just
suggestions. I don't consider this to be controlling the user
agent. A suggested font will display if it's on the user's computer
and otherwise default to something that is. The user has ultimate
control in installing fonts of choice and overriding all stylesheets
(including the default stylesheet the comes packaged with the
browser) with their own.
- CSS font-family suggestions are a perfect case of both graceful
degradation and progressive enhancement. The browser ensures that the
text will render if there is at least one font installed on the
client computer, then the stylesheet can suggest a series of families
that more closely approach the designer's ideal. It's a system
guaranteed not to break on even the most rudimentary system, and will
look better and better the more of the desired software (fonts) are installed.
- I submit that suggesting serif and sans-serif in the stylesheet is
exactly as controlling (that is, NOT) as suggesting Georgia or Lucida
Sans. It is 'controlling' in the sense that it's suggesting to the
user agent whether to use a serif font or not, but with no control
whatsoever in determining whether a corresponding font resides on the
user's computer. If I install even one serif font on my computer,
your CSS rule of 'font-family: serif' will invoke that font unless I
override it. If I install only sans-serif fonts on my computer, your
CSS rule will ultimately be ignored and I'll see your serif text in
my Helvetica or Univers.
- There is no such thing as a web page without styling. Every browser
comes with its own default stylesheets which will determine things
like font-size, margins, and padding if not overridden by the
author's or the user's own stylesheets. So we're not really living in
a pure universe in which it's possible not to style. If you don't use
a stylesheet at all, you're just asking the browser to apply its own,
so by refusing to control you're not helping to create a situation of
no control, you're simply passing the buck. As a Buddhist you can
refuse to kill animals but as long as you're alive you can't avoid
killing vegetables and microorganisms and you can't prevent the lion
from taking down the antelope nor the spider the fly. Styling
Happens. Get used to it.
- Finally, if your relinquishing of control extends to not even
suggesting font-families, what do you use stylesheets for? Unlike
font-family suggestions, stipulations of color, margins, padding, and
other properties really are commands and will be carried out in most
browsers. {margin-left: 10px;} doesn't say to the browser if you
feel like it, it says just do it. If you do use stylesheets at
all, it strikes me as odd that you would take exception to named
font-families, the one aspect of CSS that is the least controlling of all.
Curiously,
Paul
__
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] more on fonts
At 6/22/2009 05:00 AM, Marvin Hunkin wrote:
hi.
well, the subject that i was taking, and the web page for pinciples of
visual design, my professor, said i have to had fonts, in the style sheet.
that was the requirmenet of this site i was doing for a fruit shop.
Just as a reality check, let me go over how this works.
You don't have to have any particular fonts on your own computer in
order to designate them in a web page.
You create a web page on your computer, upload it to the server, and
after that each visitor who sees the page downloads it to their
computer where it is displayed (rendered). It is the fonts installed
on each visitor's computer that determine how the text will be
displayed on their screens.
If you specify font-families in the stylesheet, you're not DICTATING
what font must appear, you're only SUGGESTING which fonts you'd like
to appear. If a font you've requested isn't installed, it doesn't
show up; that simple.
If you use the stylesheet to ask that some text be rendered in a very
common font such as Arial, it will be displayed in Arial on the vast
majority of visitors' computers. If you use a more unusual font, only
a small number of visitors might have that font and see it on the
page. Everyone else will see your 2nd or 3rd choice font for that text.
For example, if your stylesheet says:
h1
{
font-family: Gothic Rare, Helvetica, Arial, sans-serif;
}
...then the visitor's browser checks to see if it can find a match
with any of the fonts in the list. Gothic Rare will not be found
anywhere because I just made it up. Helvetica is far from universally
installed, but Arial is extremely common so most people will see the
text in Arial. If none of those three fonts is found, 'sans-serif'
tells the browser to use whatever its default sans serif font is
which might easily be different on every computer.
A sans serif font is a font with no serifs. See also:
http://en.wikipedia.org/wiki/Sans_serif
Does that help clarify any of this?
Regards,
Paul
__
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] 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 button tag and are stuck with the following syntax: input type=submit value=Button Text / Did you ever style these submit inputs with background images that allowed a flexible width? I have successfully applied a background image to input, for example the join-list form on this pre-launch site: http://innerpeaceyogatherapy.com.s9135.gridserver.com/ I consider the above solution, with its single background image, to be a mediocre, interim placeholder approach because this image with its rounded corners doesn't support text-resizing well. If you enlarge text separately from layout, the background image repeats, spoiling the cosmetic effect. (We're using a fixed width in this instance, but the same applies to horizontal repeats.) In this particular case our background image is such that input text remains legible on enlargement but we sacrifice the cosmetic single-pill appearance. If we were using a plain rectangle with at most say a uni-directional gradient but without special top- side-caps, we could simply allow it to repeat vertically horizontally without cosmetic penalty. To support rounded corners in an enlargeable context, I'd surround each input control with a matrix of divs and apply fragmented background images to those parts to allow for variable height width. ...Pending universal implementation of CSS3's multiple backgrounds! One of the usability/accessibility problems with background images on input fields is that in order for the background image to display you need to override the default border background color. Then if you disable images the input field disappears. I suppose a workaround would be possible in which the input field is positioned on top of a div with a border and/or background color that would show through if the input's background image were missing from the rendering. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Using background images on submit buttons
At 6/17/2009 06:45 PM, Jens-Uwe Korff wrote: on an ASP.NET-driven site we'd like to use background images for flexible-width submit inputs. (I apologize for getting off-topic and discussing text inputs instead. Too little sleep!) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/14/2009 06:02 PM, Andrew Stewart wrote: If you can improve the user experience using JS (why else would you be spending time on it) then you must accept that the user experience for those 10% without JS is going to be worse and hence they are less likely to buy from you, or give you some kind of revenue. Is it really worth spending all this effort to cater for users that in the end may only account for a tiny percentage of sales? Conversely, if you start out by building a robust site with server-side scripting, and then add JavaScript as an enhancement on top, you'll be spending the extra time catering to those with JavaScript, not those without, and by your way of thinking those are the folks who are more likely to bring in more revenue, so the financial model would fit the demographics. However, if someone's not using JavaScript on your site, they probably aren't using it on sites in general. Rather than compare their likelihood to buy with others of your customers who do run JS, compare their experience on your site with their experience on other sites -- the folks you're competing with. If someone is driven to your site because the competing sites are broken or clumsy without JS, then making your own site work competently without JS is a revenue generator. If you try to cut costs by shutting out that 10% or whatever of potential buyers, you're simply driving them to competitors whose sites they can use. I don't see the bottom-line benefit of that. Ten percent, by the way, is an enormous number. I mean, you have to start out by building a robust site -- that's bottom-line, right? You don't go into it with a goal to build a broken one. Is it more time-consuming to build a site that works with and without JavaScript than to build one that breaks without it? Where would the time-savings come in the development plan? If you're validating a form with JS, you still have to validate it server-side so you don't invite hackers. If you're using Ajax to update the server, you still need to write those server-side modules to receive, validate, and process the data; whether the update mechanism is an HTML form submit or a JavaScript XMLHttpRequest you still have to write the same core back-end code. We can certainly imagine pages such as drag--drop layout modifiers whose user interfaces would likely have to be radically different if pulled off completely server-side, but by far most websites have user interfaces that can look very similar if not identical without JavaScript; it's just their response time that isn't as instantaneous when it comes to, say, forms morphing as the user drills into the options. That said, client-server round trips on broadband are pretty fast these days and people are accustomed to waiting for page refreshes on most sites, so I don't think most people would consider that aspect to be a sale-killer. I don't see, for example, Amazon.com suffering for lack of sales because people are too impatient to wait for page refreshes. I am not saying this is definitely the case, but plain statistics about how many users have JS or flash or siverlight etc don't tell you the full story. If a developer has X amount of hours to spend on a site, then it is possible that the most effective way to increase revenue of that site might be to forget about people without JS etc and just create the best experience for the majority of internet users. That's graceful degradation talking. Sit tight, we're sending over the deprogrammers. Sorry if this sounds a bit like heresy. No worries -- a) it ain't religion and b) thinking people welcome heresy. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/14/2009 02:25 AM, Ido dekkers wrote: thanks for the help but for some reason, the #id works only for rows that are visible to start with? i added id= to all rows and the #id works only up to row 4? In the earlier page you posted there were ids in only the first four TRs in the HTML source. In its current iteration, I see ids in all twenty rows, and the URI fragment approach does work, e.g. http://test3.dekkers.net/policies/viewer.htm#tr10 how do i get the scrollTop ? https://developer.mozilla.org/en/DOM/element.scrollTop Because scrollTop is pixel-based, does it fail to give you the effect you're looking for when the user changes text size in mid-process? If so, Keep in mind as always that a JavaScript solution will not work in user agents not running JavaScript, which can include search engines, mobile devices, assistive technology, browsers in certain corporate contexts in which JavaScript is globally turned off or stripped out of incoming pages by firewalls, old browsers, and modern browsers used by folks who turn it off for whatever reason. A developer embracing progressive enhancement (q.v.) will first make sure that the page works for everyone and then add client-side scripting to make it faster and cooler for people using script-enabled UAs. Your policies/viewer page is dead as a doornail without JavaScript running, but it doesn't have to be. It's like you've put all your energy into the icing but forgot to bake the cake. In my own experience, getting a page to work first without JavaScript leads me to such elegant solutions that I end up adding less JavaScript than I had originally thought I would, so everyone wins: the page works universally and it's lighter-weight and more bulletproof for JS-enabled users. Regards, Paul __ Paul Novitski +1 250-226-7050 skype juniperpaul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
I incompletely wrote: Because scrollTop is pixel-based, does it fail to give you the effect you're looking for when the user changes text size in mid-process? If so, If so, consider whether the auto-scrolling is critical to the functionality of the page and how confusing it might be if the table auto-scrolls to a different row than was just edited. If both answers are Yes, you may wish to consider a more bulletproof solution. Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
At 6/14/2009 11:28 AM, raven wrote: Keep in mind as always that a JavaScript solution will not work in user agents not running JavaScript, which can include search engines, mobile devices, assistive technology, browsers in certain corporate contexts in which JavaScript is globally turned off or stripped out of incoming pages by firewalls, old browsers, and modern browsers used by folks who turn it off for whatever reason. Hmmm... what exactly problem can cause using of JavaScript *in this case* from SEO point of view? Not having seen the original poster's development plan, we can't judge whether any of the parts that are broken without JavaScript will deleteriously affect its search engine ranking. Because the page was SO dead without JavaScript, I made the assumption that the author wasn't considering scriptless UAs and therefore my remarks were intended generally. Or what browser, *witch you really support*, don't support JS? In my own work, my CSS support for mobile devices has lagged, but as my pages all work 100% in the absence of JavaScript (which I do use in every site I produce) I can say I do support to that extent all the JavaScript-disabled user agents listed at the beginning of this post. (Also I do support witches, but that's off-topic.) And what part of your target auditory even know how to disable JavaScript execution in their browsers? Don't use common words! Give us facts, numbers, tests. So, for example, if I could give you the number of individuals who would be unable to use a website because I built it to unnecessarily require JavaScript, then would you be able to tell me whether that was an acceptable sacrifice in terms of loss of revenue to the client, loss of good will, negative reviews, and negative viral spread? What percentage of your clients' target audiences have you decided to block from the sites you build for no reason other than that you enjoy building cool user interfaces in JavaScript? If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? But graceful degradation is good idea. Graceful degradation is better than nothing, but progressive enhancement rocks. http://en.wikipedia.org/wiki/Progressive_enhancement http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ If you have enough time and budget big enough you may look for solutions for case when JavaScript is disabled. I don't need to. I build sites to work well with server-side scripting, then I enhance the client-side experience with JavaScript. I don't have to justify extra work to make a site functional for any size of sub-market or worry about how many people it's OK to piss off if the site already works for every user agent. I don't provide core functionality with JavaScript. I learned the hard way that doing things the other way around is time-consuming, expensive, and frustrating. JavaScript is fun, but you aren't going to survive long if you consistently eat your dessert before your vegetables. No, first you build a car that runs well, then you add the chrome and fancy sound system. I'd better stop before I think of any more metaphors to throw in the pot. Oops, too late. P.S. In ordinar case if you can get functionality, you need, without JS do it. Exactly. To everyone, I apologize for indulging in a philosophical argument that has already seen so much traffic. Reviewing the wsg list guidelines, I hope this falls into the category of discussing best practices. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] returning to scroll position in a table inside a fixed hight div
At 6/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 span/span. 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 a 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. div id=parent-outer div id=parent-inner div id=column-1 /div div id=column-2 /div /div /div 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 ***
[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 u 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] 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:
form action=script.php method=post
div
pEnvoyez-nous un commentaire/p
input type=image src=transparent-button.png
name=sendcomment /
/div
/form
/* 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: fieldsetlegendThis is a legend/legend... Where's the PCDATA between fieldset and legend? 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] ***
[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 is the same basic layout, but without breaking IE's font resizer, with no special treatment for antique browsers, and without disrespecting the visitor's choice of font size. In Firefox 2, when the window width becomes too narrow and/or the text size becomes too large to allow the headline The Dancer's Product Resource to fit on one line, the headline wraps around with such a high line-length that the new line overlaps the content below the header. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] layout/font site test - please
At 6/3/2007 08:36 PM, Felix Miata wrote: http://mrmazda.no-ip.com/auth/Sites/ksc/dancesrqb.html On 2007/06/04 01:41 (GMT-0700) Paul Novitski apparently typed: In Firefox 2, when the window width becomes too narrow and/or the text size becomes too large to allow the headline The Dancer's Product Resource to fit on one line, the headline wraps around with such a high line-length that the new line overlaps the content below the header. At 6/4/2007 09:13 AM, Felix Miata wrote: The question remains what, if anything, to do about that missing H1 content. One option is to simply dismiss it as a problem of inadequate consequence. As grounds to support this option: 1-Its title text contains the missing portion. 2-It's really only a subtitle to the real title contained in the graphic. 3-The dearth of people who actually need such giant text in proportion to the viewport width would likely be satisfied that the meat of the page is fully accessible. Another option would be to use JS to remove the graphic, reduce H1 font-size, and/or remove the added H1 letter-spacing when some chosen ratio of font-size to viewport width is found to be exceeded. Sorry, I don't see the problem. Why not simply allow the header block to naturally expand vertically when the headline wraps? The fact that the header contains both text and image isn't a show-stopper. In a case like this when the image has a monochrome background (here, white), simply apply that background color to the header block and position the image as desired (left top, left center, etc.). If the logo has a more complex background, simply extend the image to the side and below to give it a chance to fade to a repeatable monochrome or gradient which can be a repeating background image of its container. Here's a simple example: http://i-edu.org/ Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] layout/font site test - please
At 6/2/2007 03:06 AM, Designer wrote: Sparked partly by the recent discussions on elasticity, I've been attempting to put together a 'template', based on em's and with a max-width. I've used an expression for max-width in IE 7 (pinched from Georg!). I've tested it in FF1.5, IE6 IE7, Opera 9, and Netscape 4.02. To accommodate the latter I've used a simple table instead of floating, but ignore this please - my main concern at this point is that the basics work without falling apart in other browsers. If you have time to do a check and comment I'd be really grateful. The links are dummies, apart from 'projects'. You can see it at: http://www.marscovista.fsnet.co.uk/newtemplate/template.html Nice work! In FF2 I can narrow the window to about 348 pixels before I get a horizontal scrollbar. IE7 doesn't support text enlargement very well. I'm getting a horizontal scrollbar as soon as I start enlarging the text, even when the apparent content width doesn't require it. I've been wrestling with that in my own layouts; I'm sure the solution is close at hand. Did you experiment with floating the menu so that it flips underneath the content (or vice versa) when horizontal space is constrained beyond a certain point? I imagine that will be necessary to support people who want three or more columns. You chose a background image for the header that nicely repeats horizontally as the page expands. To be more versatile I think it ought to repeat vertically as well to support high enlargement in modest window widths. Real world logos are most often single fixed image rather than a repeating pattern, but in many cases it's easy enough to fade them to monochrome to the right and below or blend them to a lower-level background image that does repeat (such as a gradient). If you size the cartoon in ems as well, I think you might be pleasantly surprised at how well it survives. Tedd Sperling has been doing a lot of that lately (http://sperling.com/examples/zoom/) and it seems to work pretty well -- as long as the crispness of the images isn't crucial to the communication, as it might be for a photographer's or artist's website. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] layout/font site test - please
Paul Novitski wrote:
You chose a background image for the header that nicely repeats
horizontally as the page expands. To be more versatile I think it
ought to repeat vertically as well to support high enlargement in
modest window widths.
At 6/2/2007 11:08 AM, Designer wrote:
I think I'm too tired. I simply can't get the thing to repeat on
enlargement. I've put it in a div and put it as the background
there, but it still won't go vertical as well. I'm Confused! It's
123 by 236px in size. Maybe it's too high for this.
You must be tired! I can totally relate to that. Your stylesheet says:
#header {background : #830 url(../graphics/fencing.jpg) repeat-x left top;}
Change repeat-x to simply repeat to go both directions.
Regards,
Paul
__
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Recommended screen size
Paul Novitski wrote: Every 40th visitor, on average, will have a bad experience... 800x600: 2.5% = 100/2.5 = one in 40 visitors uses 800px-wide screen resolution (window width not mentioned). ... At 5/31/2007 11:32 PM, kevin mcmonagle wrote: These visitors probably wouldnt notice the difference between an 800 and 1000 wide layout. So you're saying that someone using an 800-pixel-wide monitor probably wouldn't know what it's like to see the same page with a 1000-pixel-wide monitor? And therefore they don't deserve to see a decent page? What's your logic, and where's your compassion? In school the teacher has to teach for the dumbest kids in the class and that ruins it for everyone else. Oh, I see. So from your perspective life is really like an elementary school classroom, and we're really like little ten-year-olds pouting because we're too spoiled and lazy to advance ourselves when the teacher is paying attention to the stupid, mute, blind, and crippled kids. Oh my god. You're advocating a paradigm in which we can win only if someone else loses. There ain't enuf pixels on this ranch fer the two of us, Jethro! *Pow!* *pow!* *splat!* Unless, of course, it's possible that intelligent design can provide a decent page for everyone. That, however, requires a real winner. It takes the motivation to make everyone succeed and the intelligence to figure out how to make it work, the compassion to care about people different from ourselves and the brilliance to find solutions where others have failed. Are you up for the challenge? Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
list etiquette [WAS: Re: [WSG] Recommended screen size]
At 6/1/2007 07:38 AM, Chris Williams wrote: ...the teacher is paying attention to the stupid, mute, blind, and crippled kids. Well, Mr. Compassion for the User... stupid, mute, blind, crippled? Nice choice of words... Yes, I chose those offensive words deliberately to point up the attitude of the person to whom I was replying, who wrote, ...the dumbest kids in the class However, I apologize to Kevin and to the list for posting such inflammatory sarcasm. I'm glad that folks are ignoring it and getting on with business. Warm regards, Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommended screen size
design of the page, but that's inevitable if one is to avoid horizontal scrolling. A page that's engineered to survive text enlargement this way will also survive display in a wide variety of window widths (and screen resolutions). Obviously there are limits to accommodation: if you enlarge the text until a single long word won't fit in your window width, horizontal scrolling or hidden text is inevitable. It's my job to minimize those effects. I'm not too worried that a page optimized for 1024 will look very different, even homely, at 800 or 600. Readability comes first, layout second. At times this seems to put me at odds with graphic designers, but really I'm just trying to help them reach the audience with as much of their vision intact as possible. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommended screen size
At 6/1/2007 07:29 PM, Katrina wrote: However, the proactive stances also accepts that position is about to undergo a 360 degree change, with the advent of mobile devices with access to the internet. The iPhone will have a huge impact, not just because it can access the internet, but because it can access the internet with Safari, a HTML browser. And of course, the iPod have shown us just how 'cool' Apple gadgets are, and how quickly they are adopted. Kat, I appreciate your comments on proactive vs. reactive web engineering. Fortunately we can aim stylesheets specifically at handheld devices, at least. It's that enormous spectrum of larger monitors that are lumped together as one (media type screen) that give designers such headaches. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommended screen size
At 5/31/2007 08:31 PM, Tim Offenstein wrote: Anyone have a recommendation on what size screen to use as a baseline when designing for a new site? 800x600 or 1024x768 or something else? Ideally, I believe the baseline should be no assumption of screen size. Look at the spectrum of user agents: screen readers, Braille readers, handhelds, PCs, Macs, etc. Which populations of users will you choose to deny access to your sites? Design your sites so that they can be read on any of these devices and you'll be at the top of your field. Sure, read the stats, but don't misinterpret them. They won't really show you who to target. All they'll show you is how many people you can exclude by building fancy stairs and no ramps. Even if you could predict the screen size of a visual user agent, you still wouldn't know how large the user will size their browser window. Window size is more significant than screen resolution. A lot of PC users (including myself) maximize their windows by default, but that's by no means universal. For some interesting stats analysis see: Actual Browser Sizes by Thomas Baekdal http://baekdal.com/reports/Actual-Browser-Sizes/ Even if you could predict screen size and window width, you still wouldn't know how large the user has sized their text. How easy is it to enlarge text so that it spills out of your column widths, overlaps with other text or disappears off-screen, and becomes unreadable? With ingenuity you can design a page that works well with a wide variety of window widths and text sizes. Consider sizing page width in ems and max-width at 100% to let the page expand up to but not exceeding window width. Consider floating columns side-by-side so that they stack vertically when the window is too narrow for a multi-column layout. There's much, much more, but that's a start. I strongly recommend you join the CSS-D listserve and read their wiki: http://css-discuss.incutio.com/ Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Recommended screen size
Earlier I was suggesting that, instead of stats telling us who to target, they really tell us who to exclude. A fellow poster wrote: my blog 800x600 accounts for less than 2.5% of the traffic That poster appeared to be advocating for leniency, but let's take this example of screen resolution stats and turn them around. Let's say his stats apply to your website audience as well. 800x600: 2.5% = 100/2.5 = one in 40 visitors uses 800px-wide screen resolution (window width not mentioned). Let's say you design your site to look good at 1024 but crappy at 800. Every 40th visitor, on average, will have a bad experience. Is this what you want? Ask yourself not how many people you want to have a good experience on your site but rather how many people you want to have a crappy experience. What's your expected site traffic? 100 visitors a day? So two to three people every day will have a crappy experience on your site. 1,000 visitors a day? About 25 people every day will have a crappy experience on your site. 10,000 visitors a day? About 250 people every day will have a crappy experience on your site. Why would anyone want this? Why do web designers even think this way? For the most part, I think, they don't. They read the stats the other way around: they think, oh, great! 97.5% of my users will have a good experience! And they stop thinking there. Instead of trying to solve the problem they're relieved that the problem can be expressed as such a small number. Instead of thinking, How can I make this work for everyone? they're thinking, Can I make this work for most? What's the cost of expediency? Can I afford to piss off a few people in order satisfy a lot? So they don't actually perform the thought-experiments that lead to innovation and new design. This, I believe, is where you come in. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] 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 src=asterisk.jpg alt=required class=required /
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] 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? pEnter your contact information:/p fieldset legendRequired:/legend label for=nameName:br / input type=text id=name name=name value= / /label ... 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] 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] 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 big tag for example. I will probably use the strong tag then. I think the problem with using strong to demarcate your introduction isn't that strong 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 strongstronger/strong 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 p 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 hnIntroduction/hn 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] semantic HTML for intro text
At 5/26/2007 10:04 AM, Designer wrote: Presumably, p title=introduction and p id=introduction 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] 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] 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] 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 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
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] 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] 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] 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 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
li class=bullet1lorem ipsum/li
li class=bullet2lorem ipsum/li
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] 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] Semantics and small
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 pNo, it traveled emsideways/em in time!/p the adverb is not any more emimportant/em than the other words in the sentence, it's merely ememphasized/em 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 date and supplement, you may be left without a semantically direct way of specifying your auxiliary content in today's HTML. Personally I don't think small 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 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.) h1Thundering Pigs/h1 citea blog by Bob/cite No, cite is for citations. A question on cite: is this an appropriate usage? pThe SitePoint book citeBuild Your Own Web Site The Right Way/cite, by Ian Lloyd, is a great primer for learning acronymHTML/acronym and acronymCSS/acronym./p __ 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 CITEHarry S. Truman/CITE said, Q lang=en-usThe buck stops here./Q More information can be found in CITE[ISO-]/CITE. __ 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/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 CITEHarry S. Truman/CITE said, Q lang=en-usThe buck stops here./Q Truman didn't say it here, for this document...he said it somewhere else. More information can be found in CITE[ISO-]/CITE. 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: citeby Bob/cite but rather: tagby citeBob/cite/tag which doesn't help me decide what that tag 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] ***
[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.) h1Thundering Pigs/h1 citea blog by Bob/cite h1Thundering Pigs/h1 p class=taglinea blog by Bob/p h1Thundering Pigs/h1 div class=taglinea blog by Bob/div h1Thundering Pigs/h1 h2a blog by Bob/h2 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] markup for headline and tagline
At 5/5/2007 09:16 PM, Thierry Koblentz wrote: I've usually gone: h1Thundering Pigs spana blog by Bob/span/h1 I do something very similar, but using a colon: h1Thundering Pigsspan: a blog by Bob/span/h1 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: h1Thundering Pigs/h1 tagby Bob/tag 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] ***
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] ***
[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 dt 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:
dl
dtcolumn 1, item 1/dt
ddcolumn 1, item 1/dd
dtcolumn 1, item 2/dt
ddcolumn 1, item 2/dd
dt class=col2 id=col2column 2, item 1/dt
dd class=col2column 2, item 1/dd
dt class=col2column 2, item 2/dt
dd class=col2column 2, item 2/dd
/dt
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:
dl
dt id=a-titem 1/dt
dd id=a-ditem 1/dd
dt id=b-titem 2/dt
dd id=b-ditem 2/dd
dt id=c-titem 3/dt
dd id=c-ditem 3/dd
dt id=d-titem 4/dt
dd id=d-ditem 4/dd
/dt
#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[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] ***
Re: [WSG] Template Review
At 4/29/2007 06:04 PM, CK wrote: http://working.bushidodeep.com/dom_site/template.phphttp://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 img src= / 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] 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] 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] 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 li id=a at the top, and then for C you'd have li link=a. 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): ol li id=aA a href=bPROCEED TO B/a/li li id=bB a href=cPROCEED TO C/a/li li id=cC a href=dPROCEED TO D/a a href=aLOOP BACK TO A/a/li li id=dD/li /ol 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 structural properties to make my markup more semantically meaningful and less tag soupy. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com
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/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] 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/6/2007 11:04 PM, Thierry Koblentz wrote: For me if it fits in a two column table then it's not tabular data. Yikes-a-roonie! That is the most refreshingly bizarre assertion I've heard all day. And self-contradictory: if it fits in a table then it is by definition tabular, number of columns aside. Your three-column minimum certainly doesn't apply to data tables in general out there in the real world; why impose such a restriction in HTML? I've just re-read what the HTML 4.1 spec has to say about table markup and structure, and nowhere did I see any restriction on the number of columns a table may have. I have a need for a table when it is the only tool that would make sense of the data. Usually that's the way I think about it, if it makes sense only in a table then it's tabular data. If you apply that same rigorousness to all of HTML's tags you're going to tie yourself up in knots. You could as easily say that you shouldn't use a definition list unless it's the only structure that will hold the data. A 2xN dataset doesn't *require* a definition list; to be consistent shouldn't you assert that you shouldn't use a DL unless your data requires that structure? With a table's flexibility in the number of rows and columns and a DL's flexibility in the number of DTs and DDs, how can you find the kind of inflexibility you're seeking? If someone marks up a two-column dataset as H3-P pairs I don't think they're marking it up incorrectly, just differently, with some arguable advantages and disadvantages depending on their circumstances. I don't think the other way around, I don't leave room for any other consideration. So in short, if it *also* makes sense in a DL or an UL or anything else (without styling), then it is not tabular data. Because only tables can display tabular data. You're expecting the markup language to be excessively rigorous. HTML has latitude, gives us choices, leaves us room to be creative and inventive and to come up with multiple solutions to problems. If you paint yourself into tight corners then your own innovations will become brittle and uninspired. Hang loose, man. 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 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] ***
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] 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. /quote 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] New Project - Feedback Appreciated
At 3/5/2007 08:44 PM, Sarah Peeke (XERT) wrote: http://geofeat.com/ Nice site, Sarah. If you look at the home page with images turned off you'll see that there's no site title -- the graphic logo disappears and you've positioned the text head (Geofeat - all things green, eco-friendly and organic) off-screen. This past year I've switched from using that technique to using this one: mark up the logo as a foreground image with its text equivalent in the alt: h1img src=/images/presentation/logo.gif alt=Geofeat - all things green, eco-friendly and organic //h1 The head will show up with or without images enabled as well as with or without CSS enabled. I routinely style all my chrome as background images so I really had to wrestle with this idea. It finally won me over for its accessibility and progressive enhancement. And it's easy to justify a site logo or corporate identity as a foreground image -- it's not merely decoration, it's a concrete graphic entity that represents the website owner. 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] unobtrusive js help
At 3/1/2007 02:32 AM, Bob Schwartz wrote:
I am in the process of converting my javascript library to
nonobtrusive js.
...
At 3/1/2007 06:44 AM, Bob Schwartz wrote:
I'll start with the easy one first:
var d=new Date();yr=d.getFullYear();if
(yr!=2003)document.write (copy; +yr); myplace
which gives me: © 2007 myplace
Here's my pathetic attempt:
window.onload = function() {
var para = document.createElement(p);
... etc.
Bob,
I'm glad you're getting help with your javascript problem. However:
Unobtrusive javascript doesn't just mean
separation of the script from the markup, it is
also the use of javascript that doesn't break the
page when scripting is disabled.
http://onlinetools.org/articles/unobtrusivejavascript/chapter1.html
For example, a hyperlink that reloads the page
with new content can be morphed by javascript to
display the new content immediately without
returning to the server. Regardless of whether
javascript is enabled, the new content shows
up. Unobtrusive javascript enhances the page but
the page doesn't DEPEND on javascript.
Your use of javascript to display a copyright
notice means that the copyright won't be
displayed when javascript isn't running. This
isn't unobtrusive, it's obtrusive. It's like
printing a book with a copyright notice that
shows up only in artificial light but is
invisible in daylight. I can't imagine you're
protecting your client's intellectual property
rights by generating the copyright notice in such
a fragile way. Please generate the notice
server-side -- or hard-code it into the html --
so it shows up for everyone viewing the content.
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] Forward-slash suppresses word wrap in Windows IE
I've just blown some time trying to debug my CSS as rendered by IE6,
finally discovering that the problem had nothing to do with CSS.
In Windows IE, a forward-slash (virgule) that follows whitespace
suppresses word wrap:
http://juniperwebcraft.com/demo/slashwrap.html
It's only these Windows IE-class browsers that share this peculiarity:
- IE 5.0
- IE 5.5
- IE 6.0
- IE 7.0
- AOL 9.0
http://www.browsercam.com/public.aspx?proj_id=237505
Solutions: I haven't found a way to negate the effect. The CSS rule
{white-space: normal} does not override it, nor does using the HTML
entity #47;
Workarounds: Preceding the slash with a BR tag works, of course, but
I haven't yet found anything else.
Your suggestions are welcome.
I'm croggled that I've never stumbled on this before. I haven't
found any reference to it on the net.
Is it a bug or could Microsoft possibly consider it a feature?
This may be a trivial point, but it hung me up for a while because I
couldn't believe it wasn't my CSS that was causing a text box to
exceed its styled width in IE. The client's text I was marking up
separated two words with a space and a forward-slash. Fortunately
this character sequence is highly unusual.
Grumpily,
Paul
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Forward-slash suppresses word wrap in Windows IE
At 08:49 AM 3/20/2006, Thierry Koblentz wrote:
Paul Novitski wrote:
Workarounds: Preceding the slash with a BR tag works, of course, but
I haven't yet found anything else.
Try this:
P.demo2 {word-break:break-all}
Thanks, Thierry, but no go:
word-break is shorthand for word-break-CJK || word-break-inside
[1]. word-break-CJK is used with Chinese, Japanese, and Korean type
orthographies. It breaks between characters strictly at the block
width without regard for Latin-style word breaks.
Regards,
Paul
[1] http://www.w3.org/TR/2002/WD-css3-text-20021024/#line-breaking
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Forward-slash suppresses word wrap in Windows IE
At 12:01 PM 3/20/2006, Thierry Koblentz wrote: Paul Novitski wrote: Workarounds: Preceding the slash with a BR tag works, of course, but I haven't yet found anything else. Another solution would be to use IMG elements in there. It's an ugly workaround, but unlike the BRs they would create line break only when and where needed. Thanks, Thierry. Sadly, yours may be the best solution. I've added it to my demo page: http://juniperwebcraft.com/demo/slashwrap.html and run it through Browsercam: http://www.browsercam.com/public.aspx?proj_id=237505 The problem begins to show up on the third page (pictures 25-36). Your solution fixes the problem in those instances and doesn't break in any instance. I have to say, though, that inserting images into the HTML purely in order to tweak the presentation makes me twitch. Tremble as you watch the finger bones of spacer gifs claw their way out of the grave! Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] linked list alternative to nested menus
I'm contemplating an alternative to the usual nested-list nav menu structure and solicit your opinions. First, here's a standard nested menu. Opinions vary as to whether it's kosher to include all the sub-menus nested inside the parent and conceal the inactive sub-menus from visual users. I've included all the sub-menus in this markup for the sake of illustration: h3Navigation/h3 ul lia href=home.phpHome/a/li lia href=products.phpProducts/a ul lia href=widgets.phpWidgets/a lia href=whatsits.phpWhatsits/a lia href=thingummies.phpThingummies/a /ul /li lia href=philosophies.phpPhilosophies/a ul lia href=tao.phpTao/a lia href=zen.phpZen/a /ul /li /ul This makes semantic sense but could wear on your patience if you're hearing the page through a screen-reader. If you activate a link in the parent menu and bring up a new page that again contains the navigation menu, how do you know that a sub-menu exists inside the parent item? Do you have to listen through all the menu options you've already heard in order to discover and hear the new sub-menu? As an alternative, I'm considering a series of linked lists instead of one complex nested list. In the following example, the Products and Philosophies sub-menus appear after, not nested inside, the top-level menu. The Products and Philosophies items in the top-level menu now contain URI fragment identifiers (same-page anchors) linking to their sub-menus farther down the page. If you've navigated to the Products home page, I'd also add a skip link to the Products sub-menu so you wouldn't be forced to hear the top-level nav menu again: pa href=#productsSkip to Products/a/p h3Navigation/h3 ul lia href=home.phpHome/a/li lia href=#productsProducts/a/li lia href=#philosophiesPhilosophies/a/li /ul div id=products h3Products/h3 ul lia href=widgets.phpWidgets/a lia href=whatsits.phpWhatsits/a lia href=thingummies.phpThingummies/a /ul /div div id=philosophies h3Philosophies/h3 ul lia href=tao.phpTao/a lia href=zen.phpZen/a /ul /div Advantages: 1) faster easier for non-visual users to navigate (I hope). 2) lends itself easily to visual layouts in which the sub-menu lies in a column or row adjacent to the parent menu. 3) sub-menus can be displayed or concealed for visual users in the same ways as nested sub-menus are. Disadvantages: 1) The semantic relationship of parent menu item to sub-menu is obscured if not lost. 2) Because the sub-menu is not structurally nested within the parent item, some visual layouts of the menu will be difficult or impossible, such as the nested folder metaphor. Your comments? Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
