Re: [WSG] Cite in blockquote
Ted Drake wrote: I believe Jeremy Keith or PPK has a javascript that pulls the cite attribute out of the blockquote and places it as a link after the blockquote. Here's a quick'n'dirty version: http://24ways.org/advent/dom-scripting-your-way-to-better-blockquotes There's a longer version in my book which puts the attribution outside the blockquote, which is semantically more correct but a little trickier to implement. -- Jeremy Keith a d a c t i o http://adactio.com/ ** 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] accessibility - opening new windows philosophy
Ted Drake wrote:
Jeremy Keith recently spoke about using the class in the link to
target a javascript to add the behavior, leaving a nice, clean link.
In the case of PDFs opening in a new window, you might not even need
to add a class. You could write a function that looks for the file
extension .pdf in the href attribute and open that link in a new
window. Something like this:
function preparePDFlinks() {
if (!document.getElementsByTagName);
var lnks = document.getElementsByTagName(a);
for (var i=0; ilnks.length; i++) {
if (lnks[i].getAttribute(href).indexOf(.pdf) != -1) {
lnks[i].onclick = function() {
return !window.open(this.href);
}
}
}
}
window.onload = preparePDFlinks;
I haven't tested that: it's just an idea really.
--
Jeremy Keith
a d a c t i o
http://adactio.com/
**
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] implicit / explicit labels which is better?
Derek wrote:
From what I remember, Safari doesn't support clickable labels at all.
Not so cool.
That's right.
Here's a little bit of JavaScript that levels the playing field and
will make labels clickable in any DOM-capable browser:
function focusLabels() {
if (!document.getElementsByTagName) return false;
var labels = document.getElementsByTagName(label);
for (var i=0; ilabels.length; i++) {
if (!labels[i].getAttribute(for)) continue;
labels[i].onclick = function() {
var id = this.getAttribute(for);
if (!document.getElementById(id)) return false;
var element = document.getElementById(id);
element.focus();
}
}
}
Call the function with your favourite addLoadEvent function or just use:
window.onload = focusLabels;
Of course, for most browsers, this function will make no difference
whatsoever: it's replicating the existing behaviour. But for the
exceptions like Safari, it will make *explicit* labels clickable.
--
Jeremy Keith
a d a c t i o
http://adactio.com/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] My life as an 800x600 leper
Sunny wrote: i build web sites. i'm over 40. i have 20/20 vision. i work (and play) at 800x600. i LIKE it. I build websites. I'm under 40. I have 20/20 vision. My monitor is 1440 x 900 pixels but I too like to surf at 800 pixels wide (although usually taller than 600 pixels: just personal preference). When I come across a site that displays horizontal scrollbars, I *could* expand my browser window... but I could just as is easily hit the back button (which is what I'll probably what I'll do). My computer. My browser. My choice. It's all about choice. Normally choices are made by the designer with the user in mind: readable fonts, good colour schemes, etc. But when it comes to nailing an entire design onto a fixed layout, this is one of those areas where the choice of the designer conflicts directly with the choice of the user. so, seriously folks, am i wrong to hope that a site will look right in my browsing environment? Nope, you are not wrong at all. Sites that only work for a specific resolution are like sites that only work for a specific browser. Whether it's 800 pixels wide, 1024 pixels wide or whatever the latest trend might be, hardcoding widths is a shortsighted strategy. Clive Walker wrote: We use the stats here to guide our general design choices. I think that's missing the point. The goal is not to design for the majority but to design for everybody. As Anthony Cartmell said: HTML was designed to work as a flexible presentation medium. I hate the rigidity of making it work like paper In my opinion, John Allsopp's A Dao of Web Design, though five years old, remains the best and most relevant article ever published on A List Apart: http://www.alistapart.com/articles/dao/ BTW, technically this isn't really a standards question as the subject of user-centric, fluid layouts is something that's been around since before CSS/XHTML/etc. but, as a question of best practices, I think most people would agree that it's relevant. -- Jeremy Keith a d a c t i o http://adactio.com/ ** 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: Betr.: [WSG] Window Pop-ups
Kornel Lesi?ski wrote:
It uses inline JavaScript - event handlers should be assigned via DOM.
As an example, you could use a class to indicate which links should
open in a new window:
a href=http://www.example.com/; class=popupvisit the site/a
Then in an external JavaScript file, you could have a little function
that is triggered when the page loads:
1) Loop through the links in the document.
2) If the link has a class of popup:
1) add an onlick behaviour
2) cancel the default action
3) make onkeypress do the same thing.
function preparePopUps() {
if (!document.getElementsByTagName) return false;
var lnks = document.getElementsByTagName(a);
for (var i=0; ilnks.length; i++) {
if (lnks[i].className.indexOf(popup) == -1) continue;
lnks[i].onclick = function() {
window.open(this.href);
return false;
}
lnks[i].onkeypress = lnks[i].onclick;
}
}
window.onload = preparePopUps;
Because you're using a class to indicate which links open in a new
window, you could use CSS to style these links differently.
HTH,
Jeremy
--
Jeremy Keith
a d a c t i o
http://adactio.com/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] a required field marker in forms
Here's a little piece of DOM scripting that will redress the lack of
label behaviour in Safari. It's basically just doing what's built in to
many browsers: clicking on a label brings the associated from element
into focus:
function makeLabelsWork() {
if (!document.getElementsByTagName) return false;
var allforms = document.getElementsByTagName('form');
for (var formcount=0;formcountallforms.length;formcount++) {
var labels =
document.forms[formcount].getElementsByTagName('label');
for (var i=0;ilabels.length;i++) {
if (!labels[i].getAttribute('for')) break;
labels[i].formfield = labels[i].getAttribute('for');
labels[i].formnumber = formcount;
labels[i].onclick = function() {
eval('document.forms['+this.formnumber+'].'+this.formfield+'.focus()');
}
}
}
}
You'll need to call the function when the document loads:
window.onload = function() {
makeLabelsWork();
}
It isn't targetted at any specific browser(s). If the browser already
does this, then the script is just duplicating what's already there. If
the browser doesn't have this behaviour by default, it has now.
HTH,
Jeremy
--
Jeremy Keith
a d a c t i o
http://adactio.com/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Standard JS events and properties?
Kornel Lesinski asked: Where can I find authoritative list of standard (i.e. future-compatible, non-deprecated) JS properties for HTML/CSS manipulation? If you stick to the DOM Core, you can't go wrong. Basically, that means using a small but powerful arsenal of methods and properties like: getElementById getElementsByTagName getAttribute setAttribute, etc. When in doubt, I always go for the standardised DOM way of doing something even if it's more verbose, e.g. I'll use: element.getAttribute(href) instead of: element.href I'm using W3C DOM and events (I don't care about IE-compatibility) Actually, IE has very good DOM support. IE's problem is that it supports too much: it has all those proprietary methods and properties which, even though many of them have been implemented by Mozilla and other browsers, are *not* part of the standardised DOM. innerHTML springs to mind. Should I stick to pure DOM or is select.options, select.selectedIndex the right way? Well, when it comes to the forms object, that isn't going anywhere. It's part of the HTML-DOM which is here to stay. selectedIndex is a good example of a situation where the DOM Core doesn't really offer an alternative. Which way of getting position and size of elements on page is supposed to be the proper one? Ah, the CSS-DOM. A whole other kettle of fish :-) Wherever possible, try to use the style property: element.style.styleProperty The big problem with reading style properties like this is that it only works when the style properties have either been set using JavaScript or using inline styles. In other words, it *won't* pick up styles declared in external stylesheets :-( So, yeah, it is a bit of a jungle out there. Peter Paul Koch has done a lot of research on browser compatibility with various DOM methods (both standard and proprietary). His website is: http://www.quirksmode.org/ -- Jeremy Keith a d a c t i o http://adactio.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CSS Document layout/structure
Jacobus wrote: I also tend to split my css in different files. structure.css - keep all structure css Text.css - all text related formatting Small.css - used in style switcher to set text to small Medium.css - used in style switcher to set text to medium Large.css - used in style switcher to set text to large Hacks.css - any hacks I might use to help IE ;) I have my CSS split up according to task. I begin with a very bare-bones CSS file called via link which then contains @imports for the following: layout.css controls the structure. typography.css anything to do with fonts, decoration, etc. colour.css just what you'd imagine. In each file, the structure tends to mimic the flow of the document. I find separating the styles like this can be useful when I need to go back later to change something small. If it's the colour of a specific element I need to change, I know exactly where to make the change. There are some fuzzy areas though. If I add margins to an element, should that go in layout or typography? Margins, paddings and borders are kind of grey areas, I find. -- Jeremy Keith a d a c t i o http://adactio.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CSS drop-down menus
Shane Helm asked: I am about to start a project that I am going to use CSS drop-down menus at the very top of the web page. Directly below the menu bar will be a banner bar that will be done in Flash. So before I begin, will the CSS drop-down menus drop down over the Flash banner correctly? No. Embedded content (Flash, Quicktime, etc.) always appears above other content, regardless of z-index. -- Jeremy Keith a d a c t i o http://adactio.com ** 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] Stadards Site Section
Mordechai Pellar wrote:
Very nice, though it would be even nicer were your JavaScript to be
external.
Here's one way of doing that...
In your (X)HTML, assign a class of popup to any links that you want
to open in a new window:
a href=foo.bar class=popuplink text/a
Then in a JavaScript file called from the head of the document:
function popUps() {
if (!document.getElementsByTagName) return false;
var lnks = document.getElementsByTagName('a');
for (var i=0;ilnks.length;i++) {
if (lnks[i].className == 'popup') {
lnks[i].onclick = function () {
window.open(this.getAttribute('href'),'popup');
return false;
}
lnks[i].onkeypress = lnks[i].onclick;
}
}
}
window.onload = popUps();
--
Jeremy Keith
a d a c t i o
http://adactio.com
**
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] Stadards Site Section
Chris Kennon wrote: So the most standards compliant method would be loading each portfolio piece into a new window without JS. Perhaps I've misunderstood you here. Do you man the same window or a new window? If you mean a new window then the only way you can do it without JavaScript is to use the target attribute. And you can only use that if you're using XHTML Transitional. If you are using XHTML Strict, then the target attribute is deprecated. And with good reason... In the same way that old-school tags like font and attributes like bgcolor mixed presentation in with semantics, an attribute like target stirs a behavioural trigger into the mark-up. Semantically, target doesn't say anything about the link except how it should be handled by the browser... which is very presumptuous: it assumes not only that the page will be viewed in a web browser on a computer but also that the browser will have the technology to spawn new windows. That kind of behavioural instruction should be handled by JavaScript, leaving XHTML to mark-up the content semantically. Hence, the attribute is deprecated in XHTML Strict. So if this is the case, why have so many sites resorted to the carnival that is often JS, with window upon window soaking up screen real estate? I'm not sure why you'd see a difference in screen real estate between windows spawned using target and windows spawned using JavaScript. As long as the window is named consistently (either with target or JavaScript), only one window is spawned and the content is updated. Or have I misunderstood? Did you mean the same window? John Horner asked: my question is, are we not allowed to use frames any more? Sure, but again, you have to use the right doctype. In this case, XHTML Frameset. Remember, there are three flavours of XHTML: If you're going to use attributes like border, target and some other vestigial presentation/behaviour stuff, use the XHTML Transitional DTD: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd If you're going to use frames, use the XHTML Frameset DTD: http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd If you're going to mark-up your documents purely semantically (using CSS for *all* presentation and JavaScript for *all* behaviour), use the XHTML Strict DTD: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd ... or, of course, you could use any one of the many HTML DTDs, all of which would allow for more flexibility in mixing and matching tags and attributes but at the price of dated mark-up that won't be future-proofed. -- Jeremy Keith a d a c t i o http://adactio.com ** 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] Select form element doesnt validate
Michael Kear wrote: And also I was sure that SELECTED=selected was correct, but apparently not. Again I looked for the dinkum definition but couldn't find it. Anyone know where it is? Your syntax is correct, it's just a matter of case: selected=selected would be correct (lower case). One of the most common validation snags (along with unencoded ampersands) is not making all attributes lowercase. It crops up a lot with JavaScript event handlers which have traditionally been written as onClick or onLoad instead of onclick or onload (which is why one of the positive side-effects to moving all event handlers out of the document altogether is fewer validation snags). HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com ** 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] 256 colours or the whole enchilada?
Andreas Boehmer asked: Out of curiosity: what's your stand to the 216 web colours? Do you stick with them or do you go the full 16 bits? I subscribe to the More Crayons school of thought: http://www.morecrayons.com/ That gives me 4,096 colours while also allowing me to predict *how* they will degrade (they will dither to nearest web-safe colour) on older displays. Basically, what it boils down to is that in my CSS my shades of grey, for example, aren't limited to just: #333, #666, #999, etc. I also have colours like: #444, #888, #bbb, etc. The same applies to any other colours: #83b, #2f5, #456, etc. In fact, the CSS shorthand way of writing hex values is tailor made for using the more crayons technique. -- Jeremy Keith a d a c t i o http://adactio.com ** 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] auto generated PHP sessions identifier causes valodation errors
Andrey V.Stefanenko wrote: I am not able to confignure auto generated PHP output dta href=./profile/?pid=1025PHPSESSID=6a2db2de31fb7e15728cc68dd01899c4 and not able to avoid ampersands in URL Should I and how i can setup my PHP? I'd like to know if there's a solution to this as well. It's the one thing that stops some of my sites from validating: http://validator.w3.org/check?uri=http://www.thesession.org/index.php But i can avoid links - change them with forms and buttons. Is this the BEST solution for this trouble? That might just create a different problem. PHP will insert a hidden input field: input type=hidden name=PHPSESSID value=6a2db2de31fb7e15728cc68dd01899c4 / But it won't wrap that tag in a block level element so there'll still be validation issues. Any PHP gurus out there know if there's a way of customising how PHP passes the session id? -- Jeremy Keith a d a c t i o http://adactio.com * 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] Hybrid layouts
Kym Novan wrote: Using the 3 column example I mentioned earlier a single 3 column table holding the column content exactly as you want it (if I remember correctly the earlier discussion was about a layout with a fixed width RH column for news and proportional for the left and centre columns) is a lot less messy than the equivalent in pure CSS. There's definitely a case for this compromise, hybrid approach. I believe that's basically the approach that Jeffrey Zeldman takes in his book. It's certainly a good thing not to see CSS and tables as two diametrically opposed ideas: you can choose the best aspects of both. However... Tables do have a certain amount of in-built rigidity. Your example of a three columned layout could be accomplished simply using a single table. But what happens when you decide it should no longer be a three columned layout? What if you want the left column on the right and the right column on the left? You would have to go in and change the markup. That's a fairly extreme example, I know. But it does highlight one of CSS's biggest advantages: the separation of content and style. MInd you, if the content isn't well marked-up (read: semantically meaningful) to begin with, then CSS isn't going to help you much when you want to alter the layout. It took me a while to truly appreciate how working with CSS is like looking at (X)HTML documents in a whole new way. Instead of thinking: That's the left-hand column. It contains the navigation. I find myself thinking: That's the navigation. It's on the left (for now). That said, each website is different. If you know for a fact that the three column layout won't be changing and you need to get the layout taken care of ASAP, then a simple table is probably your best bet. You just need to be aware that you are, to a certain extent, tying your hands. I've also simplified my argument a bit. The order of document elements in the page flow can make an enormous difference when you're using floats for positioning (although it's not an issue at all with absolute positioning) so you could still find yourself having to alter the mark-up in order to achieve a different layout. On balance though, I believe that starting with semantically correct mark-up and well-labeled elements , e.g. (navigation rather than leftcol) significantly reduces the likelihood of ever needing to muck about with the mark-up in the future. P.S. I've added a subject to this thread: I hope that doesn't count as hijacking :-( -- Jeremy Keith a d a c t i o http://adactio.com/ * 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] legal requirements for accessability
Lachlan Hardy wrote: I understand the concept of just doing it. And that's what I do. Until the client asks about such and such and I let slip either of those cursed words : 'standards' or 'accessibility'. Whoa. Reign in there, fella! Who told you to go around doing things like this? How much is that costing me? I understand what you're saying Lachlan, but surely the important point is what your answer to such a question would be. I know that in my case the answer would be nada, zip, zero, not a penny extra. Standards compliant mark-up and accessibility hooks aren't extra features that get bolted on with an associated cost. They're simply a regular way of working (which, as I understood it, was the point of Jeffrey Veen's speech). If your client is going to get extremely pedantic about it then I guess you could answer that adding labels to form elements, summary attributes to tables and alt attributes to images could cost minutes of time. All in all though, they probably take less time than the duration of your bathroom breaks during any given project. ;-) As for valid mark-up costing more, my experience has been the opposite. If the mark-up is written in a sloppy or non-standard fashion to begin with, then the time spent debugging for various browsers/platforms increases greatly. Every time I have quoted for a job by mentioning standards or accessibility, my quote has been rejected. If I don't mention it in the quote and it comes up later, I'm royally stuffed I don't see why. Unless they're labouring under the misapprehension that standards and accessibility cost money. The truth is they're just good habits. So don't fear the money question. Just give them a straight, truthful answer. Oh, and while you're at it, you might want to tell them about the Search Engine Optimisation benefits of standards-compliant, accessible mark-up. In my experience, clients who couldn't care less about visually impaired human beings care greatly about making their sites accessible to the Googlebot. Explain to them that Google is essentially blind. Then they'll get it. HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
