Re: [WSG] Server-side includes?
Hi Paul, My question is: are server-side includes good, bad, or neither in the eyes of standards and semantics? Neither. There's no connection between the use of SSI and semantics or standards. SSI enables elements of a page to be modularised (note that there are specific SSI commands for including file modification dates, filenames. etc.). For example, the HTML for global navigation bars can be 'put' into a separate file and included into each page. FILE PROCESSING One consideration is that a page may only have one form of processing applied to it. So if a website uses PHP or ASP then server-side includes that have been implemented using directives for Apache or IIS will not work. (A PHP or ASP include directive will need to be used instead.) More on SSI: http://www.motive.co.nz/glossary/ssi.php HTH, -- Andy Kirkwood Motive: net communication -- with intent http://www.motive.co.nz ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Standards and Aesthetics
Hi John, Many standards websites have subtle gradients in backgrounds -- is this because designers are confident in using PNG files which do gradients better for smaller file sizes? My opinion is that gradients and textures are introduced to recreate the textures of real world surfaces not otherwise available to a projected light display. As an example, A List Apart's new design [1] harks back to Victorian woodcut typographic elements which lends the page 'warmth'. So, is the technology dictating the look, or are all these things just accidents of history because some major relaunch like the stopdesign/AdaptivePath redesign of Blogger looked that way? Perhaps an awareness of standards (as suggested by Russ in his expanded web standards checklist [2]) begets an awareness of accessibility and the impact of presentation on accessibility (read text-legibility in this instance). If this is the case, then form is likely to follow function. Type *not* set at 9 pixels, less incidence of type-as-image and establishing a 'style guide' (focus on content) rather than 'poster' (focus on image) suggest that the designer is more aware of end-use. When seen on mass it is likely that similar 'solutions' will be found to the same design 'problems'. As noted by Ted, the pioneers in the field of web standards have set a visual tone that those new to the field may either learn from or aspire to recreate. In particular blogs have rapidly changed the overall tone of the web both at a visual and functional level. In some ways the default templates for blogging software have set an expectation that webpages should be fixed-width and centered to the screen (not an opinion that I share). For a non-web equivalent some clients now believe that a logo is only a logo when it: -has a shadow -is 3D -or is inset or embossed If a 'web standard look' is the look that is associated with the websites that are relevant (i.e. contemporary/topical) then design agencies may 'borrow' this aesthetic to be seen as contemporary. The 'web standards look' also has much in common with the new interfaces to the Macintosh and Windows operating systems. The dark to light gradient of the OS X icons being an obvious reference. Again this can be seen as drawing on a familiar paradigm to minimise potential barriers between the user and content. [1] A List Apart http://www.alistapart.com [2] Web standards checklist http://www.maxdesign.com.au/presentation/checklist.cfm Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Good practice of CSS styled forms
Hi Goran, Our glossary provides a few form references, including usability, accessibility, styling, etc. Have reviewed the references up to a point. As per usual with the web, caveat emptor. http://www.motive.co.nz/glossary/forms.php Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Screen reader users: Label text for search field?
Hi, (Apologies for the re-post, thought this might have been buried under the flurry of CSS queries.) Currently there seem to be a few different approaches (with regional variation) to marking up a simple search form. -Search for [Input field] [Button: Go] -[Input field: Text: Search for...] [Button: Go] -[Input field] [Button: Search] The above approaches seem ok for sighted users. The issue I've come across is when the search form also enables the scope to be limited to a section of a website. In such a case I tend to build more of a composite sentence from the input elements: -Search [Select: Scope/Section names] for [Input field] [Button: Go] The issue is labelling the input field. Although accessibility sites such as WebAim markup the text 'Search' as the label for the input field, 'Search' does not describe the nature of the input? On the WebAim site 'Search' is used as the label for the input field on one search form [1] AND as the label for the search scope on another [2]. [1] http://www.webaim.org [2] http://www.webaim.org/siteindex Compare the relationship between the label and field for another common example: Surname [Input field] Here the user is expected to enter their surname into the field. Perhaps a more appropriate label for the search input field would be 'keyword'? Or is the general consensus that 'Search' is accepted shorthand for 'I want to find...' or 'term to search for'? I'm also attempting to track down some references on how screen readers negotiate (non-Javascript) select elements. Is it preferable to associate a label with the select, or use the first option in the select as the label. Label: Limit search to: [Select menu] or... [Begin select *Limit search to* -Entire website (selected) -Corporate info -Glossary -Guides -News End select] Any screen reader users out there who would like to add their 2 cents/pence/pesos? Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Wild metadata
Hi Jonathan, ** The problem ** On the Web, DC.description and DC.subject are not very effective finding aids when the full text is indexed. I'm unclear as to the purpose of your enquiry. My take on what you have outlined is that you're seeking a method of generating metadata records without requiring the author to be involved. If this were the approach taken by the White House, then George W Bush's biography would be assigned the metadata record 'miserable failure'. http://news.bbc.co.uk/2/hi/americas/3298443.stm The benefit of classification by an authority (someone who knows their field) is that the classification differentiates content. The more specific the classification, the more useful that classification is to a knowledgeable searcher. On the web, broad, common language classification systems are of most value when the subject is unknown. For example, as a new web designer I might search for 'web design'. As my knowledge increases, my search is likely to be become more sophisticated, for example 'CSS floats' or 'IE box-model hack'. It would be helpful to define both 'effective' and 'finding aid'. As search is such a broad topic it would also be productive to establish context. For example, is this a public search or a site specific search? Would metadata records be displayed to the user or factored into the page ranking? Etc. ** The solution ** Wild metadata, such as anchor text, blog descriptions and folksonomies may provide better description and subject (or keyword) metadata. If the author-generated metadata records are displayed as part of a search result records, then they provide a succinct description of the content. As to whether an individual finds metadata record support the locating of content, the method of display, relevance of the metadata records to the search conducted, personal preference, etc also come into play. Link text (i.e. the text used to link to one webpage from another) is already factored in public search engine ranking algorithms, as does the number of incoming links. Trackbacks http://www.motive.co.nz/glossary/trackback.php are an existing method of capitalising on blog comments, as the link text and blurb from referring webpage is embedded on the source webpage. With regard to folksonomies, looking through Technorati's tags http://www.technorati.com/tags/ , content is often classified according to subjective qualities such as 'rant', 'rambling' and 'random'. It is more likely that folksonomies constitute a snapshot of the evolution of language. As a 'fringe' term become socialised it emerges as part of a formal classification system. For example the term 'hack', as it pertains to CSS, has been socialised to the point where it has become meaningful search term. I would go so far as to suggest that public search engines have already implemented a 'wild metadata' approach to generating search results. Perhaps the issue with the value of metadata records lies less with how they are generated and more with how people phrase search queries and use the web. You might find it useful to browse our glossary as it provides further info on search engines, folksonomies, metadata, etc. http://www.motive.co.nz/glossary . Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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: Default placeholders
Hi Geoff, (To pick up on Patrick's point.) Have you come across a scenario on a website where it seems appropriate to use an input element to indicate that an option exists but cannot be edited by the user? Perhaps it's preferable to show such content as text rather than as an input? (Seems like an instance of yes, we have no bananas: yes this is an input, but no you can't.) Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Label text for search input
Hi, Currently there seem to be a few different approaches (with regional variation) to marking up a simple search form. -Search for [Input field] [Button: Go] -[Input field: Text: Search for...] [Button: Go] -[Input field] [Button: Search] The above approaches seem ok for sighted users. The issue I've come across is when the search form also enables the scope to be limited to a section of a website. In such a case I tend to build more of a composite sentence from the input elements: -Search [Select: Scope/Section names] for [Input field] [Button: Go] The issue is labelling the input field. Although accessibility sites such as WebAim markup the text 'Search' as the label for the input field, 'Search' does not describe the nature of the input? On the WebAim site 'Search' is used as the label for the input field on one search form [1] AND as the label for the search scope on another [2]. [1] http://www.webaim.org [2] http://www.webaim.org/siteindex Compare the relationship between the label and field for another common example: Surname [Input field] Here the user is expected to enter their surname into the field. Perhaps a more appropriate label for the search input field would be 'keyword'? Or is the general consensus that 'Search' is accepted shorthand for 'I want to find...' or 'term to search for'? I'm also attempting to track down some references on how screen readers negotiate (non-Javascript) select elements. Is it preferable to associate a label with the select, or use the first option in the select as the label. Label: Limit search to: [Select menu] or... [Begin select *Limit search to* -Entire website (selected) -Corporate info -Glossary -Guides -News End select] Any screen reader users out there who would like to add their 2 cents/pence/pesos? Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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: Default placeholders
Hi Rebecca, For example, if you wanted to show that a field was editable content (within the whole application), but not on the particular screen you are on right now (especially if the user knew that by clicking on edit or some other option they would be able to edit those particular fields.) As you mention it would be preferable to indicate this functionality by showing an Edit button next to the (currently uneditable) text. Showing that an option exists but is not currently available is often a technique used in application menus. For example it's important to know that the Copy command can be found in the Edit menu, even when the Copy command is not an available action. The user is able to learn the interface more readily when this approach is taken. However I can't think of a similar situation on a website (if you don't have any bananas then I'm going somewhere else ;). Unless the website is more of a web application. Any examples come to mind? å -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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: Default placeholders
Hi Kevin, Nice example, top marks ;). Sometimes these discussions can get a little abstract and one (real world) example can help make the discussion less murky. Geoff, I understand your pain with regard to traditional (print) designers and the often rocky transition to screen-based design. (Although there's also no guarantee that a developer is any more aware of interface semantics.) By way of confession, back in '97 I coded a form using radio buttons as found them more satisfying aesthetically than checkboxes. Hopefully education or general awareness means that up-and-coming web designer/developers have more of a community to draw on. I often think the root cause of many issues with website usability come down to the mock-it-up-in-Photoshop-then-hand-it-over-to-the-tech-people-to-be-built approach. Ideally there would be meaningful dialogue between the brand/visual and the interface/usability. I actually used read only input fields recently for our online subject selections. Compulsory subjects were pulled out of a database and displayed as read only input fields, while other fields were normal select elements. Why not just display the compulsory subjects as plain text? Because then there is a visual and cognitive dissonance between the two information sets - they can seem unrelated, especially when you consider that high school students rarely read a web form's accompanying text, no matter how important. I think in this case the fact that the information was displayed with as part of the form avoided that problem, while using the readonly attribute and styling the input text a medium grey took care of the rest. Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Naked metadata - RDF in HTML
Title: Re: [WSG] Naked metadata - RDF in HTML Hi Terrence, It feels like we're talking at cross-purposes? I'm approaching the subject with the idea that metadata is important in order for people to find (related) information at some later time. Interesting and valid point, unfortunately not the point being discussed. I think the issue being addressed by Jonathon was not how-to in a WYSIWYG editor, rather that metadata is not front-of-mind when editing an existing resource.' I equate front-of-mindness with visibility, hence reference to an editing interface that will *show* the metadata records--a wysiwyg editor. Jonathan's focus was on the author and not the reader. From the original post: ** The problem ** People updating Web pages often doesn't update the metadata in the header. The method presents an elegant solution for metadata that is important for an external audience/end users (who wrote it, when, what's it about, what else is there, where am I with regard to related documents), as opposed to the internal management of a collection (similar but slightly or significantly different to the above). I was not advocating a separate metadata collection, but rather that metadata within a single document may be more elegantly edited/updated if all contained within the head of the document, than when the records are mixed-in with the content. The leading WSIWYG editor can be extended, with much gnashing of the teeth and swearing, to provide this type of functionality. In fact, that is a major selling point. Moving away from specifics of which tool, the issue is still educating authors on a practice that is peripheral to writing the content. To create and maintain metadata requires the author to either care about metadata it also helps if they *see* the metadata when editing/updating the content. The RDF approach requires the author to have access either to the source code or the means by which they can assign classes to spans. Wysiwyg editors have *not been created to include a work flow that is optimised for adding metadata records to content in this manner*. I think the opposite. Sure, the finer points of the machine readable part of the record is invisible, If the incorrect class value is assigned, the meaning of the record changes. Say for example I accidentally markup the author's name as the title: span class=dc-titleAndy Kirkwood/span At a visual level (i.e. without viewing the name value) it is not possible to spot the error. It would also be easy to accidentally add content to a record when editing, e.g. span class=dc-titleAndy Kirkwood will be out of the office until next week/span Authors have the opportunity to administer the metadata for their own content in a simple, relevant way. Again, the popular WSYIWYG editor can be extended to help less-savvy people. As far as I'm aware, the cutomisation available does not replace the need for the author to care about metadata :). That the RDF method is simple is definitely debatable. How is adding spans to content more or less relevant to an author than adding records to the head? The example provided, http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml , re-purposes content as metadata. If the content is edited, the record could (unintentionally) be deleted, or the content rewritten to included the records required I'm missing something here... this reads like an argument in favor of both sides: you can delete the metadata or add it? At a visual level, that the word 'Anna' is a metadata record for the first name of the author would not be apparent. I might re-edit the copy from Anna spoke to Susan on the phone to She spoke to Susan on the phone. By removing 'Anna', I've remove a metadata record from the document. To maintain the metadata record I would then need add 'Anna' to somewhere else. Keeping track of which records have and haven't been entered would be a nightmare. It's enough as an author to keep an eye on structure, grammar, spelling, etc. -if metadata records are split between the head and body of a document, review would likely require a greater degree of concentration/quality assurance and/or additional supporting technologies (such as a metadata record 'viewer' that would reveal both conventional and class-based records) -etc. A custom-built CMS, as a companion to a well-supported publishing process, is still your best bet. For enterprise sized endevours with a huge budget or significant inhouse savvy, sure. Savvy enough to care about metadata, not savvy enough to edit it when all the records are in the head, but savvy enough to pick through the content and assign classes to spans to approximate metadata records AND keep track of which records have and haven't been completed? An author that is comfortable with adding span elements with class values corresponding to the DC standard is not the 'problem'. It's the person who forgets to add metadata records when authoring content. Embedding the
Re: [WSG] Naked metadata - RDF in HTML
Hi Jonathan, An interesting application of the technology, although I'm not sure that is addresses how to make it *easier* for administrators to maintain metadata records. ISSUES (Assuming the ideal solution would be a wysiwyg editing environment for non-technical content authors.) -adding DC class values to span elements is not a mark-up behaviour likely to be supported by wysiwyg editors in such a manner that it would be 'effortless' for an author, i.e. the author would typically need to edit the source code to add appropriate class values -administrators will still not entirely 'see' the metadata they've added, as it is the combination of the name and content values that creates a meaningful record, and this would only be visible at a code level -the benefit of metadata is that it can be used to classify content to a significant degree of detail *without encroaching upon the visible page content itself*. The example provided, http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml , re-purposes content as metadata. If the content is edited, the record could (unintentionally) be deleted, or the content rewritten to included the records required -if metadata records are split between the head and body of a document, review would likely require a greater degree of concentration/quality assurance and/or additional supporting technologies (such as a metadata record 'viewer' that would reveal both conventional and class-based records) -etc. A custom-built CMS, as a companion to a well-supported publishing process, is still your best bet. The metadata records can be entered at the same time as the content, with values selected from a controlled vocabulary, etc. and then output either into the head or body as required. After all, it's more than just the ability to add or edit metadata records, its also the relevance of the values entered to the content, end-use of the records and the intended community. Food for thought anyway... Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Naked metadata
Hi Jonathan, I second Patrick's comment that 'pointing' the DC records to content on the page is not the solution. Although, from a maintenance perspective, this may appear to be a work-around for not completing the metadata records (questionable), metadata harvesting tools are unlikely to populate the content attribute of the meta element with content from the webpage. In other words, the metadata records cease to have value as metadata. Consider educating content authors or moving to a CMS. For example, in a CMS, a rule could be created that require a minimum set of metadata records to be completed before content can be published. If using a static system, then adding a placeholder for metadata content to template pages may be a solution, e.g. meta name=DC.title content=[tba] / meta name=DC.creator content=[tba] / (The author would then search the source code for the string '[tba]' as part of the publishing protocol to remind them to complete the md records.) ** The problem ** People updating Web pages often doesn't update the metadata in the header. ** The solution ** Tag appropriate Web data with id attributes. Point to the data from the appropriate metadata field in the header. Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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 title styles
Hi Sarah, I was just looking for a way to give the user immediate feedback about each reference, and thought the title may be useful. The problem with linking back and forth is that there are *so* many references on each page, sometimes two or three to each quote, so it gets a bit messy. Perhaps this is more of a content consideration, i.e. that inline references are supplementary to the central narrative? If the reader is *required* to check each reference to understand the author's intended meaning/understanding, it would suggest that the content could do with another draft ; ). If re-written and truncated to suit it's use as a short-hand identification of the origins of the opinion/quotation, the title attribute on a source anchor (that links to the full reference) would appear to be a good compromise. Although a deviation from strict academic referencing practice, consider moving the title of the work to the front of the attribute value: a href=#ref1 title=The mode of action of lipid-soluble antioxidants in biological membranes. Relationship between the effects of ubiquinol and vitamin E as inhibitors of lipid peroxidation in submitochondrial particles., Ernster L, Forsmark P amp; Nordenbrand K. (1992)sup[1]/sup/a It might even be appropriate to omit all other details (year, author(s), publisher, etc.) and strip out the strapline. a href=#ref1 title=The mode of action of lipid-soluble antioxidants in biological membranes.sup[1]/sup/a Even if using the JavaScript method, editing and truncating the reference will likely suit it better to its intended purpose. Rationale: - the first few words of the title are most likely to be read - the first few words differentiate one reference from another - (perhaps subject to content-field), the title of the work provides more *immediate* context - the title text is likely to be truncated - the author's name is often referenced inline, e.g. (Ernster L, Forsmark P Nordenbrand K, 1992) is an comparable conventional short-form reference. - if content deals with a specialised topic area, the author's name(s) are likely to be repeated and it won't be possible to distinguish between different works by the same author(s) -in general, web-writing prioritises content over authorship, for example, link text that describes the destination content tends to be more useful/usable than link text that identifies the destination content author. Additional considerations: - indicating to the reader (visually or otherwise) that the source anchor can provide an expanded reference (a link 'says', click-me rather than hover over me for a couple of seconds, then click me) -using an unmodified superscript element may make it difficult to hover or click the reference link (too small a target) Additional approaches to footnotes and endnotes: http://www.cs.tut.fi/~jkorpela/www/fn.html Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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 title styles
Hi Sarah, Unfortunately the exact wording of the content (in this client's case) is legally required, and so the possibility of editing it, or the references, in any way is out of the question. Moving the title of the reference to the fore of the title attribute value wouldn't be changing the reference (as it is shown in the endnotes), but representing it in a medium-appropriate manner? If the title attribute is too long it will be truncated anyway. It could be perceived that there's a similar issue of changing the content when adding alt attributes or long descriptions to images, in-page anchors, etc. It may come down to the relationship with the client, but if the protocol you recommend for implementing references on the website is formalised, then perhaps using the title attribute would be seen as a adding-value-to rather than 'changing' the reference? The client's web style guide would then be updated to ensure a consistent approach is taken to marking-up future documents (and get the legal team back on board). You could illustrate the issue of medium-specificity with how a search engine results page may excerpt a portion of a document (without the complete reference text). I like the idea of linking back to the content once the reader has read the relevant footnote, but there are many instances when more than one footnote is attributed to a portion of the content (see example below). Also, the same footnote reference is referred to in different portions of the content. The example you've provide isn't too bad, you could create separate links for each reference marker (a[1]/aa[2]/a). What's more problematic is the second situation you've identified where a single reference is linked to *twice* within the same document, e.g. pThis paragraph is at the top of the document [1]/p p/p pThis one is further down the page, but also references the same document [1]/p (Clarifying for the benefit of the avid reader.) Making clear to the user which of the two reference markers the user would jump back to, would perhaps be more trouble than it's worth. Looks like linking the reference back to the reference mark could be out then. Although the one-way system might not be too bad--the reader can still get a quick sense from the title attribute as to what the reference is to, and then read the full reference by clicking the link. I'm not against the JavaScript Sweet Titles option posted, but agree with the spirit of the usability observation on the entry that an overly-long tooltip may 'feel' unwieldy or provide more detail than might be expected/required from a short reference. Let me know the path you end up taking. As usual, there's no 'silver bullet'... Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Help needed with IE drama...
Hi Darren, I haven't reviewed the bug, however if its anything like the issue we've come across with comments [1] then you could try an alternative method of commenting the code. (This goes somewhat to the concept of semantic markup also.) Rather than: !-- begin footer -- div id=footer ... /div !-- end footer -- try: div id=footer ... !-- end footer --/div Rationale: The id attribute identifies the nature of the div (as a result of taking a semantic approach to assigning the id value there is no need 'duplicate' this information in the comment). It is more problematic to keep track of the end of the div, and so a comment is useful. Placing the end comment inside the /div avoids the issue with floats and comments. Admittedly, it took me a while to get used to the new coding convention, but the judicious use of white space helps. [1] Bug caused by floats and comments: http://www.positioniseverything.net/explorer/dup-characters.html We've worked out that the issue was caused by the comments in the HTML file. Has anyone had this sort of issue before? If there a solution other then removing the comments? Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] advices for using headings more correctly
Hi Julián, SEMANTICS EXTRACTOR Sometimes a view that approximates the semantics of the content can be useful. Fortunately the W3C have just such a tool: http://www.w3.org/2003/12/semantic-extractor.html . This will likely affirm Paul's point regarding an h3 as a 'parent' to an h2 element (i.e. don't). INDEX vs CONTENT PAGES It's also worth distinguishing between index and content pages when considering use of heading elements to impose structure. (An index page being an entry-point to a section of a website, for example a list of recent articles structured by topic.) For this type of page you might want to re-jig the hierarchies, e.g.: h1Articles/h1 h2Topic/h2 h3Article title/h3 h3Article title/h3 h3Article title/h3 h2Topic/h2 h3Article title/h3 h3Article title/h3 h3Article title/h3 If you have articles and guide on the same page, then this would be one of the rare instances where multiple h1 elements may be appropriate. h1 AND WEBSITE NAME/TITLE I wouldn't recommend using an h1 for the website title. If you're concerned with identifying the website (for example to screen readers) then include the website name/title in the title element, e.g: head titleContent title | Website name/title /head body h1Content title/h1 ... /body See 'Typical user scenario: 1-7 for an outline of how a screen reader may interpret page elements': http://www.standards-schmandards.com/index.php?2005/01/10/13-browsing-habits For more on the title element http://www.motive.co.nz/glossary/meta.php Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Text choices on our own sites
Hi Joe, Our clients don't care as long as it works. They do care that we care enough to make them the best, most accessible site we can, but they could care less how. It's more of an issue when a website is maintained by the client. If they're not aware of the distinction between accessible and inaccessible markup, they'll be unable to preserve the integrity of the content. If they 'don't care' in this sense, then they won't take the time to add alt attributes, validate code, only use tables for data, etc. While some CMS's have measures to prevent contributors from unintentionally creating inaccessible markup, others happy proclaim standards compliance while encouraging/enabling content to be entered inappropriately or incompletely. For example, the use of blockquote to achieve a text indent (a 'feature' of a number of wysiwyg authoring tools). An informed content author would (of course) only use this feature to denote a quotation... The manufacturing industry provides another example of where standards are equally important. Screw threads, washer bores, etc. that are manufactured to a particular quality (as in materials or finish) or standard specification (size, weight) have a 'home' in the real world. It all depends on who the client is and what criteria they're using to assess potential development partners as to how relevant standards and accessibility discussions are. Legal precedents can also carry a bit of weight. Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Text choices on our own sites
Hi Richard, To play the devil's advocate... Certainly humanist developers aim to remove the barriers that technology might place between users and content. However, difficulty arises when determining what constitutes 'technical' literacy. This could range from 'What's a link' through to 'How do I increase/decrease text size'. Even many of the 'hooks' put into content markup to make it more accessible are not used by a screen reader unless the user customises the behaviour of the software (reading title attributes for one). The issue of determining prior (technical) knowledge is one of those bug-bears like browser statistics. Even though we'd like to, it's problematic to generalise. On the other hand, adding an introduction to every webpage on how to use the web is equally untenable. Incidentally, does anyone know of a formal public-school curriculum that covers using the web? Such a document/documents might provide an insight as to how we (as in society-at-large) currently qualify 'technical literacy'. I think it's important to NOT expect users to know how to do this or even be vaguely technically literate. Doctors, for example, shouldn't have to be IT experts. They fix people not machines. It's simply not their job or responsibility to be forced to learn the HUGE amount of stuff that as developers we've crammed into our head. This doesn't mean they should be penaliseed and not allowed to see web sites or interact as freely on the web as the rest of us. -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] File sizes in links: kb KB mb MB etc.
Hi Dan, Data storage units are a bit of a can of worms. The problem lies in common-usage vs. international standards. There are also 'old' and 'new' standards for unit abbreviations. METRIC vs BINARY UNIT GUIDE Essential reading before continuing... http://www.romulus2.com/articles/guides/misc/bitsbytes.shtml RELEVANCE TO USERS There are a few reasons for showing filesize: -setting an expectation of time-to-download -setting an expectation of filesize (perhaps preferable for users on fixed usage plans) -inferring quality (assuming bigger file = better 'quality') As connection speeds tend to be in kilobits per second (kbps), then filesize _may be easier to convert to 'time-to-download'. (Although download speed uses metric notation while data storage values tends to use binary notation). The discrepancy between data transfer speed (metric) and filesize (mostly binary) is likely to be the root cause of the unit abbreviation confusion. I'd recommend MiB/MB for files greater than 1MiB/MB, and KiB/kB for files less than 1MiB/MB. If a single webpage offers alternative quality options, say for Quicktime media files, listing the download options with filesizes using the units may make it easier for the user to choose an appropriate option. Listing options in a meaningful order, e.g. from smallest-to-largest filesize will also help. (At all costs avoid ambiguous labels such as 'High' or 'Low' which could equally relate to connection speed or quality.) FILE SIZES UNDER MAC vs WINDOWS To add insult to injury, Mac and Windows operating systems use different systems when calculating filesize. Windows 2000 (File Properties) -binary: 1MiB (mebibyte) = 1024 KiB (kibibytes) Mac 0S X (File Info) -metric: 1MB (megabyte) = 1000 KB (kilobytes) SUMMARY Given the relative number of Mac and Windows users (more Windows users) and referring to the new IEC standards, the 'correct' unit abbreviation *should be* mebibytes (MiB) or kibibytes (KiB), however this flies in the face of common practice that refers to the 'old' standards of MB and KB. Toss a coin? a href=file.pdfSome file (PDF 0.1MB)/a My inclination is to use MB (Megabytes) where appropriate (ie. if the file is greater than 0.01MB), and KB (Kilobytes) for files less than 0.01MB. My reasoning is that more users can grasp the concept of a Megabyte (think floppy disks, flash drives, some MP3 players) than they can a kilobyte, kilobit or megabyte. My only concern would be that most sites seem to use (ambiguosly) one of the kb varieties. -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Radio New Zealand site relaunch
Hi Mike, I'm curious as to how the decision regarding browser support came about. What did the client perceive the 'benefits' of excluding a particular user-base to be? Why not cater to IE5 Mac if the work had already been done? no, that was an informed client choice! We had orginally done the templates to look pretty much the same in IE5 (Win and Mac), but during the integration phase they decided to not send styles to those browsers. I think their statistics showed very few visits from those browsers. I guess this may be one of the first examples of a major (for NZ) public site making the choice not to send styles to those browsers. Yah for clients prepared to make that decision :) -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Radio New Zealand site relaunch
Hi Terrence, My interest in Mike's post is in the client-developer relationship. What swayed the client toward excluding Mac IE from stylesheet support could be beneficial when considering the merits of such an approach with other standards-aware clients. Perhaps the RNZ decision means that Mac IE is now 'browser non grata'. The content is still available to any browser, so in that sense no-one is being excluded. Substitute 'user-experience degraded' in place of 'excluded' if you will. Unless I have misunderstood Mike, a decision was made to exclude Mac IE users *when they had already been 'included'*. taking a long term view there will be benefits from the reduced site maintainence. Such as? A 'dead' browser cannot spawn new bugs, once know bugs have been addressed, there should be no impact upon website maintenance. I can safely say, from server logs I have access to, the only people using IE5/Mac in New Zealand are designers/developers testing their (or my) designs, and you are more likely to come across IE/PC 4 in the wild. As you note,' from the server logs you have access to', and browser statistics vary depending on the user community--unless you're making direct reference to the RNZ website? Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Firefox mystery space bug?
Hi Joe,
Extra space between divs is often caused by a bottom margin overhang on the
content of the top div. For example, say the p element has a bottom margin
.of .6em. If this is the last element in the top div you may get a space of
approx .6em between the top and bottom divs.
The solution is either to set a custom class on the last element in the top div
to zero the bottom margin, or (preferred) add a dummy element under all content
in the top div with a zero'd bottom margin.
HTML
div
pLast paragraph element./p
p class=endnbsp;/p
/div
CSS
p.end {
height: 1px;
margin: 0;
}
You might also want to set the visited state colour for the footer links to
something with greater contrast than purple on blue.
check this out. http://hayteam.sitesbyjoe.com/default.asp
I get this occasional bug to show in Firefox for Windows. What happens is
occasionally Firefox puts a big space at the bottom of my content before just
before the footer as if I had a bunch of spaces in there. It doesn't always
happen, but sometimes it shows up if I refresh a few times, then after another
refresh it disappears.
--
Andy Kirkwood | Creative Director
Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
**
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] Couple of question - Image Map etc.
Hi Taco, SINGLE IMAGE vs MULTIPLE IMAGES A single image loads faster than the same cut into separate images. HTTP requires a new connection to be made to the server for each file (i.e. image). Even when the single image filesize is the same as the sum of the individual files, reconnecting to download each file introduces noticeable 'lag' (obviously more noticeable on dial-up than cable). Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Footer Navigation
Hi Sarah, COLD WAR AND NAVIGATION CRITIQUE A usability consideration with link duplication is the potential for 'navigational confusion'. This becomes more pronounced if there are *apparent* differences either in presentation or wording of the navigation. To polarise the issue, it can be useful to adopt a 'cold-war' mindset. Assume that navigation is the interface to a military mainframe computer, where , at a moments notice the operator has to deploy a countering anti-nuclear missile. In this hypothetical situation hesitation caused by poor navigation labels or duplicate navigation could have serious repercussions. (I was put on to this particular paradigm by a Useit article reappraising military computer interface standards from 1986: http://www.useit.com/alertbox/20050117_guidelines.html ) SIGN-POSTS In a previous incarnation of our corporate website, we eschewed navigation at the top of the page entirely. Our rationale was, that coming to the end of the content, presenting the user with the top-level navigational options would be more efficient. No scrolling back to the top of the page. Our thinking was changed by Steve Krug's 'Don't Make Me Think' (with its either ironic or unfortunate cover) where he discusses navigation in terms of real-world signage. If you're lost in an unfamiliar city do you look to your feet or up at street signage? In addition, when a user looks to the top-level navigation, it is likely that they are starting a new 'task'. The street-signage analogy, coupled with Western reading traditions of starting at the top left of a page convinced us to move our navigation to the top of the screen (and only list administrative-level links in the page footer). For more support you could also refer your client to our glossary entry on navigation: http://www.motive.co.nz/glossary/navigation.php Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Dublin Core metadata
Hi Paul, The main advantages of the Dublin Core metadata is that it represents the efforts of a group of information and library science experts to translate the cataloguing conventions previously associated with real world libraries into metadata equivalents. This translation includes details such as publisher, copyright, etc. For a complete list of the elements see our glossary entry: http://www.motive.co.nz/glossary/dublincore.php Adhering to the standards the DC working group recommend is one step toward interoperability--enabling catalogue records to be shared by different organisations. This aim of interoperability is not dissimilar to that of a web standards approach to content markup. AFAIK DC is of most use for custom-build search engines rather than for public services such as Google. In New Zealand, DC metadata is used for the New Zealand government porta and locator service: http://www.motive.co.nz/glossary/nzgls.php . For a less dry example, the Image Library of the Australian National library also uses DC metadata: http://www.pictureaustralia.org/ I have recently been reading about Dublin Core meta data. I would like to know what the main advantages are of using it and how widely it is interpreted by search engines. I am having a hard time finding out the right information, could anyone point me in the correct direction or maybe give some knowledge? Best regards, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Zoom Layouts
Hi Mike, Seems that making user's aware of what 'zoom', 'single column', 'high/low contrast', 'low graphics' or any of the other alternatives is another issue like that of educating new users about browser 'Text size' options. From personal experience, when first stumbling upon issues of web standards / accessibility etc. links like 'XHTML' and 'CSS' (as links to online validation services) and the 'AAA' ratings for accessibility were less than clear. Although it would be great to think otherwise, *task-focused* users rarely follow a link or click a button 'out of curiosity'. Perhaps 'Zoom' has been borrowed from the Microsoft Word interface for magnifying the page. Further to this, 'What do I know' [1] uses common wysiwyg interface convention to signal that page layout can be customised. From a graphical perspective the issue is indicating the change that will be affected by choosing a layout 'option'. Using 'What do I know' as an example, the various-sized 'T's are an effective illustration of what their activation will achieve: an increase or decrease in type size. Perhaps an icon that indication of a single column (maybe with an obviously enlarged 'T')? The irony is that icon-i-fying the Zoom display preference is likely to make it smaller, and assuming the feature is to cater to people with visual impairment, the option may well be overlooked. A companion issue is the consideration of user expectations: that websites are often perceived as more akin to a printed page than an application. As such (at least in the usability tests we've conducted) the user's expectation is that the page is 'the way it should be' and the concept of customising layout or display is still alien/novel. The point raised by Patrick is also interesting, namely that we should recognise that the user experience is not solely the domain of web authors. While (admittedly with the best of intentions), we attempt to build layout controls into content, there are dedicated programs developed to improve the browsing experience for users with specific accessibility requirements. References [1] What do I know http://whatdoiknow.org Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] Zoom Layouts
That's what makes selecting a suitable representation difficult. With a 'T' and magnifying-glass icon, would the user expect to have their layout transformed from 2 or 3 columns to a single column or a high/low contrast layout? Perhaps the type size, layout and contrast options should be separated as is usually the case with monitor setting controls (brightness, contrast, etc.). A point raised (by a non-WSG member) is also to consider the length of time a user will spend on a website. Obviously an unknown quantity, but the typical expectation of web content seems to be the 'quick fix', e.g. enter a term into a search engine, link to the page, find the info, move on. Display controls pre-suppose extended browsing of a single website, to the extent that the user would seek to customise the interface. This is why such controls are perhaps better left to browser developers; to ensure a consist/usable experience *across websites* rather than rely on controls that may or may not be available on a site-by-site basis. Might I suggest a magnifying glass over the 'T', or a '+' as an icon? -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] avoid Verdana - I cant get the whole point.
Hi Julián, There's no reason to avoid Verdana. In the example webpage you referenced, the author's chief concern seems to be with what happens to copy legibility if Verdana is *not* installed. As Verdana comes bundled with a significant number of Microsoft products and the Windows operating system [1], a user would need to actively remove Verdana from their computer before this would be an issue. I'm assuming that the such users would also have the requisite skills to adjust text size and/or define their own style sheet. Other users that do not either use Windows or Microsoft products probably fall into the category of 'technology enthusiasts' and may be more likely to be those with a tendency to customise their own interface. The 'attractiveness' of Verdana is matter of preference, as is the optimal size that copy should be set at. One of the more interesting points about Verdana is that it was designed specifically for onscreen legibility (unlike Times New Roman, Arial, etc.) The design of the typeface is such that the apparent letterform (bitmap) changes significantly depending on the size it is set at. The typeface was also intentionally designed with larger counters (the negative space insize the letterforms) for the same reason. As Mike mentions, the most productive point to take from the webpage is to enable text to be resized, i.e. to avoid non-relative sizing methods such as pixels, points, etc*. REFERENCES [1] http://www.microsoft.com/typography/fonts/default.aspx * Yes the W3C describes pixels as a relative unit, however it is more accurate to consider that this 'relative' quality only exists in terms of contrasting outputs: paper vs. screen, or screen resolution, i.e. beyond the browser experience. Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] H1 content
Hi Damien,
We recommend reserving the h1 to describe the page content. Perhaps on the
homepage and the 'About us' page this might be the same as the website name.
Should you want to include the site name on the page, we recommend appending it
to title text instead. For example, if the page is on 'New Zealand Postal
History 101' and your site is 'United Philatelists', the title element would be:
titleNew Zealand Postal History 101 | United Philatelists/title
See our glossary entry for more on the title element:
http://www.motive.co.nz/glossary/meta.php
Both in terms of both SEO and download speed (and as speed translates to
improved user experience), shorter, topic-centric pages are preferred.
What is often overlooked in discussion of the use of h1, is that of the
overall user experience/content. Namely: What encourages a user to link to a
webpage from a search engine results page (aside from relevance ranking)? Is it
on the basis of the site owner rather than, or above the page content? While
the site owner (effectively the 'publisher') may recommend one webpage above
another, 'declaring' the site owner in the webpage h1 does not appear to
server the needs of the user.
That said, there are a number of content distinctions that XHTML does not have
a dedicated element for, and 'site owner' /'site name' is one of them.
(Re: Andy Budd's blog.) As to whether there should be more than one h1
element per page, that depends on how you choose to break-up ('chunk') content.
Sometimes it is beneficial to create a single page multi-screen document, for
example when the page is likely to be printed. In such cases, each h1 is
likely to correspond to a 'chapter heading'.
Perhaps there are assistive technology (e.g. screen reader) considerations
someone would like to add? What is the impact on the user experience of
'announcing' the site owner when each page loads? (Positive or negative.)
I've read different opinions on what should be in the h1, and there are a
number of different options/practices.
1. Site title (ex. John's website)
2. Page/document title (ex. Contact me)
3. Combination (ex. John's website - Contact me)
4. Something else?
Which do you think is the most appropriate? Or does it depend on the site?
å
--
Andy Kirkwood | Creative Director
Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
**
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] Width defaulting to 100%?
Hi Kara, Unlike a td, a div will expand to fill the available space (and not the content it contains), if a width is not specified. To achieve the layout you describe, you will need to: -set widths on the divs, and/or -set left or right margins to accommodate both divs, for example if div [A] is 20px width then div [B] should have a left margin of 21px. This tutorial might help: http://www.456bereastreet.com/lab/developing_with_web_standards/csslayout/2-col/ , otherwise try googling: 'CSS 2 col layout'. For some reason, both divs are expanding horizontally to take up all the available space, even when the content inside them is only 20 pixels wide. I'm not specifying any widths because the content is dynamic so I have no way of knowing what the width will be. The only width I have specified is the container width of 60em. Why are they doing this? Shouldn't they only expand horizontally to make room for whatever is contained in them - in this case only a few words? Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] tabbing through links
Watch out for IE keyboard navigation bug. Depending on your method for setting the destination anchor, things can go a little awry. For details, see: http://www.motive.co.nz/glossary/anchor.php Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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
Title: Re: [WSG] accessibility - opening new windows philosophy Hi there, Could be that this discussion has drifted toward usability rather than accessibility. Accessibility considerations would be ensuring that users are advised of what will happened when they activate the link, either than the document would be opened in a new window, or that it will be downloaded. Also that opening a new window does not adversely effect users accessing a website with assistive technologies (screen readers, etc.). As to user expectation, it all depends on context. Some forms of content, such as blogs and forums are 'riddled' with pop-up windows, users exposed to such content quickly become familiar with pop-ups. As an interface design philosophy, ceding control to the user is your best bet. (This also extends to enabling text to be resized, fluid/elastic layout, etc.). In the case of pop-ups, only opening documents in new windows prevents an experienced user from controlling the browser behaviour. Indicating that a link will open in a new window is a good start, providing both a popup and non-popup link may be safer (see below). As an aside, some browsers have difficulty opening documents in new windows, when the document is a not a recognised content type. As a document like a PDF is not either a 'webpage' or inline content (such as a GIF or JPEG), the browser may only open a blank window (without downloading the document). REFERENCES Popup windows (Motive Glossary) Philosophy. Common reasons for using pop-ups, etc. http://www.motive.co.nz/glossary/popup.php WAI Checkpoint 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. http://www.w3.org/WAI/wcag-curric/sam77-0.htm So, I told my co-workers that I would throw this out to the standards community. Try to ignore any bias I may have. I would appreciate any honest feedback about whether we should open new windows for .pdf, .doc, .ppt, xls, .visio, or .whatever. Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand
Re: [WSG] 'strong' as class name
Hi tee,
.strong {
font: 1em bold #369 Arial, San Serif
text-transform: uppercase;
text-decoration: none;}
The font shorthand doesn't include a color property. Your rule should
look like this:
.strong {
color: #369;
font: bold 1em Arial, sans-serif;
text-transform: uppercase;
text-decoration: none;
}
Note that the second font family is 'sans-serif' (with an 's' and hyphen).
HTML
Also a bug in the HTML, you open a span but close a strong.
pspan class=strongStrong/strong is bold/p
/div
Should be:
pspan class=strongStrong/span is bold/p
FURTHER READING
http://www.devarticles.com/c/a/Web-Style-Sheets/CSS-shorthand-at-a-glance/2/
Cheers,
--
Andy Kirkwood | Creative Director
Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
**
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] Lynx current navigation state presentation
Title: Lynx current navigation state presentation Hi there, LYNX CURRENT NAV STATE PRESENTATION Regarding feedback provided by ¸ukasz, to the use of em vs i elements in Lynx... I *use* i and b. CSS has nothing to do with it. Does anyone have a preference/recommendation for how the currently selected navigation state should be presented in Lynx? Is it using a leading ASCII character, b or i element? Cheers, -- Andy Kirkwood | Creative Director Motive | web.design.integrity http://www.motive.co.nz ph: (04) 3 800 800 fx: (04) 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand
[WSG] New Zealand Government Web Guidelines
Hi, NEW ZEALAND GOVERNMENT WEB GUIDELINES I posted to the group late last year regarding formal implementation guidelines that refer to web standards. Mostly these are created by public sector (government) or government-related organisations. For those interested, we've just added a developer's introduction to the New Zealand Government guidelines to our glossary. http://www.motive.co.nz/glossary/nz-web-guidelines.php The guidelines themselves provide an interesting take on web-based communication and could be useful for those grappling with reconciling standards with practise. Cheers, -- Andy Kirkwood (04) 3 800 800, 021 369 693 93 Rintoul St, Newtown, Wellington ** 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] Actual Page Dimensions[revised]
Hi Chris, Is there an article of chart outlining subtractions from design dimensions for browser chrome and optional bars. My current design is 800x600 for centering horizontally. Intuition begs some appearance of a horizontal and/or vertical scroll bar on some UA. I'm aware these will appear in Browser Cam, but was hoping for a preventative approach. I've goggled, perhaps asking the wrong question. Would some knowledgeable colleague assist? We have a minimum available screen size by monitor dimension chart as part of our glossary [1] (as part of an entry on the concepts of above the fold). Our entry includes a 'screen-guide': a background image you can use to resize your browser window to emulate the minimum visible screen size, i.e. assuming all browser elements and systems menubars are displayed. Note that the figures used are based on a Webmonkey article: Sizing up the browsers [2]. Although browsers have changed since 1999-2000 the trend seems to be toward less rather than more chrome, so should still be a useful starting point. [1] http://www.motive.co.nz/glossary/fold.php [2] http://webmonkey.wired.com/webmonkey/99/41/index3a_page2.html?tw=design Cheers, -- Andy Kirkwood Motive | web.design.integrity http://www.motive.co.nz ** 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] empty named anchors
Title: Re: [WSG] empty named anchors
One reason why you might not want to have content inside of an
anchor would be because of the implementation of stylesheets (or more
accurately how style rules have been specified).
For example if a hover rule is written for to the a
element it will be applied to content enclosed in the anchor tag (as
well as linked text).
a:hover {color: #900;}
I have come across a couple of instances of this where headings
have been enclosed in an anchor, i.e.
a name=anchor
id=anchorh1Heading
text/h1/a
This causes the text colour of the heading to change when
moused-over (although not a link). From an interface perspective this
can be quite confusing. (A feedback cue that suggests interaction is
possible when it is not).
Cheers
--
Andy Kirkwood
Motive | web.design.integrity
http://www.motive.co.nz
[WSG] Semantic markup for object dimensions/units
Hi list, Any thoughts on semantic markup for object dimensions? For example works of art; height x width x depth 400mm x 800mm x 200mm Could be two parts to this, markup to indicate dimensions (that the 'x' is mathematical: 'by'), and that 'mm' is an abbreviation of a standard unit. (aside from abbr title=millimetersmm/abbr). Any cultural institution web folk out there with experience in this area? Cheers, -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity Wellington, New Zealand ** 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] e-Government Implementation Guidelines
Morning list, *Please respond to this request off-list ([EMAIL PROTECTED]), once we've compiled the results we'll get Russ to add a link to the Resources section of the WSG website.* E-GOVERNMENT IMPLEMENTATION GUIDELINES We're attempting to compile a list of international e-government web guidelines. (In NZ these standards have had a significant impact upon the acceptance and perceived legitimacy of web standards.) Implementation guidelines typically include reference to: -navigation -coding/language standards (HTML. XHTML, CSS1, etc.) -technical considerations -markup requirements -accessibility and usability aka: web-authoring requirements. GUIDELINE INFO The list we're compiling will include: - Country - Guideline Title (as link to webpage) - Coverage (e.g. Western Austrailian Government Agencies: Australia seems to have a new permutation for each state!) - Publication date, revision dates (Other info dimension suggestions welcome). PLEA Those of you who are conversant with your country's forays into this area, please send me a URL (the more specific, the better). Webpage/permalink please (no PDF links). We'll explore the links provided but feel free to provide any of the Guideline Info along with the link (see above). Disclaimer: My command of languages other than English is not great, but I'll endeavour to add all guidelines received. Best regards, -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] The Holy Grail ... CSS Liquid Three-Column Layout
Title: Re: [WSG] The Holy Grail ... CSS Liquid Three-Column Layou I think I may have found the Holy Grail that 3-column css liquid layout What I need help with is this: I have checked this out on Mozilla, FireFox, Netscape, and IE all on the pc. Can anyone who is interested please check it out on some other browsers/platforms? Here's the link: http://www.ManiSheriar.com/holygrail Checked (OK) Safari 1.2.4 OS X (Mac) Opera 6.0.3 (Mac) Netscape 7.1 OS X (Mac) Minor bugs IE 5.2 OS X (Mac): extra padding added to the width of the left and right columns Screenshot: http://www.motive.co.nz/temp/041217-hoygrail.gif (could be a known CSS bug related to IE implementation of box model-padding and border added to width) See: http://tantek.com/CSS/Examples/boxmodelhack.html Cheers, -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand
[WSG] Semantic markup for publication titles
SEMANTIC MARKUP FOR PUBLICATION TITLES In print the name of a publication is typically type-set in an oblique or italic font. A similar *visual* effect can be achieved either through the use of: - an italic font-tag iPublication/i (probably deprecated) - an emphasis tag emPublication/em - styling a span span class=pubPublication/span (with companion CSS) As far as I'm aware, none of these methods have anything to recommend them from a semantic perspective. Is there an alternative convention or standards-endorsed markup to communicate that the enclosed text refers to a publication? Elegance preferred (i.e. rather than adding title tags to any of the above options). Cheers, -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantic markup for publication titles
Maybe I'm not fully understanding your question, but what about having a class (call it pub or whatever) and then defining font-style: italic in the CSS? Creating a custom class will yield the desired visual effect, however the class pub has no semantic value. Compare this to text marked-up with a heading tag; h1Heading text/h1 The text enclosed by this standard HTML tag is defined as a heading. Applying a class to the h1, e.g. h1 class=pubPublication title/h1 does not describe the text Publication title as a publication. -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantic markup for publication titles
Title: Re: [WSG] Semantic markup for publication titles CITE: Contains a citation or a reference to other sources So you are not referencing a source, just mentioning a publication. Seems that the intended use is stretched to include marking-up a publication title using the cite tag (when not explicitly referencing content it contains). For example, a title may be provided without the content of a sentence in a bibliography. The first W3C example doesn't help clarify use: As CITEHarry S. Truman/CITE said, Q lang=en-usThe buck stops here./Q The use of cite in this example is at best redundant. Aside from the sentence structure, who said what is not communicated through markup. The q tag even includes a cite attribute. Perhaps something like, q cite="" S. TrumanThe buck stops here./q Would have been more appropriate. (NB: This is not the correct use of the cite attribute as defined by W3C) I'm aware that the core set of tags is somewhat impoverished though, so I'll settle for cite (for now). -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand
Re: [WSG] question - follow, index meta tag
If I have the following on my index page, do I need to repeat it on every page at my site? Doesn't this tag appearing once send the robots forward to all the other pages? meta name=robots content=index, follow / A robots.txt file is a better option for controlling site-wide search engine behavior. http://www.motive.co.nz/glossary/robots.php For a search engine to crawl a site the site must be well-linked, i.e. if a webpage is posted but has no incoming links it won't be 'found' by the spider (unless it is registered separately). (See reference links and additional related glossary terms for more info on search engines, meta tags etc.) -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** 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] question - follow, index meta tag
I know I should read about Robots from the Robot FAQ web site. However, I am a little pressed for time right now. What do I need to web sites to stop Robots reading my web sites I maintain? Thank you. Create a text file and name it 'robots.txt' Paste the following code, save and upload to the root directory of each site you want to ban search engines from indexing: User-agent: * Disallow: / The first line identifies the search engine spiders (user-agents) the directive applies to (all) The second line specifies the directories and files to be excluded, (all-from the root directory) -- Andy Kirkwood | Creative Director MOTIVE | web.design.integrity http://www.motive.co.nz/ ph: +64 4 3 800 800 fx: +64 4 970 9693 mob: 021 369 693 93 Rintoul St, Newtown PO Box 7150, Wellington South, New Zealand ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantic Breadcrumbs
Been following the breadcrumb (BC) discussion, and think it may come
down to defining the *purpose* of the BC. Through a process of
distillation I've arrived at the following conclusions;
The ('correct') semantic markup of a BC should be based on what the
BC primarily 'means'.
There is the distinction between BC as a presentation format
(navigation in a line suggesting a progression from left-to-right)
vs. BC-as-a-transcript (similar to the Back button) of the path the
specific user followed to reach this page.
Finally there is the companion term 'topic path'; often presented as
a breadcrumb, that show the current page in relation to an
information hierarchy or structure (the taxonomy defense).
More thoughts:
http://www.motive.co.nz/glossary/breadcrumb.php
asideSuggestions regarding additional glossary terms we should add
welcome/aside.
--
Andy Kirkwood | Creative Director
MOTIVE | web.design.integrity
http://www.motive.co.nz/
ph: +64 4 3 800 800 fx: +64 4 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
