Re: [WSG] PDFs and other non-html files opening in a new browser window
Carolyn Diaz wrote: My Web team and I are discussing whether or not we should open links to PDFs and other non-html pages in a new window. Someone cited Jakob Nielsen's argument at http://www.useit.com/alertbox/open_new_windows.html as the reason we should open in a new window. (We all work on government Web sites and they are about to release a new set of linking standards.) While Jakob is often right about usability issues, he is absolutely wrong about this. His advise is based on an extremely limited understanding and faulty assumptions about the way PDFs work on many systems. While the problems he cites have been well known issues with old versions of Adobe Acrobat, due to its slowness and defaulting to opening within the browser window in some browsers, that is not the case with all PDF viewers and browsers. Depending on the combination of browser, PDF viewer, and the user's preferences, some open within the same browser window by default, others launch the PDF viewer in a separate tab by default and others launch the PDF viewer as a separate application. If you attempt to force a new window, the many people in the latter case (especially Opera and Firefox users on Mac, for example) will end up with a new blank tab while the PDF opens in the PDF viewer. The best way to deal with the situation is to clearly label the link as being PDF and let the user decide how they wish to proceed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Re: As a web developer do you find the 'HTML5 the mark up language' a useful document?
Steven Faulkner wrote: The the W3C HTML working group is currently debating the usefulness of HTML 5: The Markup Language http://shrinkster.com/13zy vs HTML 5 A vocabulary and associated APIs for HTML and XHTML http://shrinkster.com/13zz as normative documents for web developers to use as a reference point in their work. Just to clarify the purpose of The Markup Spec, and to make the feedback from this discussion more useful, I'd like to provide a little background about the work going on within the WG that affects web developers. There are two other documents being worked on within the HTML WG specifically targeted at web developers. The Web Developer's Guide to HTML 5, which is being drafted by myself, intends to describe the vocabulary and scripting APIs in clear and simple language, without resorting to formal grammars like DTDs or Relax NG schemas, and to explain how to use the language and syntax. The structure is more like a reference guide, rather than step-by-step tutorial. http://dev.w3.org/html5/html-author/ A different type of document was begun recently and is being drafted by Dan Connolly. This document is intended to be more of a step-by-step, cookbook-style guide to writing pages using HTML5, with a big focus on the multimedia aspects. e.g. It will provide things like: * How to embed a video within a page and provide customised controls using the DOM API, * How to indicate the completion status of a web application using a progress bar. * How to markup images with captions * etc. It currently in a very early stage of development and hasn't yet been published as an editors draft and so isn't available to see yet. Although you can review DanC's emails where he has provided an outline. http://lists.w3.org/Archives/Public/public-html/2009Jan/0274.html http://lists.w3.org/Archives/Public/public-html/2009Jan/att-0274/html-writing-ideas.html http://lists.w3.org/Archives/Public/public-html/2009Jan/0308.html On the other hand, HTML5: The Markup Language, which Steve referred to, is a document that describes just the HTML vocabulary and the conforming syntax primarily using Relax NG and incorporating some conformance statements directly from the HTML5 spec. The Relax NG schemas come from the code used by the HTML5 validator, validator.nu. So the document itself, IMHO, seems to be optimised for tool developers that have a real use for such schemas, rather than web developers who just want to be able to know how to write HTML5. http://www.w3.org/html/wg/markup-spec/ Finally, the main HTML5 spec contains the full language spec and implementation details and conformance requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/ As web developers, you'll mostly be interested in the following sections, which are the main ones that deal with the HTML vocabulary and syntax. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#semantics http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing-html-documents Note that the WHATWG and W3C versions of the spec are identical in all the important ways, but the WHATWG has a multipage version that the W3C doesn't. But for those, like me, who like the single page version, we have that too. http://www.whatwg.org/specs/web-apps/current-work/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5
Vlad Alexander (XStandard) wrote: Brad wrote: Omitting the alt attribute as a requirement may have a level of appropriateness for sites like flickr Creating content on the Web that is only accessible by one group of people is never appropriate. That's technically true and even though sites like Flickr certainly should allow users to provide alternate text for their images, the question that still remains is that if allowing the alt attribute to be omitted when users don't provide any good text isn't the right solution, then what is? What should the spec recommend to use in these cases? Whatever the solution(s), there are various different scenarios that should be addressed. (Note that in all of these scenarios, the authoring tools should allow the author to specify alt text. This is just about what to do when the author doesn't.) What should an authoring tool (like Dreamweaver) insert by default when a user adds an image and immediately dismisses the alt text prompt? (It currently omits the attribute unless the user explicitly selects "" or types in some text.) What should wikipedia use by default for images used in articles? (It currently redundantly repeats the image caption in both the alt and title attributes) What should sites like Flickr, Photobucket, Facebook, MySpace, etc. generate and insert? What should forums (e.g. phpBB) or blogs (e.g. Blogger) use? What should an email application insert when a user emails an image to a friend? -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Using target="_blank"
Ryan Lin wrote: With the XHTML Strict DTD, forcing a new window to open for a link via target="_blank" is not a valid semantic method anymore. I myself believe that whether to open in a new or current window should be user decision, not wed designer/developer. If I am using Strict DTD, the only way to achieve opening the new window is through JavaScripts. So what argument should I give to my clients not to use target="_blank" ? If I say that won't validate your page, they won't care. So any non-technical argument that I can give to them? That depends on the point you're trying to argue. Are you trying to argue in favour of using javascript instead of target="" to get a new window, or against the use of new windows in general? For the latter, there are plenty of arguments against using popups and I suggest you search the archives. In particular, I know I have personally refuted ever single argument for popups in the past and don't particularly feel like repeating that again. If, however, you just want to use JS to sneak the popup past the validator, then I think you're wasting your time. If you're using popups, then getting approval from the validator is the least of your worries. There are a wide variety of JS methods you can use to create popups, including these and their variations: 1. Using JS to add target attributes to links 2. 3. Using unobtrusive JS to attach event handlers to links, which call window.open() when activated. Depending on the specific method used, using JS to create popups can cause numerous problems. Of those, #1 is just hiding the target attribute from the validator and basically misses the whole point of why the target attribute was forbidden in the Strict DTD. However, compared with the other 2 alternatives, it is the lesser evil. Using the target attribute (either directly in the markup or adding it with script) is a lot more user friendly than window.open(). Firstly, it is significantly easier for a user to configure their browser to ignore target attributes, than it is to override window.open(). (Personally, I do both, but disabling window.open() has some unfortunate side effects on some sites). The target attribute also allows the browser to notify the user that it will open a new window. Safari, for example, tells the user in the status bar when they hover over the link, and there are various other methods available for other browsers. So the question really comes down to how important validation is to you and how much effort you're willing to put in to get the tick of approval. Although I don't recommend popups if you can avoid them, if you must use them, I recommend just using the target attribute in the markup or, if the validator's tick of approval is really that important, you can accept the fact that you're just lying to it, and if you want to put in the extra effort, then add the target attributes using script. I oppose any method that makes use of window.open(). -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?
Alastair Campbell wrote: On 5/29/07, Nick Fitzsimons <[EMAIL PROTECTED]> wrote: The topic under discussion is, as I mentioned in my earlier post, mentioned in HTML 4.01 at <http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7> as being something with poor support in HTML user agents. Which I read, thank you, but unless I'm being particularly thick (quite possible, it was a long weekend ;), I can't see how that affects terminating characters. Without the SGML spec, what is a NET character? It's just frustrating not to be able to get to the source and find out what these things are. SGML and HTML Explained by Martin Bryan [1] will explain everything you need to know about SGML. In particular, chapter 4 explains the SHORTTAG NET features. Figure 4.4 [2] lists the default delimiter characters from the reference concrete syntax, which includes: / NET Null end-tag That can be set in the SGML declaration, but because it's not explicitly set in HTML4, it uses the default. [1] http://www.is-thought.co.uk/book/ [2] http://www.is-thought.co.uk/book/sgml-4.htm#Fig4-4 -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: self-closing tags in HTML, was: [WSG] A CMS for POSH sites?
Alastair Campbell wrote: On 5/29/07, Rimantas Liubertas <[EMAIL PROTECTED]> wrote: http://www.w3.org/TR/html401/sgml/sgmldecl.html FEATURES, SHORTTAG YES I guess from that I should deduce that I do need to know the SGML spec to know that a slash will terminate a tag? I hope HTML5 does away with this... HTML5 disposes of the myth that HTML is an application of SGML, so you don't need to understand SGML at all. In fact, in HTML5, the trailing slash is explicitly permitted for void elements, though it's not necessary. Void elements (formerly known as empty elements in SGML) are elements like , , , etc. Thus, in HTML5, both and are permitted and mean the same thing. The slash is ignored by the parser. However, the slash is not permitted for non-empty elements. e.g. is not allowed in HTML, though it is in XHTML because XML rules apply. -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE 7 body length problem
Thierry Koblentz wrote:
I don't see this behavior in ie7 WinXP Pro
But I think you should be able to fix what you describe by giving layout
to some element in there.
Did you try: body {zoom:1}
Be very careful about overusing hasLayout. It's not something that
should just be gratuitously used everywhere you think there's a bug,
particularly when you can't actually see a bug. If used carelessly,
hasLayout has the potential to cause more problems than it actually solves.
Hacks should always be a last resort, not something you turn to at the
first sign of a bug. It's always better if you can resolve the issue at
source, instead of throwing random hacks at it until it's patched.
--
Lachlan Hunt
http://lachy.id.au/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] markup for headline and tagline
Paul Novitski wrote: What markup do you favor for a headline-tagline pair? (The second element could be a tagline or a byline.) Thundering Pigs a blog by Bob No, cite is for citations. Thundering Pigs a blog by Bob Yes, I'd use that. -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Valid and well-formed
Katrina wrote: David Hammond suggests that validity is not well-formedness, in that a document can be well-formed and not valid, but could also be !!! valid and not well-formed. http://www.webdevout.net/articles/validity-and-well-formedness#validity_well_formedness That article is actually only talking about the cases where the W3C validator has known XML limitations. Despite the validator claiming the non-well-formed documents are valid, they are not. If you use a validator that makes use of a real XML parser, the documents would not validate. Page Valet has an XML parser available for validation. http://valet.webthing.com/page/ -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Will HTML5 be a purely presentational language?
Laura Carlson wrote: The following may be of interest to web standards folk who haven't been keeping up with the HTML Working Group and where HTML5 is headed: On 4/26/07, Ian Hickson <[EMAIL PROTECTED]> wrote [1]: There are people strongly arguing that HTML should be a purely presentational language, much, much more presentational than the proposed WHATWG draft... [1] http://lists.w3.org/Archives/Public/www-html/2007Apr/0171.html Hixie was probably referring to things like people asking for a new element to replace . Personally, I totally ignored that thread and few people took the idea seriously because the whole idea is nonsense. HTML5 will not be becoming a presentational language, though it also won't be a strictly and purely semantic language either. http://lists.w3.org/Archives/Public/public-html/2007Apr/0391.html -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] commenting javascript in script tags
Andrew Harris wrote: It is common and often recommended practice to comment javascript placed in a document. <!-- myVariable = 'woo'; // --> Don't bother using those comments, they're a waste of time. The reason cited is that 'very old browsers' that do not understand the script tag may print the raw code. How old are we talking? Has anyone ever seen this happen? Can't we safely leave behind what is essentially a hack? Sadly, yes. The browser embedded in a a particular mobile phone (I think it's the Motorolla V3) does not recognise the script element and will render the script on screen if it's not commented out. However, that phone and its browser have far more significant problems and is safe to ignore. Other than that, any browser released since the mid-90's will recognise the script element and hide its content. While I'm on the topic - what about the whole thing? No. That is for use in XHTML only. In HTML, the content of the script element is parsed differently from other markup. See this article of mine for a more detailed explanation. http://lachy.id.au/log/2005/05/script-comments -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] colour matching transparent png files
twe melb wrote: As far as i know png alpha transparency does not work well in IE 5.5 and 6, Correct. it seems to only works in firefox, And IE7, Opera, Safari, etc. i tend to avoid the use of png as it is not cross browser compatible, Nonsense! Aside from alpha transparency problems in IE6 (and earlier), PNG is widely supported. PNG8 supports index transparency, just like GIF, and that is widely supported. Alpha transparency can be used if care is taken to work around the limitations in IE6. i uses gif instead. Don't use GIF, it is inferior to PNG in every way. Animated GIFs are the exception, but they should be used sparingly anyway. -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] namespace attribute and validation
James Ellis wrote: a question about namespace attributes in html/xhtml. I'm looking at methods of conveying information to client side scripts in a neat manner within an HTML document and trying to be valid at the same time. My methods works but the validator complains about namespaced attributes. Method 1: Namespace attributes - works but doesn't validate http://www.w3.org/1999/xhtml"; xmlns:d="http://example.com/data"; xml:lang="en" lang="en"> ... What's the actual problem or use case you are trying to solve by introducing namespaced attributes? Your above description is rather vague. Have you considered that there may be an existing microformats based method to solve your problem? Note: "I want to use namespaced attributes" is neither a problem or a use case, it's a solution; but a solution to what exactly I am unsure. If you can provide more information about the use case or problem, then perhaps someone can offer a better alternative. Method 2: multiple class names a snippet ... foo If you are intending to use this in HTML documents, then that kind of approach would be best. I'd really like to use Method 1 as it's the cleanest and doesn't involve unnecessary Javascript. The specs seem to allude to the fact that you can do this but the validator says no. Does anyone have some ideas about making it validate? That's a limitation of DTDs and DTD based validation. They are simply not expressive enough to describe namespaces properly. The only way you could work around the validation problem would be to write your own DTD, but that would be an exercise in futility. Given that you're using XHTML [1] and because browsers do not use DOCTYPE sniffing for XML content, you could just omit the DOCTYPE entirely and rely on better methods conformance checking and validaiton. [1] I'm assuming by the fact that you think you can use namespaces, you are actually serving your documents as XML, and not text/html. Namespaces cannot be used in documents served as text/html. If you do not understand this MIME type issue, namespaces are most certainly not the solution to your problem. -- Lachlan Hunt http://lachy.id.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Re: Website Directory Structure - Best Practice
Richard Czeiger wrote: For example "Latest Mars News" for NASA, might be better served with havng an index page with a linked archive of static URLs, or permalinks for latest articles (like "/mars/news/060320.html"). I fully agree with what you're saying, but just have one minor issue. Dates in file names should always use 4 digit years (or more after y10k). I'm sure you all remember the y2k bug, let's not suffer again with a y2.1k bug. It's best practice to use ISO-8601 dates (with or without the hyphen), especially in file names and it has the advantage that sorting by name also sorts by date. e.g. /mars/news/2006-03-20 Or maybe: /mars/2006/03/20/article-title -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: Website Directory Structure - Best Practice
Mark Harris wrote: Richard Czeiger wrote: Sorry Vlad - Ithink I'm with Lachlan on this one... Docs can be edited or re-written but if they're obsolete, you don't need to delete them - just don't link to them... Actually, Lachlan said "no URI should be deleted" which everybody has taken to mean "no document left behind" or some such. If a document becomes obsolete, remove it and redirect the URI to a page that notifies the user of the fact and offers a newer version. How many times have you used Google and got a 404 because someone had removed the document you were coming for? And why would you have a document on your site that *wasn't* linked to? Why would you cease linking to it from anywhere, even if it was only linked from some archive pages? Can you in turn suggest a reason why you would retain a document on a site that was unlinked? Because you don't know who else has linked to it from another site or bookmarked it. Of course, if the page no-longer contains any relevant information, it has been superseded by another document with a different URI and is of *no historical value*, then the old one should be removed with a proper redirect to the new one (probably 301 Moved Permanently). But in such cases, you should generally try to reuse existing URIs rather than setting up a new one. There's a good example of this that I think I read in Cool URIs don't Change, where a weather page had ceased to be updated because it had moved to a new URI, but the old one remained without any indication of the new one being present. In that case, they either should have retained the old URI or redirected to the new one. But URI != document, necessarily, and an superseded document may be more dangerous than not finding anything. I agree, but if documents are likely to be superseded by future documents, then they should have some status section that indicates meta data such as the publication date, the permalink of this version and a URI to retrieve the latest version. e.g. Like the specs from the W3C do. This does apply to commercial sites as well. If you need evidence of why this is so important, how many times have you followed a link to an old news article from a few years ago, only to find that it has since been removed? This happened to me recently with a news article on Yahoo news I think. I can't remember what article it was or where I followed the link from, but it was rather annoying not being able to read it. -- Lachlan Hunt http://lachy.id.au/ ** 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] Chinese translations and PHP includes
Adrian O'Hagan wrote: I am using Dreamweaver for this - and you may well be right that it is an editor issue. In Dreamweaver, set the default file encoding to UTF-8 and use Unicode for all files. Avoid using any legacy encodings. Edit > Preferences... (or Dreamweaver > Preferences... on Mac) Select the New Document pane. Set the Default Encoding to UTF-8 Check "Use when opening existing files that don't specify and encoding" Uncheck "Use Unicode Signature (BOM)" - Unfortunately, the BOM causes problems with PHP and other things, so it's safer to not include it. -- Lachlan Hunt http://lachy.id.au/ ** 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] Chinese translations and PHP includes
Adrian O'Hagan wrote: I am embarking on my first multi-lingual site (English, Simplified Chinese and Traditional Chinese). It is to be a static site (no databases) and I have used PHP to take advantage of the server-side includes. Although there's nothing wrong with using PHP, you don't need to for just server-side includes, you can just use SSI. http://httpd.apache.org/docs/1.3/howto/ssi.html http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> Unless you have a specific reason to use XHTML, it is advisable to use HTML 4.01. It is also very advisable to use a Strict DOCTYPE, since the "transitional phase" is over. Use Or, if you insist on XHTML, you *must* declare the xmlns and should use xml:lang as well. http://www.w3.org/1999/xhtml"; xml:lang="zh" lang="zh"> However, it's far easier to just use HTML 4.01 Strict, since XHTML is far too complicated. (When you switch to HTML 4, you must also stop trying to use XML empty element syntax) Using the meta element with an http-equiv attribute set to anything other than Content-Type is completely useless. Using the meta element with an http-equiv attribute set to Content-Type is completely useless for XHTML, you must use real HTTP headers. For HTML, you should use real HTTP headers as the meta element is an inferior substitute. http://lachy.id.au/log/2006/01/content-type Additionally, you should consider using a Unicode encoding such as UTF-8 or UTF-16. AFAIK, PHP does not yet support UTF-16, so that leaves UTF-8 which it can work acceptably with, as long as you avoid the Byte Order Mark. See my 3 part guide to unicode: http://lachy.id.au/log/2004/12/guide-to-unicode-part-1 For PHP, setting HTTP headers is as simple as adding this to the top of the template: My major problem is this: when I save the include, all Chinese characters are rendered as a series of question marks. http://www.digitaldogma.com.au/clients/helprequest/ That either means you have a character encoding issue, which is discussed in my guide to Unicode, or the fonts are not available with those Glyphs on your computer. I suspect it's an encoding issue, but the computer I'm on at the moment probably doesn't have those glyphs either, so I can't be sure. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Forward-slash suppresses word wrap in Windows IE
Thierry Koblentz wrote:
Paul Novitski wrote:
Workarounds: Preceding the slash with a BR tag works, of course, but
I haven't yet found anything else.
Try this:
P.demo2 {word-break:break-all}
Thanks, Thierry, but no go:
... It breaks between characters strictly at the block
width without regard for Latin-style word breaks.
I missed part of the question, I tought you just wanted to break the string,
no matter where...
Another solution would be to use IMG elements in there.
Better yet, use the character U+200B ZERO WIDTH SPACE (though, you'd
need to check browser support)
--
Lachlan Hunt
http://lachy.id.au/
**
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] Re: Website Directory Structure - Best Practice
Vlad Alexander (XStandard) wrote: If you put all images into the "images" folder, it's like putting things into a black hole; things go it but never come out. The problem is just by looking at the files in the "images" folder, you have no idea which documents are referencing them so you are not sure if you can ever delete them. Simple way to handle this: Never delete them! Since "Cool URIs don't change", no document should ever be deleted, and thus any document that does reference the image will still be there and require the image. Even if the document is edited to have the reference removed, it's still good to have it there for historical reasons and so that it may be used again in the future. However, it can be very useful to categorise images into subfolders so that it makes it easier to find and use later. I find dated folders is the most effective way to categorise images, which helps allow the URIs to be maintained perpetually. -- Lachlan Hunt http://lachy.id.au/ ** 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] Certified Usable
Steve Olive wrote: On 20/03/2006, at 2:06 PM, Andreas Boehmer [Addictive Media] wrote: Sydney-based Usability company PTG has made the claim that they can certify the usability of their websites: http://www.usabilitynews.com/news/article3005.asp I quickly validated their page with HTML Tidy (Firefox extension) and the page about "Certified Usable" has 2 errors and 44 warnings for "" That just shows how useless HTML Tidy is as a validator. There are actually many more errors than that. However, the article is talking about *usability*, not validity and their site may indeed be very usable; although I doubt it's very accessible. (after getting past the 100 odd empty lines) with upper and lower case tags. There's nothing wrong with using uppercase tags in HTML, although given that they use an HTML 4 DOCTYPE that triggers quirks mode, an xmlns attribute and XML empty element syntax, they really haven't got a clue what they're doing with markup. -- Lachlan Hunt http://lachy.id.au/ ** 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] IE hacking.
Alastair Steel wrote: We are an open source based software development company who deal mostly with SME businesses. We write mostly to the standards for CSS2 and deploy with Firefox, Mozilla or Safari. Not having to hack everything for IE has meant we can develop faster and cheaper. Do you at least test the sites in IE to make sure they degrade gracefully and are fully accessible and usable, even if it doesn't look perfect? We now have a potential client that, for reasons beyond reason, wants to use IE. If you could find out their reasons for choosing to stay with IE, I'm sure those of us involved with either marketing and/or developing Firefox (or any other browser) could use the information to address their needs better. Of course, it's likely that Firefox does already addresses their needs better than IE does and they just don't know it yet. So my questions are? i/ Is it possible to just look at the CSS which controls the layout of the whole app and just hack that for them. This is preferable as each user has their own language file which calls their language and CSS. Whoever does it would need to see your HTML templates, CSS and any relevant JavaScript that modifies the DOM in ways that affect the rendering. ii/ Or is it necessary to look at each page of the application (over 100) and hack the CSS to make them work? As long as the templates cover all the different kinds of markup and styles used, they won't need to see all pages. iii/ Or worst case scenario are there changes that may be required in the HTML. (I don't see why as everything that is to be displayed in the app is in a DIV and all DIVs are controlled with CSS). There's nothing special about div elements, they're just like almost any other element, except that they have very little default styling. Besides, statements like that make me think you may be suffering from divitis (or div-mania). It may be as simple as using Dean Edwards' IE7 script or it may be as complex as doing a complete CSS overhaul. However it's done, I'd recommend you just use a conditional comment rather than modifying the existing style sheets that alread work for other browsers. iv/ If we go to all the trouble for IE 6 will it all work in IE7. Or is this going to be a separate hack. There's no guarantee that anything will work in IE7 until the site has been tested in it. It may or may not require additional hacks. It's entirely possible that IE7 won't require any hacks for the site to work, but you won't know until it's been tested. (AFAIK, the first IE7 preview that isn't a complete joke will be released in a couple of days after MIX 06.) I also need to work out the approximate costs of all the above so we can pass it on to the client. That depends on how much work is required, which depends on how bad it looks in IE and how good or bad the existing markup and CSS is to work with. I suspect that whoever offers to take on this work will need to see it before they can give such a quote. -- Lachlan Hunt http://lachy.id.au/ ** 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] Website Directory Structure - Best Practice
Lea de Groot wrote: * the page-name.some-technology, in implimentation. I tend to end all my pages in html no matter what I am using server side because a) it says 'webpage' and Then it adds 5 unnecessary characters to the end of the URI that serve no real purpose. I don't like including the file extension on any URI at all and if it wasn't for the annoying IE caching bugs I've experienced when leaving extensions of images, CSS and JS (i.e. IE apparently won't cache the files at all), I wouldn't include those either. It's also annoying when changing implementation. Like when I switched from blogger to WordPress. Blogger used static .html files and gave no way to configure links to be written without file extensions, even though I had MultiViews turned on. WordPress stores everything in the DB and has no file extensions in URIs. I ended up having to use mod_rewrite to accept .html on the end of any article URI so that no existing links/bookmarks wouldn't break. It would have been much less hassle if blogger had let me turn off file extensions in the first place. b) the technology for turning extensions off is flakey and What's flaky about it? Apache MultiViews is the easiest way to not require file extensions for static files, with the added advantage of making content negotiation extremely easy to do. I find putting a single page per directory inefficient in workflow - it has to work on both the developers and the users side! Yes, I agree with that. -- Lachlan Hunt http://lachy.id.au/ ** 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] Website Directory Structure - Best Practice
Joseph R. B. Taylor wrote: root web folder -images For images, styles and scripts these days I recommend using /images/ /style/ /script/ When I initially built my own site, I put all of these under a /lib/ directory. That can never be changed now, but on new sites I don't bother with that. For images, I now use dated sub folders (just by year) for any images used in my blog articles. That just keeps the number of images in one directory to a minimum, which makes them easier to manage. Other images used in stylesheets or other general places throughout the site either go straight in the images directory or into subdirectories by category. -main.htm It's conventional to use index.* (.* represents any file extension you need) as the main index file on most web servers (IIS uses default.*) so that you don't need to include it in the URI. You can configure it in your .htaccess file to main.htm, but why bother when it's easier to just use index.* That way the URI just needs to be: http://example.com/ instead of http://example.com/main.htm (It works the same for any subdirectories as well) -events.htm -bio.htm Those are fine, but you should avoid including the file extension in the URI so that if you ever change the implementation from static HTML to JSP, PHP, ASP or whatever, the URI doesn't need to change just because the file extension does and then there's no need to set up redirects (which people often forget to do anyway). If you're using Apache, turning on MultiViews is the easiest way to do that. Recently I was hired to do some cleanup on a site I hadn't built and the directory was set up like: [snip - directory structure] Generally, you should try to avoid moving too much around, if anything at all, because doing so will end up changing URIs and that breaks bookmarks, links, etc. If you do have to, make sure you set up appropriate redirects (using HTTP headers, never use refresh) -- Lachlan Hunt http://lachy.id.au/ ** 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] tabindex
Designer wrote: In an endeavor to 'be good', I've been putting tabindex on links just lately. Certainly the WAI validator gives me a warning if I don't. Just ignore such useless warnings, tabindex can do more harm than good if used without a lot of care and it's mostly useless because there are few cases where tabbing through in document order isn't sufficient. As it happens, the default taborder is the correct (desired) one anyway Exactly why you shouldn't use it. And what's the current thinking on accesskey? accesskey is far worse than tabindex and many accessibility experts will tell you to never use it. http://www.wats.ca/resources/accesskeysandkeystrokes/38 -- Lachlan Hunt http://lachy.id.au/ ** 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] Validating and validators
Kat wrote: For a good while now I have been using A Real Validator to validate my html offline. That's good. 1. What are your opinions of SGML-parsers vs linters? Do both have their place? Do they have different roles? SGML parsers will tell you exactly what's wrong with your document according to the formal definition in the SGML declaration and the document's DTD and is the best choice for HTML documents. SGML based validators for XML documents may have limitations (including any based on OpenSP, such as the W3C/WDG validators and A Real Validator). Most, if not all, of these limitations relate to well-formedness errors which will be picked up by a browser when you use an XML MIME type anyway. In general, lints are mostly quite useless for validation and they often lie. Though some, like HTML tidy (which is one of the most useless tools for validation, IMHO), is still reasonably good at cleaning up really messy documents so that they can at least be worked with. 2. Is Validome an SGML parser or linter? It's a lint. 3. How accurate do you believe is Validome's statement of errors? http://www.validome.org/lang/en/errors/ALL XML Declaration: All the errors not caught by the W3C validator are limitations with its XML support, but all of which are well formedness errors that will be caught by any decent browser when you use the correct MIME type. Error in the Document Type Declaration: All of the following are not caught by true SGML based validators, but that's because none of them are actually errors. Any validator that chooses to raise these issues should call them warnings, not errors. * System-ID missing (at PUBLIC) in HTML-Document * Missing White Space between Public-ID and System-ID * Upper and lower case at HTML-Documents * Document Type Declaration in commentary area * Unallowed overwriting of parameter entities * HTML-Document with user-defined DTD * HTML-Document with unknown Public-ID and user-defined DTD I don't have time to go through the rest right now, I may do so later. 4. What is the most successful way in ensuring correct and valid html and or xhtml (considering different validators have different errors)? For HTML: Use a real SGML based validator. In general, I prefer the W3C validator, but the WDG validator's additional warnings that are not emitted by the W3C validator can be useful for making documents more compatible with real browsers. e.g. it will give warnings about SHORTTAG NET usage (often just a result of XML syntax in an HTML document). For XHTML: Make sure you develop and test the page using the correct MIME type. That will catch any well-formedness errors immediately (including those not caught by the SGML validators). Generally speaking, a validator that uses a real XML parser would be best, though the W3C/WDG validators are still very good, especially if you've already ensured against well-formedness that they won't catch. The W3C/WDG validators will also give some useful warnings that a real XML parser won't, such as reference to a "non-SGML character". That's very useful for detecting common mistakes like ’ instead of ’. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: Encoding test page
Keryx webb wrote: xml-prologue The XML Prologue is the section of the document that contains the XML Declaration, DOCTYPE and any comments or PIs prior to the root element. The XML Declaration on the other hand, or (more specifically) the encoding declaration within the XML declaration, is the special construct that specifies the encoding and is what you're referring to. Please try to get the terminology correct in future. If a page is sent as XHTML, one could argue that it's supposed to be self-documenting, and that it might mean that the xml-prologue should be more important than the http-header. See the Architecture of the WWW rec: http://www.w3.org/TR/2004/REC-webarch-20041215/#xml-media-types Information supplied at the protocol level always takes precedence over anything specified in the file itself. Therefore the HTTP Content-Type header takes precedence over the XML declaration. The precedence rules work like this for the following MIME types: For application/xml, other application/*+xml and application/xml-external-parsed-entity: 1. charset parameter in the Content-Type header 2. BOM 3. The XML declaration 4. UTF-8 The meta element is never used for determining the encoding. For external parsed entities, it uses the Text Declaration instead of the XML declaration. They're similar, but not exactly the same. For text/xml and text/external-parsed-entity: 1. charset parameter in the Content-Type header 2. US-ASCII The XML declaration and Text declaration is ignored. For text/html: a) According to the spec: 1. charset parameter in the Content-Type header 2. Meta element 3. charset attribute on the link followed to the page. b) Actual browser implementation is a little unclear at this stage, it's not really well defined. Here's a rough overview anyway: 1. charset parameter in the Content-Type header 2. BOM 3. Meta element 4. Unspecified heuristics (guessing) 5. Default (according to browser pref, which is usually ISO-8859-1 or Windows-1252) I'm not sure if any UAs actually support the charset attribute for links at all. -- Lachlan Hunt http://lachy.id.au/ ** 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 Form - Person's Title
Lachlan Hunt wrote: Micky Mourelo wrote: The legend is a required child of fieldset. Specwise the DTD seems to say it is optional, Looks like it's required to me... and the validator agrees. I'd like to see your test case that demonstrates that. I forgot that this is one of those undocumented changes (i.e. not listed in section 4) between HTML 4 and XHTML 1: So, technically, yes it's optional in XHTML 1. -- Lachlan Hunt http://lachy.id.au/ ** 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 Form - Person's Title
Micky Mourelo wrote: You don't need to set the for and id attributes when the input is within the label because the association is implicit. Not on IE. IE won't make the label clickable unless it is associated through "for". Of course not in IE, but IE is broken and I consider that acceptable graceful degradation. The legend is a required child of fieldset. Specwise the DTD seems to say it is optional, Really? Let's see: Looks like it's required to me and it's the same in both Strict and Transitional DTDs. and the validator agrees. I'd like to see your test case that demonstrates that. -- Lachlan Hunt http://lachy.id.au/ ** 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 Form - Person's Title
Micky Mourelo wrote: ... You don't need to set the for and id attributes when the input is within the label because the association is implicit. In this case you would set the labels to inline. But in reality I would recommend either forgetting about the legend The legend is a required child of fieldset. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: Encoding test page
Andrew Cunningham wrote: Lachlan Hunt writes: Andrew Cunningham wrote: In theory the docuemnt should only be in one of the unicode encodings, so without a BOM, the browser should try to render it as UTF-8. No, because when it's served as text/html, HTML rules apply, not XML rules. So without the encoding declared in the HTTP headers or the meta element, the default of ISO-8859-1 should be used (if served over HTTP, technically US-ASCII otherwise). However, browsers will actually interpret ISO-8859-1 as the Windows-1252 superset and will also attempt to use unspecified heuristics to guess the encoding, before falling back to the default. If you're going by the HTTP specs. Yes, of course, as well as the relevant RFCs for the MIME types. If you go by the XHTML 1.0 recomendation, appendic C Appendix C is non-normative. would indicate that "... that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.: That is only true for XML on the condition that the encoding has not been specified by a higher level protocol. The relevant *normative* section of the XML rec. states in 4.3.3 Character Encoding in Entities: In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration. http://www.w3.org/TR/REC-xml/#charencoding The point I wnated to make is that there is another way to declare encoding for docuemnts in UTF-16 or UTF-32: and thats teh BOM; and that the test should also include BOM detection as an option, Not according to the HTML 4 Rec, but... i.e. do various web browsers use the BOM as part of their heuristics. In reality, yes. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: Encoding test page
Andrew Cunningham wrote: I was wondering if you should have another test in there: XHTML document with no encoding declared in the http header or in a meta tag, and no xml declaration. Sent as html/text. That's text/html and an XHTML document served as text/html is HTML, regardless of any lies the DOCTYPE tells you. In theory the docuemnt should only be in one of the unicode encodings, so without a BOM, the browser should try to render it as UTF-8. No, because when it's served as text/html, HTML rules apply, not XML rules. So without the encoding declared in the HTTP headers or the meta element, the default of ISO-8859-1 should be used (if served over HTTP, technically US-ASCII otherwise). However, browsers will actually interpret ISO-8859-1 as the Windows-1252 superset and will also attempt to use unspecified heuristics to guess the encoding, before falling back to the default. -- Lachlan Hunt http://lachy.id.au/ ** 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] broken sprite - very odd ie6 thing
Ted Drake wrote: I love using sprites, but I've never seen this happen before. I've got a sprite that looks like this [snip - useless ASCII art diagrams] I think you'll find someone may actually be able to help you if you provide a link to a sample document (preferably a minimal test case) demonstrating the problem. Besides, if you create a minimal test case (i.e. a document with the minimal amount of code possible to replicate the problem) you may even be able to solve it yourself. -- Lachlan Hunt http://lachy.id.au/ ** 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] Absolute Positioning-A Naive Question (Maybe)
Paula Petrik wrote: When I read the W3C specs (not the most riveting exercise on the planet), it seems that the developers emphasize absolute positioning. For example, they describe using floats to float small bits of text or images. It seems, however, that floats have become the order of the day. Rather than small bits, whole parts of designs are floated about. Was this the W3C's intent? Or, have floats become the modern equivalent of tables? http://dbaron.org/log/2005-12#e20051228a Is there some reason why absolute positioning has fallen by the wayside? There are significant limitations with the use of absolute positioning such as the inability to create equal height columns and allow any column to have the longest content, which is one of the most common abuses of floats. There are better approaches to layout being developed by the W3C, but they're still a very long way off from implementation. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: uppercase CSS and XHTML
Designer wrote: Lachlan Hunt wrote: Designer wrote: Incidentally, I would be interested in any browsers you know which won't support application/xhtml+xml, apart from IE of course. http://www.w3.org/People/mimasa/test/xhtml/media-types/results Thanks, Lachlan. I studied the list, and the only failing browsers I saw were Opera prior to v7.10 (in some versions the type selector in style sheets matched case-insensitively) Amaya (well surely Amaya users are the type to upgrade to later versions, which are OK) and iCAB, the latter's only problem being the style sheet case mentioned above. So, as far as I can see, if you have all your style sheets in lower case, the only problem is IE. If so, the selective feeding to IE should be fine. Does anyone know why this wouldn't be the case? If not, is this a new 'hack'? No, because of the case sensitivity bug several browsers have (especially iCab) and the other reasons I mentioned before regarding browser Accept headers which would result in those browsers receiving HTML, not XHTML, and that would include users that have modified their browser's Accept header. A browser's Accept header and its support for XHTML cannot be used as an indication of its CSS abilities. In Firefox, this can be set with the pref network.http.accept.default and some users may have modified it to prefer HTML because of its inability to incrementally render XHTML. iCab's accept header by default contains this: text/html;q=0.9,application/xhtml+xml;q=0.7 Safari's accept header contains just */*. If you were using Apache Multiviews (which selects files based on the file extension and chooses the files alphabetically in the event that checking all other criteria didn't result in a single preference) then the .html file would be chosen over the .xhtml file. Simply changing the file extensions to put the XHTML file alphabetically before HTML is not an option because then IE users would also receive the XHTML file. Also keep in mind that that list is not a complete list of every browser, there may be others that don't support XHTML, do support stylesheets and are still in use by some people. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: uppercase CSS and XHTML
Designer wrote: Incidentally, I would be interested in any browsers you know which won't support application/xhtml+xml, apart from IE of course. http://www.w3.org/People/mimasa/test/xhtml/media-types/results -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: uppercase CSS and XHTML
Designer wrote:
Lachlan Hunt wrote:
No, it will not work under XHTML at all. The DOCTYPE is irrelevant,
XHTML is case sensitive and uppercase element selectors will not match
anything in XHTML. It will only work for text/html.
OH Dear, I'm getting confused again!
When I read the above, I thought "ah - here's a fine way to feed IE only
stuff perhaps",
That's a bad idea because IE is not the only browser that doesn't
support application/xhtml+xml and some browsers actually prefer
text/html according to their Accept headers. So if your content
negotiation was done correctly, such browsers would also get the
text/html variant and, thus, your IE only styles.
so I did a simple experiment using the php generated
headers trick mentioned by joshua [2]. I put the CSS as:
#container {width : 400px; margin : 0 auto;}
#content {padding : 25px}
#CONTAINER {WIDTH : 700PX;}
Those are ID selectors, not type (or element) selectors. See my
previous post for a discussion of why that doesn't match.
If you did want to use this technique, though I don't recommend it, you
could use this instead:
#container { /* (X)HTML styles */ }
HTML #container { /* text/html only styles */ }
Note: that won't work if your non-conformant XHTML root element is:
http://www.w3.org/1999/xhtml";>
...
--
Lachlan Hunt
http://lachy.id.au/
**
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] CAPS in stylesheets
Jason Turnbull wrote: I was a bit unsure too as I thought the term 'selectors' in style sheets referred too all tags, ids & classes, Selectors are patterns that match against elements in a tree. They include the universal selector, type selectors, class selectors, ID selectors, attribute selectors, pseudo-classes and pseudo-elements talking about uppercase tags in CSS (h1, p ect) They are not "tags", they are *type selectors* which match an element based on its type (or tag name). From what I tested and according the link Philippe posted uppercase identifiers are ok Yes and no. It is perfectly acceptable to write type selectors, ID selectors and class selectors, etc. in upper case; but whether or not they match anything in the document depends on the case sensitivity of the markup language. Thus, all of the following are valid selectors: P /* Matches an element of type P */ .FOO /* Matches an element whose class is "FOO" */ #BAR /* Matches an element whose ID is "BAR" */ In an HTML document, tag names are case insensitive and so P will match either of the following; whereas in XHTML, tag names are case sensitive and so will only match the element with the upper case tag name: However, all elements in XHTML are defined as lower case and so the uppercase is an undefined element. Thus if a document included the uppercase tag-name, the document would be invalid but the uppercase type selector would still match it. According to the HTML4 Recommendation and browser implementations (but, technically, not according to the rules specified by SGML and expressed in DTD) id attribute values are case sensitive and since XHTML is all case sensitive, #BAR will match: but it will not match: Class attribute values are also case sensitive in both HTML and XHTML and so .FOO will match: but it will not match: -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: innerHTML
Joshua Street wrote:
On 3/13/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Joshua Street wrote:
any elements in the inserted content _aren't_ created as
elements, and hence cannot be manipulated at all.
Um... What the? Of course they are created as elements,
They're "created", but, as I understood it, doesn't exist as part of
the document tree. (Which generally isn't any great problem if you've
decided to use innerHTML anyway!) That is, you can't use the DOM
methods to manipulate the nodes within that innerHTML fragment, even
if you've put IDs into the rendered source.
Sure you can, there's no reason why one shouldn't be able to.
Testing innerHTML
var foo = document.getElementById("foo");
foo.innerHTML = "<em id=\"bar\"><\/em>";
var bar = document.getElementById("bar");
bar.appendChild(document.createTextNode("PASS"));
There may be bugs that prevent some things from working correctly, but
such things are just bugs, not restrictions on the feature itself.
--
Lachlan Hunt
http://lachy.id.au/
**
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: innerHTML (was: Re: [WSG] CAPS in stylesheets)
Joshua Street wrote: On 3/13/06, Jay Gilmore <[EMAIL PROTECTED]> wrote: I have also read (no personal first hand knowledge) that there can be issues between using DOM/DHTML scripts and XHTML. I don't know what these issues are but why invite trouble. This arises from non-DOM methods, which are often much simpler to implement (and faster in terms of performance), such as innerHTML [1] (and document.write, but we won't go there). I *think* this is because innerHTML/outerHTML/document.write and their kin leave the XML tree alone -- any elements in the inserted content _aren't_ created as elements, and hence cannot be manipulated at all. Um... What the? Of course they are created as elements, or at least they should be, unless you're talking about some strange IE bug I'm not aware of. (I never use innerHTML so I'm not aware of all of its quirks.) AIUI, the way innerHTML is supposed to work is that the value is parsed as HTML or XML (depending on whether the document is HTML or XHTML; which is determined by the MIME type, not the DOCTYPE) and a DOM DocumentFragment is created. If it's XHTML, it should result in an error when the value is not well formed. Mozilla does this, but Opera doesn't because it always parses it as HTML. I'm not sure about other browsers. All children of the element are then removed from the tree and the new DocumentFragment is appended. I believe Mozilla internally uses its proprietary range.createContextualFrament() function to do this. (That aside, I don't really see anything wrong with this [innerHTML] -- we must remember that XMLHttpRequest object is also proprietary!) The problem is not that it's proprietary, there is actually work to get it standardised as part of the WHATWG's Web Apps proposal. The problem I have with it is that it's working with strings to manipulate the DOM, and those strings need to have escaped characters which get's quite messy, much like document.write(), but not quite as bad [1]. For instance, just to write one simple element with an attribute, it needs to be like this: ... foo.innerHTML = "<p class=\"bar\">text<\/p>" ... My other problem with it is that it's specific to (X)HTML, not any generic XML like the rest of the DOM API is (except for, of course, DOM 2 HTML). IMHO, Mozilla's createContextualFragment() is much more useful for any DOM and I would like it to be standardised, but I don't see that happening any time soon. A much better alternative is to use E4X which is specially designed to make working with XML very easy, as XML is a native data structure, but support is currently too limited for real world usage. [1] document.write() is bad because of the way it throws more markup back to the parser during parsing which means instead of having a nice flow like this: input --> parser --> tree constructor --> output (DOM) document.write() makes it more like this: input --> parser --> tree constructor --> output (DOM) ^| |___doc.write()__| -- Lachlan Hunt http://lachy.id.au/ ** 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] CAPS in stylesheets
Joshua Street wrote: (with the exception of our esteemed friend Internet Explorer, which doesn't even attempt to render pages served as anything other than text/html). ...or text/plain. But that's another can of worms :-) -- Lachlan Hunt http://lachy.id.au/ ** 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] CAPS in stylesheets
sime wrote: No, it will not work under XHTML at all. The DOCTYPE is irrelevant, XHTML is case sensitive and uppercase element selectors will not match anything in XHTML. It will only work for text/html. I have never had a problem with the uppercase not working in strict. Maybe I'm not defining strict correctly. Here is a test page which works in FF,IE6: http://urbits.com/_/test.php Add this function call to the top of your PHP file: -- Lachlan Hunt http://lachy.id.au/ ** 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] CAPS in stylesheets
sime wrote: Christian Montoya HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you must write your CSS selectors in lowercase. So that would make HTML4 practically redundant for new web sites? What? I don't understand how you came to that conclusion. To Lea de Groot: It worked in Strict which is why I've been misled for so long. If you're talking about XHTML 1.0 Strict, then it will only work if you're using the wrong MIME type: text/html. Serve your page as application/xhtml+xml and I doubt it will work. -- Lachlan Hunt http://lachy.id.au/ ** 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] Re: digest for wsg@webstandardsgroup.org
Lea de Groot wrote: sime wrote: However, I'm told that my code is therefore not XHTML compliant because of my use of uppercase. So who then is HTML4 relevant to? I don't really understand the question. As written, the css shown will work under HTML dtds (and XHTML transitional? I'm not sure as I never use it) but not XHTML strict DTDs. No, it will not work under XHTML at all. The DOCTYPE is irrelevant, XHTML is case sensitive and uppercase element selectors will not match anything in XHTML. It will only work for text/html. To make it work correctly for XHTML strict, you should change each tag name to lowercase. Its a trivial change. There's little point for authors to use that stylesheet, it is intended as a guide for browser implementors and was supposedly based on the default styles applied by browsers at the time. (Although there are still many differences between that stylesheet and real world browsers) -- Lachlan Hunt http://lachy.id.au/ ** 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] Some studies about web standards usage (sites of Estonia and W3C members)
Rene Saarsoo wrote: http://triin.net/2006/03/05/Validating_sites_of_W3C_members This article states: | Character encodings | | 111 pages had no encoding specified in HTML. Of course not a | requirement, but belongs to a good style. Wrong. It is a requirement to specify the character encoding correctly. It would be useful if your statistics indicated not only what encodings were used, but whether they were specified in HTTP headers, the meta element, the XML declaration or a combination of them, incl. how many did so for each MIME type and how many had conflicting values. Regarding the list of DOCTYPEs, it would be useful if you indicated which HTML ones included the System Identifier so that it is possible to determine which ones trigger standards mode, almost standards mode or quirks mode. For example, in Mozilla, HTML 4.01 Transitional will trigger quirks mode without the SI and almost standards mode with the SI. -- Lachlan Hunt http://lachy.id.au/ ** 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] page break when printing
Jack Pivac wrote: on 10/03/06 13:56 Lachlan Hunt said the following: I have a page with about 20-30 div's each about 200-300px height. With that many, you may be overusing/abusing the div element. [...] You should probably try and find more semantic elements. So in this case http://temp.delphinus.co.nz/tab/test.html In that case, the look acceptable, the rest don't. Although besides the divs, there are some other things I'd be more concerned about. Firstly, the page doesn't have a DOCTYPE so it doesn't validate. Using the DOCTYPE override on the validator, it will validate as HTML 4.01 Strict, but it's not really conformant and there are other issues. From the source of that page: Alex11223 That should probably be an . Lose the . 12345677 - Office 01234567 - RSO Dial "right" is a presentational class name, perhaps "phone-numbers" (or whatever they are) would be a better alternative. It also looks like it's a list of phone numbers, so mark it up as a list. 12345677 - Office 01234567 - RSO Dial Last PM in August 2005 What's the extra for? This div would probably be better replaced with a element and lose the style attribute, since it's presentational. Last PM in Augus 2005 Joe Blogs 7-13 House st XHTML syntax in HTML document. It will validate but its meaning in HTML is different from that in XHTML, although browsers don't support it. Alexandra This whole address would be better marked up with a element, perhaps given an appropriate class attribute, and remove the 2 extraneous elements from the end. (use of would be wrong) Joe Blogs 7-13 House st Alexandra DDI - 1/11 LN/Group - 3111/1 UGEN# - 1 Office ID - omgofc This looks like a list () or maybe a definition list. According to the spec and the HTML 4 DTD, that border attribute is shorthand for frame="border". However, browsers will incorrectly treat it as border="1". That is why the page validates, but it doesn't mean what you thought. Both are also presentational attributes and would be best replaced with CSS. Terminal1Terminal2OFCPrinter This could be marked up within a element and the s replaced with . CM0111CM0111CM0111CM0111 The rest of this table looks fine. Rarely Used Spares - 211 Not Used Spares - 0 Looks like another list; or at the very least a . -- Lachlan Hunt http://lachy.id.au/ ** 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] page break when printing
Jack Pivac wrote: I have a page with about 20-30 div's each about 200-300px height. With that many, you may be overusing/abusing the div element. It's a common mistake, often referred to as "div-mania" (or something along those lines). You should probably try and find more semantic elements. Unfortunately when printing they sometimes get divided between 2 pages... is there any way round this? http://www.w3.org/TR/CSS21/page.html#propdef-page-break-inside -- Lachlan Hunt http://lachy.id.au/ ** 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] IE Reverse Indent ?
Kevin Ross wrote: On the topic of the IE6 specific rules... ... is there a way to put that whole section in my Style sheet file? The conditional comment needs to go within the HTML, since it is an HTML comment. There are no conditional comments in CSS. You could place it in an include file of some sort, which gets included in every file. For that, you could use SSI or, if you're using PHP, ASP, JSP, or something like that, you can use their own include functionality. -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Thierry Koblentz wrote:
I think it worth mentioning that the * html hack works in IE *Mac* too.
I forgot about this earlier, but that's the reason for the comment hack
to hide from IE5/Mac.
/*\*/ * html { ... } /**/
--
Lachlan Hunt
http://lachy.id.au/
**
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] tags
Nick Lazar wrote: Can anyone tell me what the current state of play is with the tags & XHTML? You only need to write in XHTML or, if you need to be compatible with Appendix C, . If you use HTML instead, then you only need . They seem to be the answer for a particular design I'm working on, and they don't appear to be marked for deprecation. It may or may not be the best solution, but we can't really advise on the situation unless you explain the use case. Many common uses of HR would actually be better done with a top or bottom border, but there are still many valid use cases for HRs. Are there any compelling reasons not to use them? (Apart from them being empty tags). Why would the fact that it's an empty element be a reason not to use it? -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Thierry Koblentz wrote: I think it worth mentioning that the * html hack works in IE *Mac* too. What about conditional comments? I don't think that really matters much anyway, since IE Mac is officially obsolete (i.e. now completely unsupported by Microsoft) and I think some unwanted hacks applying to it would be the least of its problems. -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Paul Novitski wrote:
My point was simply that IE's conditional comments -- and ugly they are,
no argument there -- are more likely to work as intended in a few years
than hacks like * html.
* html hacks will continue to work in IE6 forever, just as they do
today. We already know this filter has been fixed in IE7 (standards
mode), and so the following are exactly equivalent:
* html foo { ... }
(In the case of IE7 quirks mode, * html will still apply whereas the
conditional comment would not. In fact, since IE7 quirks mode will be
very close to IE6 quirks mode, * html would be better because it would
be very likely that the patch will still be required.)
So, any argument that stating that conditional comments are more future
proof is a myth. In fact, if you're not careful with conditional
comments, they can be more dangerous. Consider the following:
* html #content { height: 1%; }
The * html hack will only apply to IE 6 and earlier. That particular
conditional comment will apply to all versions of IE since IE5 (when
conditional comments were first added).
If IE7 fixes the limitation from IE6, I'm sure you would agree that the
patch should not apply to IE7 and, therefore, the use of a filter which
does not apply to IE7 is the better option.
The most effective future proofing method we have is to ensure that any
hacks we do use today do not inadvertently target any future browser.
It is better for future browsers to receive fully standards compliant
CSS, then for them to apply patches intended for and only tested in
current browsers.
If the fate of * html was not yet known then I would agree that
conditional comments with a version number specified are safer, but
since we do know that * html is equivalent to [if lte IE 6], both are
completely safe.
--
Lachlan Hunt
http://lachy.id.au/
**
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] Styling Fieldset and Legend Elements
Seona Bellamy wrote: On 07/03/06, Darren West <[EMAIL PROTECTED]> wrote: I would advise against * html hacks though - http://www.webstandards.org/buzz/archive/2005_12.html#a000598 I tend to disagree with such nonsense. * html is a completely safe filter to use now that we know IE7 will not be supporting it in standards mode. Therefore, for any IE6-and-earlier only hack, it is perfectly safe to use it. IE 7 will then receive the same styles as all other browsers. If it turns out that the limitation is still present in IE7, the filter will need to be modified to target IE7 as well, but until we know for certain whether it is or not, we cannot safely target IE7. Put it in a conditional comment instead. Then you can even target IE6 specifically, and everyone's happy. :) I have already used a conditional comment in this particular site because few hacks I had used were still required in IE7b2, but that was before I realised that IE7b2 was nothing more than a joke and I probably shouldn't have bothered with it. -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Al Kendall wrote: The attached pic is a screen shoot from IE 6. Firefox 1.5 was fine Yes, I know. I think you misread my e-mail. I knew it was broken in IE6, I'm looking for a way to fix it. Any ideas? -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Philippe Wittenbergh wrote: http://lachy.id.au/dev/2006/03/fieldset On OS X 10.4.5 Firefox 1.5, Camino - latest nightly trunk build, iCab 3.0, Safari 2.03 and WebKit nightly build, Opera 9 tp2, all look the same. and so does Konqueror/KDE 3.5 running on top of OS X . Great! But I still need a solution to fix it in IE6. IE 5.2 Mac has a small 1px white border around the legend, barely visible given your light background-color. There is also some white-space under the legend (padding on fieldset, you won't get rid of it). That's acceptable, IE/Mac is obsolete now anyway, so as long as the page is readable, I'm not concerned. -- Lachlan Hunt http://lachy.id.au/ ** 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] Styling Fieldset and Legend Elements
Hi, I'm looking for a way to style a legend element with a background that spans the whole width of the page. I originally used a regular heading (h3) because I knew the design would have difficulty with fieldset/legend, but the after the accessibility review it was requested that we use fieldset/legend anyway and I need to get the design as close as possible. By default, legends are only as wide as they need to be to fit the text and there seems to be little one can do about this in current browsers. I came up with one solution using a thick top border on the fieldset behind the legend element which works in Firefox, but it doesn't quite work in IE because it leaves a small white gap between the legend and fieldset border. I currently don't have access to any other browsers for testing, but I'd like it to work fairly well in at least all major browsers. The following test case demonstrates how I want it to look and my current solution that works in Firefox. Both examples in the page should look roughly identical http://lachy.id.au/dev/2006/03/fieldset -- Lachlan Hunt http://lachy.id.au/ ** 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 of CSS specificity
Barrie North wrote: I need some help, what is the difference between: table.module Specificity: 0,0,1,1 and .module Specificity: 0,0,1,0 Is table.module just more specific or is there more going on? The former will only select tables with the class name "module". The latter will select any element with the class name "module". e.g. They will all be selected by .module, but only the table will be selected by table.module Similar question between: a.contentpagetitle:link Specificity: 0,0,2,1 That will select link and .contentpagetitle a:link Specificity is the same, but will select differently: link (The element could be any ancestor element) -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Felix Miata wrote:
On 06/02/20 06:32 Lachlan Hunt apparently typed:
[someone else] wrote:
Or better: Is there a way to please both groups?
Yes. Don't use small fonts.
Don't blame me, I wasn't the designer, just the implementer so I had to.
But I also wrote somewhere else in that thread that I wouldn't go
below 'small' for main content and that's exactly what it is.
On 06/03/02 10:31 Lachlan Hunt apparently typed:
http://edentiti.com/create/
[1] http://edentiti.com/
http://edentiti.com/style/design.css has '#container {...font-size:
small;}', which makes for a _lot_ of small P text.
Issue #2:
http://juicystudio.com/services/colourcontrast.php tells me 'strong
strong { color: #F90}' on white is inadequate color difference and
brightness, and #069 on white just barely makes it.
I'll let the designer know.
Issue #3:
http://mrmazda.no-ip.com/SS/lachh1.jpg
Even at 1280x960 w/ my 20px default there the text for the left images
is obviously not landing where you want. Seems like simple images like
those you could grow with text size to keep things in place.
I'll look into this problem later.
Thanks.
--
Lachlan Hunt
http://lachy.id.au/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Site Check/Launch: Edentiti.com
Kim Kruse wrote: Hi Lachlan, Just a design opinion... Ok, I'll pass it on to the designers. The main area (#main) looks a little "squeezed" between the rather heavy right and left sides. Maybe make the h2 bigger and I know. It worked better when there was less introductory text on the homepage. make the intro below strong. (It is, but double strong!!... important text (styled in blue) very important text (styled in orange) It was the most semantically correct way I could find to markup the different levels of importance. There's are other combinations of nested aswell (see the stylesheet). I don't know if that's why it doesn't come up as strong on my screen (W2K/FF 1.5). Not sure what you mean by that. Also the #main text is not the same size on all pages! It's only different on the homepage (by design), everything else is the same. IMO the text would stand out more if you used the darker blue from the logo instead of the paleish blue you use right now. Ok, I'll let the designer know. If the text is increased the text in the boxes on the left side "drops out" of the bg img. Maybe Thierrys TIP would work nice here? What's Thierrys TIP? Besides that I looks great... and I'm crazy over the form validation. Looks awesome. Thanks. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Joseph R. B. Taylor wrote: Only thing I noticed is that the subpages' text size appears a bit different than the homepage text. You may want to go with one size throughout the site for consistency. That was the designers' decision. Like the difference with the logo positioning, it was decided that the home page should have a larger and different colour text. It was originally designed with less text (about 1/3 of the current amount) on the homepage and looked ok with it, but now there's more I'd tend to agree it should just use the same as the rest, but it's not my decision. I'll be passing on all of this feedback to the others for review anyway and see what happens. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Tom Livingston wrote: On 3/2/06 10:31 AM, "Lachlan Hunt" <[EMAIL PROTECTED]> wrote: [1] http://edentiti.com/ Took _minutes_ for the home page to display, and once it did, it still wasn't finished loading "things". Mac OS 10.4.5 Safari 2.0.3 Really? Maybe the server can't cope with the load very well, it's loads just as fast in Safari for me, as it does in everything else. I find IE slightly slower because of the IE7 and the DOM patch scripts initialising, but nothing too serious. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Gunlaug Sørtun wrote: Lachlan Hunt wrote: [1] http://edentiti.com/ The layout can't cope with any degree of font-resizing in any browser, which I think is a weak point. In my testing, I can resize a substantial amount before seeing any problems occur, and even then it's just slightly misaligned background images which don't affect the readability of the content too much. The text will eventually over lap the columns (especially on the 3-col home page), but it has to get quite big and I'd rather the user disabled stylesheets in such cases or we provided an alternative larger font/single-column stylesheet. Noticed delay (on a slow connection) for those '#secondary-nav' background-images to change on :hover first time. Maybe a single repositioned background would work better..? That was considered and even attempted, but I couldn't find a way to do it in a way that didn't cause other problems without spending too long on the issue. Now that I have more time, I may be able to find a way to do it. PS. I know the markup is currently XHTML and I'm aware how much of a hypocrite that makes me :-)... plans to convert it to HTML4 later on. Not much of an issue :-) However, are there any reasons for not using '(X)HTML Strict' on that page/site? Yes. The JavaScript and CSS were not fully written to deal with real XHTML issues. With the exception of the DOM script from my library which was written to handle both conditions, the rest wasn't designed and tested under XML conditions because my original templates used HTML 4 Strict. It wasn't until the back end developer came along later and was only relatively new to programming JSP/JSF, we ended up having to accept the default output of XHTML in favour of fixing the other more major issues including invalid/ill-formed and inaccessible generated markup. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Rob Mientjes wrote: On 02/03/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Hi Everyone, A new site I recently developed the front-end for over the past few months, called Edentiti [1], has just officially launched and I wanted to get some feedback... Looks good, everything works. Just not sure about the logo and left chunk of site. Why is that below the header bar? It was decided by the designer and management that they wanted the logo on the homepage to be slightly larger and more prominent as a branding exercise, but to then move it up to the header, out of the way for all the sub pages. Is that just Safari or was it a conscious decision? Concious decision, all browsers. Also, a typo on the about page says "About Edentit"—think of all the children that will grin gleefully. Couldn't find that typo anywhere. Which page? Give the URI. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Check/Launch: Edentiti.com
Hopkins Programming wrote: Why must I have javascript enabled for the site to be styled? Um... You don't need to, although IE users without script enabled with have a slightly degraded style (not totally unstyled) due to Dead Edwards' IE7 script not working. Which browser are you testing with? I couldn't replicate this issue at all. -- Lachlan Hunt http://lachy.id.au/ ** 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] Site Check/Launch: Edentiti.com
Hi Everyone, A new site I recently developed the front-end for over the past few months, called Edentiti [1], has just officially launched and I wanted to get some feedback about the usability, accessibility and over functionality in whatever browsers you can get your hands on. I've tested in various Windows and Mac browsers during development, but as is always the case, bugs tend to sneak in wherever they can and something may have been missed. (I know there are bugs in IE7, but I'd rather wait till MS actually release something that isn't a joke like both betas 1 and 2 were before I bother testing/fixing with it - the one to be released after Mix '06 looks slightly more promising) For all you DOM Scripting fans, if you go to step 2 of the Create an Edentiti section, there's a funky form validation script you might want to check out. http://edentiti.com/create/ (click next, to get to step 2) [1] http://edentiti.com/ PS. I know the markup is currently XHTML and I'm aware how much of a hypocrite that makes me :-), but, given the time constraints, it was a limitation of the back end solution we had to accept, with plans to convert it to HTML4 later on. -- Lachlan Hunt http://lachy.id.au/ ** 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] Linking to top of page
Ian Anderson wrote:
Lachlan Hunt wrote:
It depends where the H1 is positioned. If it's not at the top, the
page won't be scrolled to the top.
If the H1 isn't at the top of the content, then I'd say there's a pretty
good case for saying that the H1 is in the wrong place.
I meant not at the top of the rendered view. i.e. It's been positioned
using CSS. Try this simple test case:
#foo { margin: 100px 0 1000px; }
Hello
top
--
Lachlan Hunt
http://lachy.id.au/
**
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] Linking to top of page
Paul Novitski wrote: At 05:35 AM 2/27/2006, Curby wrote: What is the recommended way for linking back to the top of the page? I can't link to the id of my H1 because of my CSS. Whoa. Stop right there. How can CSS stop you from linking to an h1 that's got an id? It depends where the H1 is positioned. If it's not at the top, the page won't be scrolled to the top. -- Lachlan Hunt http://lachy.id.au/ ** 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] Linking to top of page
Curby wrote: What is the recommended way for linking back to the top of the page? I can't link to the id of my H1 because of my CSS. The name attribute of the A tag is deprecated/removed[1]. ... [1] http://www.w3.org/TR/xhtml11/changes.html#a_changes It's only deprecated in XHTML 1.1, which you almost certainly shouldn't be using anyway since it's really not supposed to be served as text/html. If you really want to jump on the XHTML bandwagon, stick with XHTML 1.0. And while some people might say "use the scrollbar or press Home" That's always possible and why I never bother with back-to-top links. 1) Giving my BODY id="top" and linking to that seems to work but might not be widely supported. I'm not aware of any browser that doesn't support it, though it's possible some older browsers may choke on it. If you use a container element around the whole content, you could use that instead: ... content ... top -- Lachlan Hunt http://lachy.id.au/ ** 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] Converting the heathen: never again
Lea de Groot wrote: Maybe (s)he knew all those things were a problem I doubt it. If that were the case, I'm sure the response would have been more along the lines of: "Thank you, we are aware of these problems and we are investigating ways to fix them, but at this stage there is nothing we can do. We apologise for the inconvenience." and couldn't bear them being brought up by (cough, splutter) a *customer* What kind of person would rather insult the customer instead of admitting they have a problem? -- Lachlan Hunt http://lachy.id.au/ ** 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] Converting the heathen: never again
SunUp wrote:
When I could not find what I was looking for I was told: "I recommend
that this issue in this case has not been a usability issue but
instead has been a logic issue on the clients side, and I would
recommend that you re-attend year 10-12 english classes in order to
know this in future cases."
They obviously fail to understand the concept of usability. It's not
about their ability to use the site, it's about the user's ability, and
the fact that they have chosen to completely disregard this usability
issue is astounding.
When I complained about horizontal scrolling I was told: "I would
recommend that you take a look around the real world, not just your
own room and classroom, and see that these days even seniors are
using the resolution of 1024x768.
They need to realise that screen resolution is irrelevant. I suggest
you inform them that it's the viewport size that matters, and even if a
user has their screen resolution set to 1024x768 or higher, their
browser window may not be much larger than 800px wide, either because
they don't maximise it or they use a side bar or anything else that
reduces the viewport size.
Personally, on my 1280x768 screen, my browser sits at around 900px wide.
When I used to use a 1024x768 screen on older machines, it would have
been less than 800px, because I don't like maximised windows.
And you do have a choice, you have the choice of
increasing your resolution, or alternatively to scrolls when you want
to see anything to the left or down on the website.
How is that a choice? In their case, that would be more of a
requirement to effectively use their site! Perhaps you should politely
remind them of the meaning of the word "choice".
When I commented on the huge amount of javascript in the I was
told: "unobtrussive javascript does not work on a number of browsers
short of the newest,...
That's a load of rubbish. There are, of course, some features that
won't work in older browsers, but that doesn't mean unobtrusive script
cannot be written for them.
Javascript pulled from linked files doesn't work in some browsers?
I don't think either of you fully grasp the concept of unobtrusive
javascript. It is not merely script which has been externally linked,
it is one that exhibits no obtrusive behaviours and degrades gracefully
when not fully supported or not supported at all. It is, in fact,
entirely possible to have unobtrusive javascript that is contained
wholly within the document, rather than an external file, although an
external file is considered to be best practice.
As for the CSS that was in the (body
{margin-left:0px;margin-top:0px;margin-right:0px;margin-bottom:0px):
... ".. could not be solved with a simple
margin:0 as you have stated, which is only the newest standard in
relation to this issue,
I would like to know where they got this information from. The 'margin'
shorthand property has been around for as long as the individual
properties have been. They all exist as part of CSS 1 and have been
reasonably well implemented in browsers. Although there are many box
model related bugs, AFAIK none of them relate to the use of 'margin'
instead of 'margin-top', ' -right', ' -bottom' or ' -left'.
but which does not resolve the issue in the
browsers that this code is targetted at.
Ask them to name the browsers that they believe the 'margin' shorthand
property (or, indeed, any other feature they claim can't be used) will
not work in.
As to validation: "the W3C are self-appointed, and the standards they
impose are self-regulated and are only recommended standards.
While that is technically true and there are some cases where the W3C
recommendations don't reflect the interoperable behaviour found in most
browsers, their standards need to be followed as closely as possible to
achieve maximum interoperability.
--
Lachlan Hunt
http://lachy.id.au/
**
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] Positioning a graphic
Angus at InfoForce Services wrote:
I appologize if this is off topic. The validator does not like "float:
center;".
That's because the value is undefined for the 'float' property.
What is the correct way to center an image? IE6 shows a
centered Scottish flag which I would like and Firefox 1.5 does not.
IE is wrong. There are various ways to center a box. You can set
'text-align' on the parent element, which will center all content.
p { text-align: center; }
/* where the img is a child of this element, just use an appropriate
selector */
The other way is to use auto for left and right margin.
img { display: block; margin: 0 auto; )
IE 5.x doesn't support this method, but that shouldn't matter since it's
obsolete anyway. You can just let it degrade gracefully in it.
--
Lachlan Hunt
http://lachy.id.au/
**
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] Page veiwing
SunUp wrote: Woah! They're such low resolutions, do you only have a 15" monitor? Gee you guys ... not everyone has the latest 'n greatest in equipment. I think everyone is aware of that, it was a simple question that was not meant to cause offence or otherwise insult or ridicule the person for failing to upgrade their equipment to support a minimum resolution of 3840×2400 or higher. :-) My work (government) PC has a 17" mon, 800x600 (because I LIKE this res, Interesting. and I wish I had a dollar for every site I have to horizontal scroll on). Indeed. Sites that require horizontal scrollbars for 800x600 screens need to be fixed. Their designers often fail to realise that not everyone has their browser windows maximised, so even if the user does have a slightly higher resolution, their viewport may still be relatively narrow. I will have to be dragged kicking and screaming to 1024x768 Are you aware of the ergonomic considerations for screen sizes and resolutions? I believe the recommended resolution for a 17" (4:3) monitor is 1280x1024 (that's even the native resolution of most LCD screens of that size) and 1024x768 for 15". (For 17" LCD screens, that happens to work out nicely as 96 pixels per inch, making 1 device pixel equal the size of the reference pixel in CSS. Not exactly sure about 15" screens, I haven't done the calculations, but I think it works out to be fairly close) Regardless of that, I've never heard anyone so strongly object to the notion of using a higher screen resolution. If you don't mind me asking, what are your reasons for making this decision? I will certainly never go higher. I wouldn't say never, I expect that the minimum resolution of newer operating systems to increase from 800x600 to 1024x768 in the near future. It already went from 640x480 to 800x600 with WinXP (at least on devices that support it). -- Lachlan Hunt http://lachy.id.au/ ** 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] "What is ..." XHTML Questions
Kat wrote: I had written a huge email with a ton of questions, that I realised many really boiled down to one: How did that one guy, 'beandizzy', pass all three tests? http://www.goer.org/Journal/2003/Apr/index.html#results How do I replicate those efforts? 1. The Simple Validation Test Validate your home page, fix every single errors and preferably fix all warnings, unless you have a very good reason not too. 2. The Laziness Test Validate all sub pages. 3. The MIME-type Test For all XHTML documents, the server must send the following HTTP header: Content-Type: application/xhtml+xml The first 2 are easy. Just run them through http://validator.w3.org/ and fix what it tells you to. Although, you should be aware that the W3C validator has some XML limitations mostly related to well-formedness, but these will be picked up when you set the MIME type properly. The third requires that you configure your server properly, and this depends on the server and/or the server side technology you're using. For static XHTML files using Apache, you can use a .htaccess file. Just create one and add the following line: AddType application/xhtml+xml .xhtml You can use whatever file extension you like, though if your server needs to serve both HTML and XHTML documents, it will need to be different from the one used for text/html (usually .htm or .html). 1.What is the difference between the doctype and the standard namespace? What does this namespace provide: 'html xmlns="http://www.w3.org/1999/xhtml"; xml:lan="en" ' that isn't provided by the doctype? The DOCTYPE (short for Document Type Declaration) refers to a DTD (Document Type Definition) which describes the legal structure of the document, including element content models, attributes and their types, and their default values. The namespace is used to associate an element with it's defined semantics. Elements in the XHTML namespace <http://www.w3.org/1999/xhtml> have their semantics defined in the XHTML recommendation or a related module. The DOCTYPE does not define semantics at all, only structure. Although, you should be aware that the XHTML 1.x DOCTYPEs define the default value for the xmlns attribute, and so a validating parser will not inform you that you have left it out. However, it is required because not all parsers are validating parsers (no browser uses a validating parser) and so, they would not be aware that the elements were in the XHTML namespace. 2.>blockquotehowever XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.>/blockquote< http://www.w3.org/TR/xhtml1/ Is the XML declaration the XML prolog: ?xml version="1.0" encoding="UTF-8" ? Yes, that is the XML Declaration, but the XML Declaration is not the same as the prolog, it is only part of it. So if your character encoding is UTF-8, thus it is OK not to have this XML prolog? Yes. Or should that last 'and' have been an 'or' in the specs: Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 *OR* no encoding was determined by a higher-level protocol ? According to the XML Recommendation, that is correct. Thus if the server sends the character encoding as UTF-8, then this prolog is not needed? If the server sends any character encoding, the XML declaration is not required. However, it is strongly advised that it be included when the encoding is not UTF-8 or UTF-16, because the file itself could be saved to the local file system, where no such protocol information exists, which may then make the document non-conforming. (Note: The only exception to this rule is if you only use the US-ASCII subset of any encoding, which is also a subset of UTF-8) -- Lachlan Hunt http://lachy.id.au/ ** 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] Google pages and the XHTML doctype
Christian Montoya wrote: I just published a page with the new "Google pages" service and I would like to share it with you all: http://sirokai.googlepages.com/home If you do a view source you will see some pretty bad markup. An XHTML 1.0 Strict doctype with invalid nesting and font tags. This is, unfortunately, fairly typical of most pages with XHTML DOCTYPEs on the web. I think this won't be good for XHTML if everyone is publishing pages through Google's service with the doctype and bad markup. The problems certainly aren't limited to Google's service. Just take a look at Geocities or any other major free web page hosting company like that. I sent them a request asking them not to use the XHTML doctype, mentioning that the HTML 4.1 doctype is safer, That's HTML 4.01. Although, validation clearly isn't one of their goals, so they'd be better off just using . It triggers standards mode, and since validation isn't a concern, there's no point lying about it. -- Lachlan Hunt http://lachy.id.au/ ** 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] Strange empty XHTML element issues in IE & FF
Vlad Alexander (XStandard) wrote: Lachlan wrote: It is just as easy to set , output an HTML4 DOCTYPE and not worry about inserting a space before '/>' for empty elements. If you use the 10 lines of re-usable code that I suggested in your XSLT, one does not need to "worry" - you have XML in and you have XML out. That code your referring too seems to be incomplete. It doesn't handle every empty element, and in fact seems to explicitly filter out link and meta elements, along with script and iframe elements which makes no sense to me. Excerpt from the XSLT: Why do that? AFAICT, this prevents those elements from being output. There may be a reason for that in your specific application, but it doesn't really make this code reusable as is, without modification. That list is missing the following empty elements: * * * * * * * * As a result, I believe (with the exception of link and meta) these will be processed as non-empty elements by your code, and thus not comply with Appendix C. If you're using XSLT, why bother attempting to comply... It depends on your requirements - right? Yes, it does. If you are doing a batch process and you plan to store the output before serving it, you would want to store it in a parsable form that can be served as is or further processed by other XML technologies. Fair enough, but do you agree that if there is no intention of any further XML processing, then converting to HTML 4 would be the most appropriate choice? Can I assume that you agree that XHTML 1.0 was designed to be backwards compatible to HTML 4 if written to compatibility guidelines? It is clear that that was certainly the intention, but I don't agree that the HTMLWG were entirely successful in doing so. -- Lachlan Hunt http://lachy.id.au/ ** 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] Page veiwing
Angus at InfoForce Services wrote: I am sorry if this is off topic. I do not know who to ask. I have my screen resolution to default to 800 by 600 and thinking of changeing to 1024 by 768 Woah! They're such low resolutions, do you only have a 15" monitor? I still would like to view my web pages in 800 by 600. I really do not have the knowledge to have the screendefault to 1024 by 768 and still veiew web pages in 800 by 600. Get yourself a copy of the Web Developer toolbars for Firefox [1] and IE [2]. They have options to resize the browser window to 800x600. Other browsers may have similar tools available or may even be built in, but even if they don't, you can always resize them manually. There's no need to change the resolution of your screen down to 800x600, since it's the viewport size that matters. Also, keep in mind that not all users have their browser window maximised. [1] http://chrispederick.com/work/webdeveloper/ [2] http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en -- Lachlan Hunt http://lachy.id.au/ ** 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] :before and :after for code tag
T. R. Valentine wrote:
On 22/02/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
code:before {
content: "
No version of Internet Exploder will generate content. Unfortunately.
Not natively, but Dean Edwards' IE7 script will add limited support for it.
--
Lachlan Hunt
http://lachy.id.au/
**
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] Plain text v HTML on this list
Terrence Wood wrote: On 22 Feb 2006, at 2:50 PM, Lachlan Hunt wrote: Outlook users should ...switch to a better mail client that isn't broken. Outllok can be configured to send plain text can't it? It can, but there are a variety of serious problems with Outlook that make it an extremely bad program to use. I won't go into much detail, because it's off topic, these are just a few issues. * Lack of support for format=flowed [RFC 2646] * Failure to quote properly by default, even in plain text mode. (Incorrect use of vertical bar '|', instead of '>' - not sure if that's by default, but it does do it.) * Lack of support for sending the proper sig separator: "-- " (the space on the end would be stripped before sending, even if you typed it manually) * Failure to remove the signature when replying to e-mails that do use the proper sig separator. * Country specific prefixes to subject for replying and forwarding. * Incorrectly formatted (bloated) attribution line. * Signature is placed above the quote in replies by default (i.e. top-posting). And that's just for plain text. It gets worse when you look at its HTML mail. Some of these things are fixed by using Quote Fix; but IMHO, you're just beating a dead horse. It doesn't fix the major security holes in it, its inferior junk mail filter, its bloated user interface, and probably many more issues I can't recall off the top of my head. Now, this is getting way off-topic so if anyone wants to continue the discussion with me, I'll be more than happy to respond off-list. I usually don't bother to read the 1mm tall text it sends out (screenshots on request), unless I'm really interested in the thread. Can you put the screenshots up somewhere and link to them? I've never seen such small text, either in or from Outlook. -- Lachlan Hunt http://lachy.id.au/ ** 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] Strange empty XHTML element issues in IE & FF
Vlad Alexander (XStandard) wrote: You can write your XSLT to output XHTML that follows compatibility guidelines. You can use the technique in this XSLT: http://misc.xstandard.com/wsg/preview.zip If you need a hand with your XSLT, contact me off the list and I'll be happy to help. If you're using XSLT, why bother attempting to comply with the oft criticised, self-contradictory, *non-normative* "Appendix C"? (I will not get into another flame war over this, I just want to know your reasons, assuming you actually have any.) It is just as easy to set , output an HTML4 DOCTYPE and not worry about inserting a space before '/>' for empty elements. There is no benefit to be gained from serving XHTML as text/html to the client, even if there are benefits gained from working with XHTML on the server side. -- Lachlan Hunt http://lachy.id.au/ ** 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] Plain text v HTML on this list
Nick Gleitzman wrote: A frequent request, which occasionally needs to be remade: could list members please use plain text for posting? Yes, absolutely! The following articles discuss the various issues further. Although they generally relate to USENET, most of the advice applies equally to mailing lists like this as well. http://www.cs.tut.fi/~jkorpela/usenet/dont.html This is some of the reasons why HTML mail is not appreciated: http://www.georgedillon.com/web/html_email_is_evil.shtml And also, people need to learn how to quote properly: http://www.netmeister.org/news/learn2quote.html http://www.xs4all.nl/%7ewijnands/nnq/nquote.html Note: Outlook users should get Quote Fix or switch to a better mail client that isn't broken. -- Lachlan Hunt http://lachy.id.au/ ** 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] making table cells share equally
Ted Drake wrote:
Hi all you former table hackers out there. I've got a simple question.
If I have two or three columns in a table and I want the cells to share the
space equally, what would you suggest? I don't have a width on these cells
right now and if one cell has lots of content, it's pushing the other column
to the curb.
table { table-layout: fixed; }
--
Lachlan Hunt
http://lachy.id.au/
**
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] Strange empty XHTML element issues in IE & FF
Paul Hempsall wrote: I came across a strange issue last night while converting some XML data via an XSL template into XHTML. Issue 1: In the Head section of my XHTML I had an empty script element (see below). IE refused to load the page. IE does not support XHTML at all. All of your problems are a result of using the wrong MIME type. XHTML should not be served as text/html, it should be served as application/xhtml+xml or other XML MIME type. When you serve XHTML as text/html, browsers think they are receiving HTML, so that's how they parse it. They have to resort to error handling techniques to handle all those extra slashes and, in this case, missing end tags. The following explanations of your problems only relate to text/html documents. The syntax is perfectly well-formed XML, but requires an XML MIME type to be parsed properly. FF had no problem with this. The reason Firefox appears to have no problem with it is because of the way it will reparse the entire document from that erroneous script element when it hits EOF and has not found a matching end-tag. This behaviour cannot be relied upon, or any other markup that currently causes Firefox to reparse it, as this will likely change in the not-too-distant-future. As far as browsers are concerned, that is exactly equivalent to: </pre><tt>If you remove the '/' from your document, you will get exactly the same </tt><tt>result. </tt><pre style="margin: 0em;"> Compare these: <a rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo</a> <a rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript/%3E%0A%3Cp%3Efoo">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript/%3E%0A%3Cp%3Efoo</a> <a rel="nofollow" href="http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo%0A%3Cscript%3E%3C/script%3E">http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo%0A%3Cscript%3E%3C/script%3E</a> </pre><blockquote style="border-left: #EE solid 0.2em; margin: 0em; padding-left: 0.85em"><pre style="margin: 0em;"> To get IE past this line in the markup I had to change the text to read: </pre><tt> </tt><tt><script type="text/javascript" src="nav.js"> That is the correct what to handle it. Issue 2: In the body of my document I have an empty . IE rendered the page correctly. FF didn't close the element, so my CSS didn't get implemented correctly. Again, that is exactly equivalent to: , with no end-tag. See what the DOM looks like: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cdiv/%3E%0A%3Cp%3Efoo To allow FF to process the div, I had to modify the line to: That is correct. I thought I might need to add a space before the forward slash (ie. ), but this didn't make any difference. The space is required for compatibility with some older browsers (Netscape 4.x I think), so that they don't completely choke on it. What's also weird is that I have plenty of other self-closing elements in the document, but these didn't break the browsers. It's ok to do it with empty elements like , , , etc. because they're already EMPTY in HTML and don't require end tags. In such cases, the '/' is just handled as part of error recovery, the browser doesn't keep looking for an associated end tag. The same is not true for elements that aren't EMPTY in HTML. -- Lachlan Hunt http://lachy.id.au/ ** 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 legitimate case for pop-ups
Patrick H. Lauke wrote: Lachlan Hunt wrote: No, that just demonstrates how ignorant judges can be with regard to technical implementations. The article states: Off topic, but it made me smile thinking about my not so clued up higher management going on about adding a "GIF" to pages to mean "image". If only they knew that I'm disobeying their wishes and sometimes use a JPEG or even PNG instead... I know how you feel, I get requested to use all sorts of inferior technology in various jobs. At a previous job, I worked with a graphic designer that didn't know much about PNG at all, and actually once requested that I change all the PNGs to GIFs. I informed her that PNG was superior to GIF in every way, and that I only had to avoid alpha transparency and it works just fine. I don't even use GIF any more, especially since PNG8 can do index transparency just as effectively as GIF, and I rarely use animated GIFs. -- Lachlan Hunt http://lachy.id.au/ ** 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 legitimate case for pop-ups
Kat wrote: I never thought the day would come when there actually was a legitimate use for pop-ups! I'm still waiting for that day. It's legitimate to use pop-ups, if a court judge orders you to :) http://australianit.news.com.au/articles/0,7204,18214048%5E15306%5E%5Enbv%5E,00.html No, that just demonstrates how ignorant judges can be with regard to technical implementations. The article states: | Justice Wilcox ordered Sharman to use pop-up windows to force users to | upgrade their Kazaa systems to a new version that would include a | copyright filter. Assuming The Australian actually quoted that correctly, and didn't mean that: a) they were ordered to force users to upgrade in some way. and b) they decided for themselves to use popups for that purpose. Then this just proves that upper-level management (a judge in this case) should not ignorantly force specific implementation details upon those doing the actual implementation. There may be other ways to force upgrading without using a popup and the actual implementation is irrelevant from a legal point of view, as long as the end result is the same. -- Lachlan Hunt http://lachy.id.au/ ** 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] Font Sizes - Best practice
russ - maxdesign wrote: people that use the Internet world wide. Consider this: the number of people that visit my relatively small site every single day would be more people than I've met in my entire life time, so it's hardly... This could be read in two ways. You have a hugely popular site, or you need to get out more. I am hoping for your sake it it the former ;) I hadn't thought of it that way. :-) ... It's ok for relatively unimportant legal mumbo jumbo (copyright notices, disclaimers, etc.) to go smaller than that, but not for main content. Could it not be argued that the "unimportant" legal content is sometimes more important to some users than the general content on the page? :) I'm sure there are some that think such notices should be shown in large bold letters, read and agreed to by every user prior to getting access to the rest of the site. They do exactly that on DVDs and Videos, often on porn sites where the user must agree to being over 18, etc. But from the average user's perspective, it's the main content that's most important. -- Lachlan Hunt http://lachy.id.au/ ** 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] Font Sizes - Best practice
Martin Heiden wrote: I read a lot of threads about font-sizing lately, but I still did not catch the point of best practice yet. I use to set the body font-size to 62.5% for getting 1em = 10px at default settings. Eek! Never rely on default settings, many users will change them. So if a user sets another preferred font-size, my hole layout will adjust to that value, Good. On the other hand, I don't know anyone who changed the default font-size in his/her browser I do, but that's irrelevant. The number of people you know, or anyone else knows for that matter, is insignificant compared with the number of people that use the Internet world wide. Consider this: the number of people that visit my relatively small site every single day would be more people than I've met in my entire life time, so it's hardly surprising that the people you know wouldn't even come close to being a good representative cross-section of the wider population. but lot's of people (mostly designers) who prefer smaller font-sizes. It's unfortunate that so many designers prefer small font sizes. They fail to realise that while they may think small fonts may look good from a design perspective and are easily readable on their massive, super-high resolution, 21" monitors, it actually looks really awful and is extremely difficult for many users to read. Not every user will understand how to increase the font size, let alone know how to configure a minimum size in their browser. Those that do know will be able to work around such bad author decisions, but those that don't will be left squinting at their screen, which is bad for ergonomics, usability and accessibility. IMHO, any smaller than 'small' (approx 82%) is too small for main body copy, though I know some that argue font sizes generally shouldn't be smaller than 'medium' (100%). It's ok for relatively unimportant legal mumbo jumbo (copyright notices, disclaimers, etc.) to go smaller than that, but not for main content. Well, the question is: Which group of people is more important? I'm hoping that's a rhetorical question! The users are more important. They're the ones visiting your site trying to read it and if they can't read it, they'll leave. Or better: Is there a way to please both groups? Yes. Don't use small fonts. Those that can't read small fonts will be happier with the larger fonts, those that can read small fonts will have no difficulty reading the larger font and if they find it too big, they can either decrease it or even just sit a little further back from their screen. You need to build for the lowest common denominator (within reason), and when it comes to font sizes, it's better to be slightly too big for some, than too small for others. -- Lachlan Hunt http://lachy.id.au/ ** 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] problem with Conditional Comments
Soeren Mordhorst wrote: This one should link to a CSS file for IE6, not IE5.x, but I'll assume that was just a typo and you meant something like ie6xstyles.css. So what I need are three css-files: - normal layout.css - one css-file for IE 6 - one css-file for IE lesser than 6 (5.0 - 5.x) Any suggestions? Besides the mistake above, I don't see what else you could be having trouble with. That's exactly what you need to do if you wish to support IE5 and IE6 in this way. In future, always provide a URI to a test page demonstrating the problem, you'll be more likely to get much more helpful response if you do. -- Lachlan Hunt http://lachy.id.au/ ** 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] occam's razor again
Designer wrote: Back button? I'd like to bet that >75% of users don't know what that is! Aw, people can come up with statistics to prove anything. Forfty percent of all people know that. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Herrod, Lisa wrote: Lachlan Hunt wrote: The users! Please, won't somebody think of the *users*! This line reminds me of something from my favourite show when I was a kid: Fantasy Island. "the plane, the plane!" :) Actually, it's a slightly misquoted line from Helen Lovejoy in the The Simpsons: "Won't somebody _please_ think of the children??" Every site is different, every user is different, every demographic varies from the last. ... Don't assume anything... whether or not it's best practice. Which is exactly why I make no assumptions about the user's browsing environment or preferences, and I don't attempt to force new windows upon them which they may or may not want - they are free to do as they please, without interference. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Jude Robinson wrote: Lachlan Hunt wrote: There are no valid use-cases or reasons for opening a popup window Well...there's *one*: http://www.useit.com/alertbox/open_new_windows.html No, Jakob is wrong about that one. I know, it's strage, he's rarely wrong about usability issues, but he is in this case. Browsers and/PDF viewers can be configured in various ways: * Open PDF within browser (the unfortunate default) * Save PDF to disk, then open in external application (e.g. "PDF Download", Firefox extension) * Load PDF in external application (saving only to temp directory) * User may not have a PDF plugin installed, and just be prompted to save it. For anyone without the default setting, forcing a popup window would result in new blank window. For those with the default setting, I'm aware of the fact that this has been known to cause problems in older versions (incl. crashing), but that is an issue for the browser/PDF plugin vendors to address, not each individual site author. The only information a browser needs is this in the HTTP headers: Content-Type: application/pdf It may help to include that in the type attribute. foo (PDF) But few browsers ever use that attribute by default. There may be extensions that do (I don't know), but CSS can be used to style it or JavaScript to do something else with the link to make it obvious to the user that the link is to a PDF. Theoretically, it's possible to interpret that type attribute to mean open a new window, and it would seem trivial to write a Firefox extension (or Greasemonkey script) to do that. The important point is that telling the user/browser that the file is a PDF should be all that is required for the user/browser to make an informed decision about what to do with it. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Serdar Kılıç wrote:
When I first started my weblog all internal links had no target
attribute thereby browsing within my site was within a single window.
Any offsite links were brought up in a new window, a window for each
link clicked.
The way *I* browse some sites is how I built my site.
But you need to remember that you're not building your site for you.
You're building it for *your visitors*. For every user, there is only
one person can decide if they want a new window: themselves!
The problem is is that there are no visual clues whether or not a
link will open in that window or a new one (I'm not a fan of little icons).
Which is why shouldn't rely on a author to a) open a window for you if
you want one, or b) not open a window if you don't want one. You can
use a user stylesheet to indicate the presence of a target attribute:
a[target] { cursor: crosshair; }
But I think the best option is to completely disable the target
attribute to prevent the author from interfering with your decision and
make it yourself, every single time. You cannot possibly rely on the
author to make the right decision for you, because every user is different.
--
Lachlan Hunt
http://lachy.id.au/
**
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] TARGET in 4.01 Strict
Kevin Futter wrote: On 15/2/06 6:57 PM, "Lachlan Hunt" <[EMAIL PROTECTED]> wrote: Many users hate popup windows. There are no valid use-cases or reasons for opening a popup window, don't do it. If you think you have one, I'd like to hear it, but know this: I've heard many excuses over the years (some more often than others) but every single one of them has been flawed in some way. Yes, in fact I do have one. For a couple of sites I do for musicians, I open a Flash-based music player in a new window - a small pop-up. Why? Because if you embed the music player in the page and begin to play a song, and then navigate to a different page or website, you lose the entire show. I'm not convinced. There is no reason why the user can't choose to open it in a new window/tab for themselves. Even if they don't, they can continue navigating elsewhere in a different window/tab. Besides, you shouldn't need to write your own flash-based music player. You could provide the song in an downloadable MP3 or a streaming audio format and let them play it in their own media player. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Jona Decker wrote: Lachlan Hunt wrote: For what reason are they annoying? You can't just say something is annoying because you think something else is better, you have explain what it is about it that is annoying, and perhaps the issue could be addressed to improve the method without resorting to popups. If the viewport isn't the "right" size you do not see this expanded text. So you click on the help question mark, and seemingly nothing happens. The only way I could replicate this in the demo page was by resizing my window so that the the text box and help button were at the bottom of the viewport with nothing visible below them. It seems strange that you wouldn't have scrolled the page up nut even then, the scrollbar clearly resized when I clicked it, indicating that I need to scroll down. I know it's not perfect, but it wouldn't be hard to solve this problem, here's a few quick ideas. (I'm sure there's many other possibilities) * A script could scroll the page a little (if required). * The icon could change from a question mark to a down arrow, pointing to the help. * The help could be positioned beside the field, rather than below. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Designer wrote: I'm surprised at your comment that the number of windows is being reduced these days - have you seen Dreamweaver lately? Dreamweaver has a nice tabbed interface, I'm not sure what you mean. Flash 7? No, I don't use flash. Photoshop? I find photoshop's use of windows annoying, it would help a lot if all the little tool windows would actually dock together in one manageable group. I find it impossible to work on a lot of these graphics programs without two monitors on the go! And you don't consider that evidence against the use of so many windows? Incidentally, preview pane: surely, having something appear in the preview pane is the same as opening it? Yes, it is. But it doesn't appear in the preview pane until I select it, but even if I do, it is 100% safe for me. And opening mail is a really good way to set a virus free. I'm well aware that there are/have been major security holes in Outlook that allow malicious software to run simply by reading e-mail, but this is impossible to do in Thunderbird (or any other decent mail client, for that matter) in plain text mode, and I know of absolutely no security holes even in HTML mode, which I'm rarely in anyway. Looking at the subject, who it's from etc and deciding whether to read it or bin it is much more secure as far as I can see. True, and the few that aren't picked up by my junk filter get manually marked as junk before I read them. But even if I did open them, it would still be completely safe. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
rs, I try to get some of this flexibility and uncluttered approach into my web How could opening new windows be considered an "uncluttered approach"? Remember, one of the major benefits of tabbed-browsing is that it reduces the clutter of windows on the desktop. pages. If I have a gallery of images, a click on a thumbnail will perhaps open a larger display of the image - in a new window. Eek! I hate galleries that do that. Have you considered the possibility of a better alternative? http://www.alistapart.com/articles/imagegallery/ http://www.huddletogether.com/projects/lightbox/ Lightbox looks better, has the same result of a popup, in that it doesn't navigate away from the current page, but it's easier to close by clicking anywhere, there's no need for clicking the close button. It's currently got some keyboard navigation problems, but it could always be improved. If a link is waiting for the content to be completed, an alert box "available shortly" pops up I really don't understand how you think popping up an alert box that the user needs to dismiss before anything will continue is a usability benefit. Browser developers realised a long time ago that alert boxes are useless and annoying. This is why they are moving the much less obtrusive information bar approach. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Stephen Stagg wrote: On 15 Feb 2006, at 12:28, Lachlan Hunt wrote: What I really don't understand is that there are so many people who participate in this and various other mailing lists, newsgroups and forums that actively advise against using popups and explain why they hate them, yet you still somehow believe that users are ok with them. Newsflash: we are users too! Listen to us when we tell you outright that *we hate popup windows!* Do not use them, find a better solution. For that matter, I am a user too and I like popups when used properly. Perhaps your aggressive responses tend to be a bit pony-ish? You can never please everyone, the example you gave of http://juicystudio.com/article/form-help-without-popups.html is not something I prefer over a well implemented popup and therefore, for this issue, using these inline-hidden-help-comments are annoying me, and people like me. For what reason are they annoying? You can't just say something is annoying because you think something else is better, you have explain what it is about it that is annoying, and perhaps the issue could be addressed to improve the method without resorting to popups. If you don't like having to move your mouse up to the toolbar of your window when closing them, learn your OSs key combination for closing the active window. (Windows: Alt-F4, Mac OSx Cmd-W) This way, you can improve your productivity. I know the key combination, but then I'd have to move my hand to the keyboard which takes just as long. While browsing I use the mouse far more often than the keyboard since a) most of the time, I'm not typing anything, and b) my mouse has every major browsing function built in (back/forward, clicking links (obviously), scrolling, selecting text, etc.). I don't have a >100Mbit connection so I like it when a site opens an external link in a new window, Then you have every right to request your browser to do so for you. What reason does the author have to believe that all users feel that way about the situation, when they clearly don't? Every time I click a link, I make that decision for myself. It's not that hard. If I want the same window, I'll left click and if I want a new tab (or window, if you prefer), I'll middle click. You and every other user can perform exactly the same function with your browser (using whatever mouse/keyboard command it's configured with), the author should not interfere with the user's decision. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
James Gollan wrote: Lachlan Hunt wrote: Ian Anderson wrote: Lachlan Hunt wrote: I think generalisations like "users hate popup windows" are perhaps a little unhelpful. But the statement is 100% accurate... It may be technically 100% accurate, but in that case so is the statement "users hate it when a new site opens in the current window and takes them away from the site they were viewing". It only takes 2 users to make this true. And these 2 users may also be annoyed :) True, but such users can only be annoyed with themselves for failing to understand how to use their browser in a way that gives the results they want; not with the author for failing to meet their specific requirements, which will very likely differ significantly between every user. I am not a pop-up advocate, I think it's best to clearly identify external links but open them in the current window. I do, however, wonder about the number of users that actually know that they can override the browser and open a link in a new window. I'm sure there are many that don't know how to open a new tab/window, but I'm sure there are many, many more that don't know how to prevent a new tab or window. This is, perhaps, a browser usability issue, but it should be addressed by the browser vendors, not web page authors. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Ian Anderson wrote: Lachlan Hunt wrote: Many users hate popup windows. There are no valid use-cases or reasons for opening a popup window, don't do it. I disagree with this statement. In my opinion, there are several very good use cases. Name one for which a popup window is the only valid and, indeed, best solution! The primary one is help windows, where instructions can be compared with the items in the main window. A variant of this is T&Cs in forms, where there are serious consequences for the user if they move off the page while in the middle of completing a form - they may lose some or all data. While that is legitimate use-case that comes up quite often on the web, the best solution does not involve popup windows. In fact, related to the issues I discussed earlier, popup windows can be prevented and you have no idea which users do this. Thus, while relying on the popup windows to solve this problem may work for 99% of visitors, for the 1% that don't get a new window (incl. those without script and those, like myself, that explicitly disable popups), the problem you're trying to solve is still a problem. This is one solution that doesn't involve popups, that I have actually used myself in a recent project. http://juicystudio.com/article/form-help-without-popups.html That solution works acceptably for 100% of users, regardless of their support for javascript, popup windows or any other feature. I think generalisations like "users hate popup windows" are perhaps a little unhelpful. But the statement is 100% accurate. I, as a user, hate popups. I know of many others that hate popups too. I did not say "all users", just "users". Regardless of how many users that is, are you really willing to annoy them? Is it not safer to avoid using popup windows, considering that people that don't mind them won't be at all upset when they don't see them; but those that hate them, will be if they do? I am sure a lot of people dislike popup adverts, but to dismiss all use of popups on this basis is clearly to throw the baby out with the bath water. I'm not just dismissing them on the basis that popup adverts annoy people, I'm dismissing them for serious usability and accessibility concerns, some of which I discussed earlier. Here's another: Every time you open an unrequested window (assuming my browser wasn't configured to block them completely), that's another window I eventually have to close. That's annoying, especially when I didn't request it. My mouse has a built in back and forward button and when you open a popup, those buttons don't work - there is no "close popup" button. It takes longer to move my mouse up to the close button than it does to push the back button with my thumb, which is just wasting my time on a tedious task I shouldn't have even been faced with. That is absolutely no better than using the target attribute. In fact, for accessibility reasons, it is worse. This is not true, Yes it is. I even gave an example to explain why. Just because your usability testing failed to test the scenario I presented, doesn't mean it doesn't happen. Also, because the button UI is usually turned off, You're assuming the browser is configured to let you turn off the chrome. That's another bad assumption, because browsers can be easily configured to always show the chrome that the user wants. there are fewer issues with users starting to surf in the new window and losing their window history, which is a problem using target _blank. So what if they started to surf with the new window!? Is there some rule against that? It's a browser window, just like the original, It clearly doesn't really matter whether they browse with that one or any other. What I really don't understand is that there are so many people who participate in this and various other mailing lists, newsgroups and forums that actively advise against using popups and explain why they hate them, yet you still somehow believe that users are ok with them. Newsflash: we are users too! Listen to us when we tell you outright that *we hate popup windows!* Do not use them, find a better solution. -- Lachlan Hunt http://lachy.id.au/ ** 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] TARGET in 4.01 Strict
Bert Doorn wrote: Serdar Kýlýç wrote: How does one open a new window with a 4.01 Strict DOCTYPE and have it be valid? For my weblog I ran the w3 validator and it complained that there is no attribute called target The users! Please, won't somebody think of the *users*! Many users hate popup windows. There are no valid use-cases or reasons for opening a popup window, don't do it. If you think you have one, I'd like to hear it, but know this: I've heard many excuses over the years (some more often than others) but every single one of them has been flawed in some way. The main idea is that one should not open new windows at all, leaving it up to the user to decide, which is why the target attribute was removed. Correct. But if you want to (or "have to"), either go back to transitional or use javascript. You may find some discussions about it in the mail list archives, but the simplest implementation would go along these lines: link text That is absolutely no better than using the target attribute. In fact, for accessibility reasons, it is worse. Good browsers, like Firefox (and probably many others), allow the user to easily disable the effect of the target attribute when it would cause a new window to open, without interfering with legitimate uses of it in frames (which are also evil). However, with window.open, the ability is not so easy. It is possible to do in Firefox. I do it myself, so that any call to window.open acts like a regular link and opens the page in the same window). However, it does have side-affects that an average user would find more difficult to cope with. Thus, while I personally find that both the target attribute or window.open() (when used like the example above) are of little concern [1], most users wouldn't be able to override the script as easily as the target attribute. Additionally, a user stylesheet may be used to indicate the presence of the target attribute, but not of that specific type of script, and so the user has no opportunity to take further action to prevent it (if required). Also, for those that don't know how to prevent even the target attribute from opening a new window, why should they be forced to accept them? Do you consider it a kind of opt-in/out feature, whereby unless a user explicitly requests not to see new windows, then they must be ok with them? [1] window.close(), on the other hand, is a pain in the *** thanks to a bug in Firefox, which has only recently been fixed in the trunk -- Lachlan Hunt http://lachy.id.au/ ** 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] [IE 6 Problem] -Container will not align centre to the page.
Omen King wrote: I have gone about creating this site for a class I have. I have been using in the past XHTML 1.0 strict but the doctype we must use is XHTML 1.1 Strict and it is giving me trouble. Firstly, XHTML 1.1 Strict doesn't exist, it's just XHTML 1.1. Don't confuse it with XHTML 1.0 Strict/Transitional/Frameset, there are no such variants for XHTML 1.1. Secondly, is your teacher aware of the fact that real world browsers don't support XHTML 1.1 properly, and that some don't support it at all? Most notably, no version of IE supports it - anyone who says (or tries to show) otherwise is lying. Perhaps my recent article would be an enlightening read for both you and your teacher. http://lachy.id.au/log/2005/12/xhtml-beginners I have already know the problem is some kind of rule issue. I am researching the problem currently but if anyone already knows the anwser it would be greatly appericated. Please view this page both in IE 6 and Firefox. http://www.monsterboxproductions.com/hwk/thedigitallibary/index.html It appears to work in Firefox, IE7 and Opera just fine (though, it really only "works" in IE thinks it's receiving HTML, not XHTML - it's a MIME type issue). I don't have IE6 available to test in without uninstalling IE7. However, you need to be aware that using the XML declaration triggers quirks mode in IE6 (they fixed that bug in IE7) and this may be the cause of your immediate problem. Remove this line: To fix any other problems correctly, it requires using the correct MIME type. The easiest way is to change the file extension to .xht or .xhtml and add this line to your .htaccess file on your server (create it if you don't have one, Google for ".htaccess files" for more info) AddType application/xhtml+xml .xht .xhtml (After doing this, you won't be able to view it in IE, only Firefox, Opera and other descent modern browsers, but you will learn a valuable lesson none-the-less) -- Lachlan Hunt http://lachy.id.au/ ** 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] Target sued over non-accessible site
Nic wrote: At which point does one's right to "do as one chooses" start stepping on another one's right to access services? Would we even *have* this discussion if people being refused access to websites were black and the refusal was because they are black? I really don't see the point you are trying to make here. There is no difference between refusing access to someone based on physical/mental disability (those that require assistive technology) and someone based on their race, culture, religion, etc. It's unnecessary discrimination either way. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
