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: [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] ***
[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] 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 ***
Re: [WSG] xhtml doctypes and charsets
Alan Trick wrote: On Fri, 2005-11-25 at 10:46 -0400, The Snider's Web wrote: "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> The meta element is effectively useless in XHTML, assuming you're serving it with the right MIME type. If you're serving it as text/html, then you may as well be using HTML 4. The other thing is that I don't think anybody besides the odd bot ever looks at those meta tags. That information belongs in your http headers. However, for text/html, in the absence of the information in a higher level transport protocol (like HTTP), browsers do look for encoding information within that meta element. Of course, it is preferred that such information occur in the HTTP headers (it is also a trivial exercise to configure your server properly to do that), but that meta element is better than nothing. For XHTML, application/xhtml+xml is the preferred MIME type and it's best to include encoding information within the XML declaration. -- 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] Extra menu for when images are turned off
Stuart Sherwood wrote: I have added a hidden menu to a site for those using text browsers or surfing with images turned off. The regular menu is image based but uses titles for accessibility, but this doesn't show in Lynx. Use the alt attribute to specify alternate text, use the title attribute to show advisory title information. The alt attribute will be rendered by lynx and other browsers without images enabled, the title attribute which is typically rendered as a tooltip in visual browsers may not even be seen by many users. I'd rather have a text based menu now but the client is happy and it is better than the drop down menu they wanted. Most image-based menus I've seen could usually be done just as well (if not better) using styled text. Unless the images have some fancy text styles on them that can't be easily reproduced using CSS, it's usually just as easy, if not easier, to use text with background images. I'm just wondering if there may be any disadvantages, for SEO or otherwise, by doing this? As long as the alternate text provided for any images is equivalent to the image, there shouldn't be any 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] page break up
Lori Cole wrote: Hi-I am new to CSS and strict. The URL I am having trouble with is http://members.cox.net/loricole.newhome.html. The style sheet is at http://members.cox.net.loricole/newtext.css. Please make sure you type the URIs correctly in the future and use '.' and '/' appropriately. http://members.cox.net/loricole/newtext.css http://members.cox.net/loricole/newhome.html The first problem I noticed in the CSS is that you have attempted to use comments like , , etc. These are HTML comments, not CSS comments. (Also note that the first is an invalid HTML comment, but that's really irrelevant in this case). You need to use CSS comments in CSS and HTML comments in HTML. CSS comments are: /* comment */ Fixing these issues may solve some of your 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] Extra menu for when images are turned off
Stuart Sherwood wrote:
Sorry, I forgot to mention that the menu uses CSS Sprit rollovers so
there are no images
in the markup, therefore no alt tags.
They're *attributes*, not tags, please learn the correct terminology.
Title tags are irrelevant for accessibility?
No, they're not irrelevant, but they need to be used appropriately and
cannot be depended upon for giving information to the user.
Put the text inside the a element and use CSS to hide it. There are
still some accessibility problems with this method, but until more UAs
support the 'content' property on any element, there's not much you can
do about it.
try something like this:
a { background: ...; text-indent: -2000px; text-decoration: none; }
Look up image replacement techniques for more alternatives.
--
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 up
Terrence Wood wrote: Lachlan Hunt said: is an invalid HTML comment how so? In SGML, the comment syntax is as follows: (Markup declaration close (MDC)) Only white space (or nothing) may occur between comments (except that no whitespace may occur immediately after the MDO). So, breaking up the above comment into components, we see: (start of comment 2, missing end "--") (Missing MDC) If it were XHTML, it would be well-formedness error. However, since it was occuring in CSS, it wasn't really an (X)HTML comment, it was just using the syntax and I felt it worthwhile to mention so that the same mistake isn't made within 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] CSS Validators
On Nov 23, 2005, at 5:42 PM, Geoff Pack wrote: Does anyone know of a downloadable CSS validator (other than the W3C one) that I can install on an local server to batch check files on my local network? We currently use the WDG html validator, but their CSS validator is not available for download. Firefox 1.5 and higher will report CSS errors in the JavaScript console. It won't do batch files, unfortunately, but I find it more convenient than a validator anyway, since it tells me as I'm writing and previewing them. -- 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 up
Jay Gilmore wrote: 2. When styling your the pseudo classes, hover, active, visited. The way to ensure that the cascade works is through the "LoVe HAte" a:link, a:visited, a:hover (a:focus), a:active. I read somewhere that there was is a Star Wars reference that takes the focus into consideration. Lord Vader's Handle Formerly Anakin http://mezzoblue.com/css/cribsheet/#lovehate -- 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 up
Terrence Wood wrote: Lachlan Hunt said: In SGML, the comment syntax is as follows: I believe your original comment was that it was invalid HTML. While similar, the SGML rule differs from HTML in it's treatment of whitespace, There is no formal difference between HTML4 and SGML comments, as HTML is an application of SGML which follows SGML rules. On the practical side of things, however, browsers will handle various forms of invalid comments in various ways, but that doesn't make them any less invalid, nor alter the formal HTML comment syntax. and the example you provided is, in fact, invalid HTML. Note that I broke the comment onto multiple lines in order to explain each component clearly, and I did mention that whitespace could not follow the MDO and that only whitespace could occur between comments. I thought it was clear that the notes in parenthesis were just that, and not actually part of the comment. The recommendation[1] That part of the rec should be treated as being informative, rather than normative. goes on to say authors should avoid multiple hyphens together in comments, however mulitple hyphens do not invalidate the document (otherwise, I presume, the recommendation would read MUST avoid multiple hyphens, and the validators would flag multiple occurances of them). It says *should* because it still uses SGML comment syntax, but authors should avoid using it because a) browser support is limited (and was much more limited at the time of writing) and b) most authors are unlikely to understand the SGML comment syntax, and it's advisable for authors to simply avoid strings of hyphens, rather than worry about all the technical details. If it said *must*, then that would not comply with SGML rules. eg. Run those through the validator to confirm that, if you like. [1] http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4 -- 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] Extra menu for when images are turned off
Stuart Sherwood wrote:
I think I have come up with a more elegant solution now.
There is only one menu with each link formatted like this:
Home
The br pushes the text under the header so it isn't visable to regular
users but accessable when images are turned off.
In that case, just use
a { padding-top: 1.2em; height: 0; }
(leave overflow: visible;, or it won't be visible without images)
Then make sure the header image does cover up the text. There's no need
to pollute the markup with unnecessary presentational uses for elements.
You may run into some trouble in IE with that because of the way it
treats 'height' somewhat like 'min-height', but you should be able to
get it to 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] page break up
Terrence Wood wrote: a comment in this format is not invalid HTML: If it's not followed by another '-->' later in the document with no extra '--' in between, then yes it is an invalid comment declaration. Where on earth did you get the idea that it is valid? The validator will certainly issue an error for that: Error unterminated comment: found end of entity inside comment Browser support is limited for HTML comment syntax? Which browser(s) would that be? IE/Win, for one, plus some (if not all) browsers in quirks mode. Also, at the time the spec was written, I seriously doubt NN4 and other browsers of that era supported them either.See the acid 2 test in IE, notice where it says ERROR on the page (near the bottom left corner). http://www.webstandards.org/act/acid2/test.html Also see the the different comment parsing modes in Mozilla (pick a DOCTYPE that triggers standards mode and compare with one that triggers quirks mode) http://www.mozilla.org/docs/web-developer/quirks/doctypes.html View the same tests in IE, and it will always show that comment parsing is in quirks mode -- 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] firefox 1.5 is official
Geoff Pack wrote: Can someone explain what the new Canvas element does that SVG doesn't? And why is it a new element instead of just using the Object tag? It's an implementation of this: http://www.whatwg.org/specs/web-apps/current-work/#scs-dynamic -- 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] firefox 1.5 is official
Ian Rifkin wrote: Now, a funny note. Firefox 1.5 has a new feature (under the help menu) called Report a Broken Web Site. I wanted to see what it was like so I clicked on it. Within the tool there is a link to a Mozilla Privacy Policy, but it's a dead link. A broken site? Just thought it was amusing. Bug filed. https://bugzilla.mozilla.org/show_bug.cgi?id=318210 -- 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] FF1.5 and Web Dev. T/B
Stephen Stagg wrote: Is it just me or does the 'Disable Images' option on the Web Developers Toolbar not work with FF1.5? Although this is off-topic for this list, I believe it's a known incompatibility in version 0.9.4 that appears to have been fixed in the latest beta version 0.9.9. http://chrispederick.com/work/webdeveloper/beta/ -- 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] editor
Lori Cole wrote: I am new to (trying to learn how) constructing standards conforming web pages using XHTML Since you're new, you might want to stick with HTML4 until a) browser support for XHTML increases (IE does not support XHTML), and b) you've learned and understand all the differences between HTML and XHTML (there's much more than just minor syntax differences). and would like to know what HTML editor you folks that are light years ahead of me would recommend? Like HTMLTidy? I find Dreamweaver 8 fairly good for hand coding. It's WYSIWYG editor is ok, it will produce relatively sensible markup, but I recommend avoiding such features until you're more confident and can control whatever rubbish they output. Even the best WYSIWYG editors will output rubbish for inexperienced users. I've also heard good things about HTML Kit, though I've never used it myself. http://www.chami.com/html-kit/ Avoid MS Frontpage like the plague, it will output rubbish for even the most experienced users. I am Windows based with IE v6 which I will soon be switching to Firefox based on this list. Make sure you test in at least Firefox 1.0.7 and 1.5. You'll also want to get a copy of Opera 8.5 and 9.0 preview 1. You may wish to test on earlier versions of Opera as well, but I wouldn't bother testing on anything lower than Opera 7. -- 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] editor
Matthew Cruickshank wrote: Lachlan Hunt wrote: Since you're new, you might want to stick with HTML4 until a) browser support for XHTML increases (IE does not support XHTML), Heh... please elabourate on how IE doesn't support XHTML. Try this in IE: http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML&withHeader=1 Oops, that's served as application/xhtml+xml, so it won't work. Here's the same article as text/html: http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML One other thing that doesn't seem to be mentioned in that particular article is that if you use the declartion (or, in fact, anything before the DOCTYPE), then it will trigger quirks mode in IE6 and below. IE7 will fix that particular bug, but still won't support XHTML properly. -- 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] XHTML Issues (was: Re: editor)
Matthew Cruickshank wrote: Lachlan Hunt wrote: http://www.howtocreate.co.uk/wrongWithIE/?chapter=XHTML ...if you use the declaration..., then it will trigger quirks mode in IE6 Right... rather than jumping to conclusions I was just wanting to make sure you were telling a beginner at html/css that "IE does not support XHTML" because of relatively minor things like http headers and xml declarations. Such things aren't "relatively minor". If you're not using the right MIME type, you may as well be using HTML4, as you're just relying on browsers error recovery techniques to understand XHTML. Plus, I'm sure you've read Ian Hickson's "Serving XHTML as text/html considered harmful" article?! Also, it's very important to be aware of the xml declaration issue, beginners must not learn to rely on quirks mode behaviour, they need to learn standards compliant behavior from the beginning, so it's important that it not be used. I didn't even mention other issues such as scripts, stylesheets, and the use of named entity references in XHTML, which are also important for authors to understand, but such a discussion would just take too long and it's much easier to tell a beginner to use HTML4 properly, than for them to try and understand all issues with XHTML when they don't have much experience with HTML. I'm a bit of a standards nazi, don't get me wrong, but I think you're misleading Lori. I don't. I think it's important for beginners to learn correctly from the beginning, not be mislead into thinking that they're using XHTML properly and thinking that it is supported by IE, when it's clearly not. I mean no one goes around saying Firefox doesn't support HTML and CSS because it doesn't pass the Acid test or implement soft-hyphens[1] There's a difference between limited support and absolutely no support. In the case of Firefox support for HTML and CSS, it has limited support and the soft-hyphen bug is just one of them that has been around for many years. In fact, no browser fully supports HTML4, but their support is sufficient enough for it be used, as most of the unsupported features (mostly SHORTTAG related) provide no additional expressive power over the supported ones. No browser fully supports CSS2.1 yet either, though some are very close. But, again, the support is sufficient enough for many of the features to be widely used. In the case of IE and XHTML, there isn't even limited support for it, there's none at all. There's only complicated error handling that manages to make sense out of all those extra slashes when it's parsing it as tag soup. -- 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] XHTML Issues
Bert Doorn wrote: I code in xhtml Strict and serve it as text/html. My code is future-proof, valid and well structured. Future proof from what? Do you really think any browser will ever drop support for HTML4? If I code in HTML4, there is less "need" for writing properly structured documents. Rubbish. It's just as important to write properly structured HTML as it is for XHTML, the only difference is that when served as XML, UAs will just give up, but tag soup parsers are much more lenient. In fact, it's that lenience you're relying on when serving XHTML as text/html. If at some point in the future browsers understand xhtml served as xthml, changing the way it's served is a relatively simple operation. Re-coding from HTML to xhtml (and unlearning bad coding habits) is not as simple. What bad coding habits are there that can be learned in HTML that can't be learned in XHTML as text/html? Plus, I'm sure you've read Ian Hickson's "Serving XHTML as text/html considered harmful" article?! One man's view, based on an assumption that people will write xhtml tagsoup. Even if they do, they will find out soon enough. How many sites claiming to be XHTML, but served as text/html, do you honestly think will survive the transition to application/xhtml+xml? I can't speak for others, but I write proper xhtml, not html tagsoup translated to xhtml. You might, but you do really expect beginners to when they're not seeing and learning from the actual results of an XML parser? I think we've had a thread about this article already, so will leave it there. Yes, the issue has been discussed to death in many forums, newsgroups and mailing lists, but there are clearly still some people that haven't got the message. In the case of IE and XHTML, there isn't even limited support for it, there's none at all. While technically correct, it is misleading, particularly for newbies, who might read it as "don't code in xhtml - people with MSIE will not be able to view your site". What's wrong with teaching them that? The fact is XHTML really should not be served as text/html, despite what the joke that is Appendix C says. (Also note that most sites claiming to be XHTML as text/html, don't conform to appendix C) It's not true if the page is served as text/html. If the page is served as text/html, then you're not really using XHTML, despite what the DOCTYPE says and the syntax used in the file may look like. I think it's important for beginners to learn correctly from the beginning. Exactly. Teach them properly structured xhtml 1.0 and serve it in a MIME type that the browsers people use can work with. Since when does using XHTML correctly involve using the wrong MIME type? Ready to reap the benefits of X(HT)ML later, when browsers support it. In theory, that sounds good. But the reality is, unless you actually developed the page and tested it under XML conditions, it's often not that simple. Here's a brief overview of the serious problems many people will encounter if they ever attempt to serve their XHTML as application/xhtml+xml if they've only ever tested it as text/html: Scripts * If you've used this very common and outdated comment trick, the script will be hidden from XHTML UAs: (the same applies to
Re: [WSG] Re: the basics of Firefox (was RE: [WSG] BBC E-mail: Overhaul for Firefox web browser)
Adam Morris wrote: If I uninstall everything, will I lose all my bookmarks, prefs etc.? No, you won't, that's not how it works. However, as has been said several times on this list, this is not a Firefox support list. Look up information about the profile folder, how to backup your bookmarks, passwords, etc, and how to create a new profile. Reinstallation usually won't fix problems associated with corrupted profiles. -- 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] XHTML Issues
Rimantas Liubertas wrote: It is pretty easy to check, all we need is some online tool which, given an url can resend page's content with application/xhtml+xml. Then grab those XHTML pages and see what happens. Try Hixie's content-type proxy. http://software.hixie.ch/utilities/cgi/content-type-proxy/content-type-proxy -- 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] XHTML Issues
Christian Montoya wrote: 2005/12/2, Lachlan Hunt <[EMAIL PROTECTED]>: Try Hixie's content-type proxy. http://software.hixie.ch/utilities/cgi/content-type-proxy/content-type-proxy Is this a trick? at the bottom of the page prevents it from handling xml. Any sort of xml. Now how am I going to test my XHTML pages What are you talking about? What ? It's certainly not being put there by that script, it must be present in your own XHTML. See, for example, w3.org as application/xhtml+xml http://software.hixie.ch/utilities/cgi/content-type-proxy/content-type-proxy?uri=http%3A%2F%2Fwww.w3.org%2F&type=application%2Fxhtml%2Bxml -- 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] UK Government Web standards - IE and serving issues...
Cameron Edwards wrote: Following some of the very interesting UK .gov mails of late, I've been involved in a fierce debate about serving XHTML 1.0 STRICT either as application/xhtml+xml or text/html, content negotiation and the like - whether, in fact, the world is ready for XHTML etc While I do strongly believe the future of the web lies with XHTML [1], the world is not ready for it yet, which is why I currently advocate that beginners learn HTML. Before XHTML can be used seriously on the web, here a few milestones we need to reach first: * Majority of UAs support XHTML (including Google, IE, lynx, handheld devices, etc.) * Support for incremental rendering. Gecko currently cannot incrementally render XHTML. * CMSs need to properly support XHTML, using XML tools that guarentee well-formedness and validity. * CMSs need to handle character encodings correctly (there are currently significant problems with blogs handling trackbacks from sites in a different character encoding) * CMSs need to be able to serve XHTML as XML to users that support it and transform to HTML for those that don't. (not just content-negotiation, I mean actual XSLT transformation (or equivalent) from XHTML to HTML) Plus, the following extras would be nice, but not essential: * ECMAScript for XML (E4X) widely supported * MathML, SVG, XForms, etc. widely supported (natively in implementations, not just plugins) Until such a time, there is little point using XHTML for any major corporate or government site, especially if you don't need to use any XML only features, like mixed namespaces, etc. By the way, for anyone interested, the next versions of XHTML, including XHTML 2.0 and the WHATWG's XML serialisation of HTML 5 (XHTML 5), are being defined so that they *must not* be served as text/html. [1] http://lachy.id.au/log/2005/04/xhtml-future -- 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] UK Government Web standards - IE and serving issues...
Patrick Lauke wrote: Daisy Could we drop the sexist (it's never a grandfather!), ageist digs at people who simply had the misfortune to be born 10, 20, 50 years too early? Replace my previous statement with something non-gender/non-age specific phrase to signify users who may have a average computer skills and are not tech savvy. I'll be sure to make sure all my future examples use "non-technologically inclined, gender indeterminent homo sapien" instead. Sure it's a mouthful, but we mustn't be sexist. -- 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] Newcomers and Web Standards (was editor)
Vlad Alexander (XStandard) wrote: Lachlan Hunt wrote: Lori Cole wrote: I am new to (trying to learn how) constructing standards conforming web pages using XHTML and would like to know what HTML editor you folks that are light years ahead of me would recommend? Since you're new, you might want to stick with HTML4 Lachlan, here is a classic example of a person new to Web Standards asking for a recommendation about which editor to use and instead you embroil this person in a debate over MIME types. My original advice to Lori did not include anything about MIME types or any other technical issues, I merely advised him/her that XHTML was not widely supported that there's a lot to learn about XHTML before one can use it; both points are true and I would expect anyone to give such advice to a beginner, before they go off and learn XHTML wrongly. I only brought up all the technical issues in order to defend my position, and if I wasn't able to defend my position, I would have lost credibility. Do you think this is a healthy environment for newcomers to learn about Web Standards? Yes. Why should we attempt to hide the truth from them, especially when they're just starting out and they need to lose/avoid any bad habits and mistakes as quickly as possible. Since you brought up MIME types and Hickson's article, let me say that you will get a lot more credibility for your argument if you stop referring to an article that is based on flawed assumptions. The assumptions are not completely flawed, and while the conclusion that authors blame XHTML may not be true in all cases, substitute "XHTML" with "browsers" or anything else commonly blamed by incompetent authors other than themselves, and the rest of the assumptions still hold true. But those assumptions you quoted from the article are irrelevant to the accuracy of the technical arguments within it. It is the technical arguments you need to dispute, not some introductory prose. -- 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] XML Declaration (was: Re: editor)
Gunlaug Sørtun wrote: An added advantage of including the 'xml declaration' is that IE7 won't be triggered by it. IE7 will simply skip it and treat 'xhtml 1.0' in 'Strict mode'. Therefore we have a built-in filter to avoid feeding IE6 styles to IE7, when our IE6 styles are using the old '* html' hack that IE7 will ignore when in 'Strict mode'. * html is supported by IE6 in any mode, there is no need to trigger quirks mode for it to be used. In fact, I have found no reason at all to ever intentionally trigger quirks mode in IE, and I'd be interested to know your reasons for doing so. All this "back and forth" is based on 'xhtml 1.0' served as 'text/html' and _treated as_ 'html 4' by every browser on earth. That's how I code and serve 'xhtml 1.0' today, with or without an 'xml declaration', and there are no actual problems involved when done right and assisted by 'HTMLTidy'. This is one of the myths I've been talking about in this thread. There are significant differences between text/html and application/xhtml+xml when it comes to handling scripts, stylesheets, erroneous markup and encoding information. XHTML *is not* merely HTML 4 in XML syntax, it comes packaged with all the XML handling requirements as well, with great big "Fragile" and "Handle with Care" stickers on the front of the box (metaphorically speaking). Well made and well prepared 'xhtml 1.0' with an 'xml declaration' is also ready for the next step - serving it as 'application/xhtml+xml'. That is assuming any scripts and stylesheets have been developed and tested with XHTML rules in mind. No advantage in that for the general web page/site at the moment, since no browser released (or to be released in the near future) by Microsoft will support 'xhtml 1.0' served as anything but 'text/html'. It is expected that IE8 will support XHTML, but the expected release schedule for it is (AFAIK) not publicly known, nor expected any time soon. My estimate is about 3 years away, with IE7 being about 6-12 months away. So, we have a choice whether to allow for the less demanding and not future-prepared 'html 4' to affect our coding-practices, or learn how to prepare for the future with well-formed 'xhtml 1.0'. Could you please explain what future needs to be prepared for with HTML 4? Are you expecting that browsers will drop support for it some time in the future, thus leaving any page not converted to XHTML inaccessible? Are you expecting browsers to start choking on invalid HTML 4? Are you expecting something else about HTML processing to significantly alter the way existing documents are treated and rendered? While I do believe XHTML will play a big part in the future, the future is not here yet and we have a long way to go before then. -- 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] Newcomers and Web Standards
Matthew Cruickshank wrote: Lachlan Hunt wrote: Yes. Why should we attempt to hide the truth from them, especially when they're just starting out and they need to lose/avoid any bad habits and mistakes as quickly as possible. Yours is a fringe and pedantic opinion, and you're being ridiculously harsh on XHTML. I have not been harsh on XHTML at all, I do like XHTML and it does have a lot of benefits when used properly, but if it's going to be used, it really needs to be done right and fully understood for what it is, or it should not be used at all. HTML is already broken beyond all repair because of all the broken implementations and people doing it wrongly without caring about the consequences, and I don't want that to happen with XHTML. Although with the number of people jumping on the XHTML bandwagon just because it's the latest and greatest standard, believing the myths that it's widely supported, usable and that their doing it correctly, when the vast majority of authors clearly aren't, has already done more damage than good. I might add that my "fringe and pedantic opinion" is based on fact, and that not one valid technical argument has yet been raised in this thread against any of the technical reasons I've posted. Additionally, a significant portion of the replies against me have been little more than judgements about how appropriate it was or was not for me to give such advice to a newcomer; which is not very constructive at all. I'm glad that people have been speaking up so that hopefully Lori will see that it's not so black and white an issue. I'm happy for people to speak up and challenge my views; in fact I encourage it, that's part of what forums like this are for and opinions that can't stand up to such challenges are not worth retaining. I realise the issue is not so black and white for some people, hence why this topic has been and will rehashed again and again on every forum, newsgroup, mailing lists, blog and whatever else around the world for a very long time. So, let it be discussed, and let the newcomers benefit from such discussion, but lets keep the discussion on the issue, rather than attacking another person's views without backing up your own with valid, technical arguments. -- 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] editor
Artemis wrote: I'm confused lol. My personal site is XHTML and I don't get any popup box when viewing in IE. That is because the MIME type sent in the HTTP Content-Type header would be set to text/html. As has been discussed in this thread, the correct MIME type is application/xhtml+xml, but because IE does not recognise that, it offers the user the choice of what to do with the file (save or open with another application). What is this used for? Why would the average personal site need it? If you could explain in "beginner speak", I would greatly appreciate it :) The XML declaration is supposed to be used to define the version of XML being used (not to be confused with the actual markup language version number, as in XHTML 1.0 or XHTML 1.1), the character encoding of the file and whether or not the it's a standalone document (but I won't go into the details about the standalone attribute, it's rarely needed). The syntax looks like the following and, when present, must occur on the first line of the file with no whitespace or other text before it (except maybe a UTF-8, -16 or -32 Byte Order Mark (BOM)) The version number refers to the XML version. There is currently only XML 1.0 and XML 1.1. Most XML that people write (including XHTML, MathML, SVG, etc.) is XML 1.0. There are significant differences between 1.0 and 1.1, but I won't go into detail here. Basically, unless you have a specific need to use XML 1.1, then use 1.0. Be aware that an XML 1.0 parser that was not built for XML 1.1 as well, will fail with a well-formedness error if version="1.1" is encountered in the declaration. For XML 1.0, the XML declaration is optional. The encoding determines the actual character encoding of the file. This can be any encoding name you like, preferably one defined by IANA. The encoding attribute may be omitted, and in the absence of such information from a higher level protocol (e.g. the HTTP Content-Type header), the default for XML is UTF-8 or UTF-16. XML user agents will thus attempt to use either of those, determined by the presence or absence of the BOM. The BOM is a essentially special Unicode character (U+FEFF) used for determining the particular UTF encoding, based on how the character itself is actually encoded within the file. There is also a standalone attribute that can be set to "yes" or "no", but as I said I won't go into the details of what it means, it's quite confusing and you normally just leave it out. Lastly, it is important that the version and encoding attributes appear in that specific order. It is not well-formed to write this: As I said, the encoding attribute may be omitted, if the encoding is UTF-8 or UTF-16 (or if it is specified in a higher level protocol), so this is well-formed: If you are using XHTML and serving it as text/html, it's best to leave it out because anything before the DOCTYPE declaration will trigger quirks mode in IE, which is basically a mode that uses intentionally buggy, backwards compatible parsing and rendering behaviour reversed engineered from obsolete 4.x era (and earlier) 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] Newcomers and Web Standards
Vlad Alexander (XStandard) wrote:
Lachlan, you have been on this list long enough to know that when you
make extreme statements such as "since you're new, you might want to
stick with HTML4" or "IE does not support XHTML", that debate will
ensue.
So be it. If there are still people that don't understand XHTML for
what it is, yet blindly attempt to use it, then the issues need to be
discussed.
This is not what newcomers to Web Standards need. A better
approach would have been to ask why this person needs/wants to use
XHTML and if he/she has a good reason to do so, give this person
advice on how to do it right.
Thank you for this very constructive advice, in future I will be more
careful about how I phrase such things. But my message still stands:
XHTML is not appropriate for an inexperienced HTML author to use,
particularly with the current level of browser support.
To address your statement that "IE does not support XHTML" - this is
not true. IE does support XHTML 1.0 - you and I just don't like the
level of support IE offers.
No, the fact is that IE has no native support for XHTML at all. By the
same logic you're claiming that it has limited support, then I could
invent my own FooML language using similar element names and attributes
to HTML, register the MIME type application/fooml+xml for it to use,
serve it as text/html and claim that IE has limited support:
http://example.org/fooml/dtd";>
http://example.org/fooml/namespace";>
This is a FooML Document
If I serve this as text/html, then IE will seem to support it.
I can even use scripts with a MIME type it it doesn't normally
recognise.
alert("Hello World!");
// Since "content-type" is an non-existent attribute in HTML,
// the MIME type is ignored and tag soup browsers assumes it's
// JavaScript, even though most current browsers only widely
// recognise text/javascript.
Would you agree that IE has no support for FooML, or would you claim
that it has limited support because the result is acceptable, when
served with the wrong MIME type?
If you serve valid XHTML as HTML to IE, will there be any data loss? No!
If you serve invalid, ill-formed XHTML to any browser as text/html, will
there be any data loss? The answer is the same, but that doesn't make
it right.
Now, I don't want to give Hickson any more of my attention. But I
will say that he and his groupies are not interested in teaching
people how to use XHTML correctly.
I am interested in teaching people to use XHTML correctly, but
experience shows that newcomers are far better off sticking with HTML4
until they are confident enough to fully understand the ramifications of
using XHTML.
If we want to teach XHTML correctly, I'm all for doing so, but *we
should actually teach XHTML /correctly/*. Despite any objections to the
contrary, that means using the correct MIME type and gaining a full
understanding of all the differences between HTML and XHTML, rather than
just doing half the job by teaching them the syntax, getting them to
throw in a few extra slashes and leaving it at that, thinking the rest
is all the same as HTML. That is *not* teaching them correctly, and
it's doing much more harm than good.
--
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] editor
Christian Montoya wrote: On 12/3/05, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Be aware that an XML 1.0 parser that was not built for XML 1.1 as well, will fail with a well-formedness error if version="1.1" is encountered in the declaration. For XML 1.0, the XML declaration is optional. Wait, so you are saying that I could serve application/xhtml+xml to modern browsers without the xml declaration? What about declaring the stylesheets in xml declarations at the top of the document? I thought that was required. There is a difference between the XML declaration and other processing instructions, although they do look similar as they begin with end with ?>, but their similarities end there. For XHTML, the xml-stylesheet PI you're referring to: is only useful for a generic XML user agent that is not aware of the XHTML NS, and thus doesn't recognise the style element or a link element that refers to a stylesheet. In which case, the UA won't even have a default UA stylesheet for it and your styles designed for (X)HTML with such a stylesheet in mind, may not look any good under such conditions anyway. Such a UA probably wouldn't recognise the ID attribute as being of type ID (unless it read the DTD), in which case the example [1] given in Appendix C is quite useless. It might have a better chance if xml:id were used instead, but would still require an xml:id implementation. [1] http://www.w3.org/TR/xhtml1/#C_14 -- 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] Newcomers and Web Standards
Matthew Cruickshank wrote: Lachlan Hunt wrote: I might add that my "fringe and pedantic opinion" is based on fact, and that not one valid technical argument has yet been raised in this thread against any of the technical reasons I've posted. Ah, but the argument is not strictly one of technicalities -- it's a matter of opinion about what is sufficient support and what compliance means. You've arbitrarily decided that IE has sufficient support for HTML but not XHTML, That's because IE's parsing and rendering engines were not built with XHTML processing in mind at all, they were only built HTML in mind. The fact that XHTML is compatible with such broken HTML parsers is irrelvant to the fact that it doesn't actually support it at all. MIME types are what matters, DOCTYPEs don't (except insofar as quirks/standards mode are concerned). Regardless of what the DOCTYPE says and the syntax used, if it's labelled as text/html, it's HTML, albeit very likely invalid HTML that relies on the undefined and reverse engineered error handling behaviour of browsers to support it. that the internal rendering engine affects XHTML compliance The rendering engine itself doesn't affect the compliance of the document, the MIME type it's delivered with, however, does; and the idea of using the wrong MIME type to trick some ancient browser into doing something useful with the document is ludicrous. How many XHTML as text/html documents out there do you think actually conform 100% to the guidelines set forth in Appendix C? Virtually nil! None of these opinions is based on W3C standards, and so it's difficult to refute your ideas. There are no W3C standards on this matter, or at least none that can be taken seriously. XHTML 1.0, section 5.1 Internet Media Type states: | XHTML Documents which follow the guidelines set forth in Appendix C, | "HTML Compatibility Guidelines" may be labeled with the Internet Media | Type "text/html" [RFC2854], as they are compatible with most HTML | browsers. Those documents, and any other document conforming to this | specification, may also be labeled with the Internet Media Type | "application/xhtml+xml" as defined in [RFC3236]. For further | information on using media types with XHTML, see the informative note | [XHTMLMIME]. Although that section claims to be normative, it references an *informative* appendix and *informative* note. Appendix C has been successfully disputed many times and because it's informative, it can't be normatively referenced anyway. So, while technically serving XHTML as text/html is allowed, that doesn't make it a good idea. All the purported benefits of XHTML are nothing short of meaningless in a text/html environment, so why bother teaching it to newcomers, when there is sufficient evidence to show that the vast majority learn it wrongly? This is not another opportunity for you to derail this thread with more technical references. No one disagrees with that -- this thread is about how it's best to teach people web standards. And you fail it. It is about both. They are not mutually exclusive topics, you can't talk about the reasons for teaching XHTML without talking about and satisfying the technical reasons for using it in the first place. -- 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] XML Declaration
T. R. Valentine wrote: On 03/12/05, Christian Montoya <[EMAIL PROTECTED]> wrote: If your server is sending the MIME type text/html, then the META doesn't do anything. You need to change the MIME type being sent out in the headers, and that is done server side. The only reason the meta element contains text/html, is so that it conforms with the syntax of an HTTP header. Since at least the Content-Type needs to be sent with the HTTP headers (or other higher level protocol), the MIME type specified in the meta element is essentially meaningless. Theoretically, the meta element is supposed to be able to be read by a server prior to sending the file to determine the HTTP headers to be sent, but I don't believe any servers in existence, or at least in use, actually do so. Browsers will try to determine the encoding from the meta element, if it's not specified in the HTTP headers, but the HTTP headers must always take precedence. Thanks for that explanation. But what about when simply opening the .html file in a browser, no server involved? Even there I do not see a difference in IE between the two forms. When opening from the local file system, browsers typically using the file extension to determine the MIME type. .html is generally associated with text/html, and that is the MIME type used. This is a summary of file extensions and their commonly associated MIME types: .xml application/xml (preferred) or text/xml (not recommended) .xht .xhtml application/xhtml+xml .htm .html text/html If you create some files with these extensions and open them up in Firefox. Then go to Tools > Page Info, and notice where it says 'Type:' followed by the MIME type used. This info is also available in Opera and possibly other browsers too, I just can't remember where to find it. If you create an ill-formed XHTML document, save it as two separate files: one with .html and the other with .xhtml, and open the up in IE and Firefox. The results will be something like this: .html opens normally in any browser .xhtml Firefox will report well-formedness errors, page info dialog will typically show application/xhtml+xml. IE will either offer a save as dialog or cause it to open in your default browser (it opens it with Firefox for me, because that's my default browser, your system may be 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] Newcomers and Web Standards
Lori Cole wrote: I was a science major in college and went into biotech which is dominated by men. Your advice to me as a newcomer to just stick with HTML4 rather than to try to learn the right way to use XHTML right off the bat reminded me of the experiences I have had in science that I believe have been sexist. I have no idea how you could have interpreted my advice as being sexist in any way. In fact, I had no idea whether you were really male or female; because experience tells me that guessing a persons gender in an online community based on their name, when I know nothing of their culture or country of origin, is often an incorrect guess, so I assure you my comment was not meant as discriminatory in any way whatsoever. My advice comes purely from my experience. Evidenced by the fact that the vast majority of people who attempt XHTML, often fail miserably to grasp the differences between HTML and XHTML. Not only are most sites claiming to be XHTML served as text/html not even well-formed, they often suffer from any number of other problems I have mentioned in this thread, and any future attempt at simply changing the MIME type will fail miserably. If you choose to learn XHTML, I strongly advise you to gain a very good understanding of valid, semantic, non-presentational HTML first; you can't even begin to grasp the differences between HTML and XHTML if you don't know HTML first, let alone gain any serious benefit at all from using XHTML. I urge you to prove me wrong, and show that you can learn XHTML correctly as a beginner without much HTML experience, but please understand that you are not the first to try, nor will you be the last, and the odds are not in your favour. If you must go ahead with XHTML, then please at least develop and test your pages in an XML environment, even if you end up serving your pages to the world as text/html. Learning and developing XHTML in a text/html environment is a recipe for disaster. -- 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] Newcomers and Web Standards
Vlad Alexander (XStandard) wrote: User agents come and go, so how one browser parses markup is so trivial in the larger scheme of things. What is really important is content. If people write content in HTML they are creating legacy data because it is not easily parsable from a content management perspective. Yes it is, it just requires SGML tools, instead of XML tools. This all comes down to using the right tool for the job. Content written in HTML cannot easily be re-purposed. If you have 1,000 documents and you want to change some markup in all of them, it is very difficult to do this if these documents are in HTML. If the documents are in XML (XHTML), then this is a trivial task using off-the-shelf technologies like DOM/SAX parsers or XSLT. The same is true of HTML, it just requires that you use SGML tools to process it, rather than XML tools, and SGML tools have been available for much longer than XML tools; they're just not so widely deployed because HTML is rarely treated as an application of SGML anyway. Since, as you say, it's trivial to use such tools for XHTML, it's also trivial to convert from XHTML to HTML 4 on the fly using XSLT or some other method. So we need to start writing content in XML and if it's content destined for the Web, then XHTML is perfect. The next step is: if you write it in XHTML, then why not serve it in XHTML (even if right now it's still processed by some current browsers as HTML). Such use cases require XML tools, with a CMS that uses such tools to guarantee well-formed input and output. It also requires that the author be competent enough to develop and test and a completely XML environment, even if it's delivered to the world as text/html. I do agree that XHTML on the back end does have significant authoring benefits for those experienced and competent enough to do so, but we're talking about beginners who are unlikely to have such tools at their disposal and are extremely likely to be developing and testing in an HTML environment. As I have said many times, learning XHTML that way is not a good idea, and it is the responsibility of those of us teaching it to make sure it is learned correctly, not incorrectly as you seem to be pushing. Additionally, how many commonly used, off-the-shelf CMSs that claim to output XHTML as text/html, or in fact any CMS regardless of its output, actually make use of XML tools? WordPress certainly doesn't, it uses string substitutions and doesn't guarantee well-formed output, as do others such as MovableType, Blogger, etc. I challenge you to name several readily available off-the-shelf CMSs that actually do make use of XML tools. As of yet, I have not found any that do, let alone guarantee 100% well-formed output. -- 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] XML Declaration
Gunlaug Sørtun wrote: I'm more or less aware of how easy it is to mess things up, so for the last 2 years I've used the following procedure: - Creating an xhtml 1.0 document. - Cleaning out 'human bugs' in HTMLTidy -> 'convert to xml'. - Serving it as 'xhtml' with the extension '.xhtml' to browsers that can make anything out of it - Opera, Moz/FF, Safari - internally and on line. Info: application/xhtml+xml - no errors - no apparent problems. - Changing the extension down to '.html' to get wide-spread support, with no additional changes to the document. - Run it through any browser I care to support - and maybe a few others and the validator for good measure - no apparent problems. Is this enough 'real world' testing in order to secure quality of code so it can be served as either 'application/xhtml+xml' or 'text/html' by choice ? Yes, because you have developed and tested under both XHTML and HTML conditions, you already know your pages will survive the transition to true XML when the time comes. You would have already worked out any incompatibilities between the handling of scripts, stylesheets, encoding issues, etc. You are clearly not a beginner and you have made a very informed choice, and that is fine. Beginners, however, would not, nor can they be expected to be aware of all these issues and more often then not, develop XHTML in a purely HTML environment. It is this that will cause all the problems in the future, if they ever attempt to switch to true XML, and why I very strongly advocate that beginners start with HTML, not 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] standards or confusion?
ows what type of file it is. In many ways, this is indeed the case, but there is a necessary step in between that is not quite so obvious. Common file extensions are typically associated with specific MIME types. For example: .htm .html text/html .xht .xhtml application/xhtml+xml .gif image/gif .jpg .jpeg image/jpeg .png image/png .txt text/plain .pdf application/pdf etc. So, although the file extension is commonly used for determining the MIME type, it is the MIME type that the browser should use to determine what the file is and thus what to do with the it. When the web server receives a request for a file, it needs to determine what type of file it is and, thus, what it should tell the browser when it sends the file. It is common for web servers to make use of the file extension to determine how to process the file. This is how it knows to execute .php, .asp or .jsp files, for example, and also how to serve .html, .png, .jpg, etc. But, for the browser receiving the file over the web (usually via HTTP), the file extension is meaningless and can be left off the URI completely. This information is sent to browser (preferably including character encoding information for text/* documents) using the Content-Type HTTP header, and should look something like this for HTML: Content-Type: text/html; charset=UTF-8 Unfortunately, charset information is generally left out of the HTTP headers and so for most sites, it will simply be: Content-Type: text/html That may look somewhat familiar to you, if you ever used this meta element in your document: In HTML only, the meta element is an inferior attempt at providing this information within the document itself, but it is not a proper substitute for real HTTP headers, the HTTP headers always take precedence. For XML, that particular meta element is not used by the browser at all, under any circumstances. As mentioned previously, XHTML really should be served with an XML MIME type, such as application/xhtml+xml. Technically, any XML mime type should work if both it and namespace are known to the web browser, but that is the preferred MIME type to use. When you use text/html, HTML parsing and rendering rules are applied. Regardless of any XHTML DOCTYPE you use, XML rules are not applied, well-formedness errors are handled like any other erroneous HTML document, the DOM will be generated and worked with, and CSS will be applied according to HTML rules. When you use an XML MIME type, XML parsing and rendering rules are applied. This means that XML well-formedness errors will be fatal and the user will typically see the "Yellow Screen of Death" (in Mozilla based browsers), the DOM will be generated and worked with, and CSS will be applied according to XML rules. This means that any scripts or styles written and tested under HTML conditions may not function as expected in XML conditions. As I mentioned earlier, the MIME type is used by the browser to determine what to do with the file. Because IE is not aware of what application/xhtml+xml means, it doesn't recognise it as an XML document and asks the user what to do with it (either save it or open with another application). -- 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] Newcomers and Web Standards
Vlad Alexander (XStandard) wrote: Lachlan wrote: I challenge you to name several readily available off-the-shelf CMSs that actually do make use of XML tools. Here comes shameless self promotion - any CMS that uses XStandard. I meant on the back end. The use of XStandard on the front end doesn't guarentee well formed input or output from all sources. What about user's leaving comments with embedded markup, trackbacks, pingbacks, etc. What about stripping and replacing named entity references? What about handling character encoding issues properly, which is supposed to cause fatal well-formedness errors (although it doesn't in Gecko). What if a user doesn't install the XStandard plugin and just uses a text area for input? All of these issues require proper XML processing on the back end, and you can't seriously claim that all CMSs using XStandard on the front end, do so on the back end too. Plus, you still run into trouble when the user includes scripts and styles written for text/html and untested in XML. -- 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] Newcomers and Web Standards
Alan Trick wrote: If you want another potentially good thing gone bad from missuse you don't have to look any furthur than RSS and it's 9 (I think, but it could easily be higher) almost completely incompatible versions. It was 10 at last count, 9 mentioned here http://diveintomark.org/archives/2004/02/04/incompatible-rss plus RSS 1.1 which was developed a little more recently. http://annevankesteren.nl/2005/01/rss-11 That leaves Atom 1.0 as the only feed format people should bother using, now that Atom 0.3 is officially deprecated. -- 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] standards or confusion?
Bob Schwartz wrote: Lachlan, By far, the most important issue facing beginners with regards to standards is the separation of semantics, presentation and behavioural layers into well structured, valid, non-presentational markup; CSS and javascript, respectively, and it sounds like you've already made significant steps toward these goals already. Just to be clear I've understood a concept you mention above, could you show an example of javascript used as layered, non-presentational markup and one that is not? When you mix behavioural attributes within the markup, like onclick, onmouseover, etc. or javascript: pseudo-URI schemes, that's the behavioural equivalent of including presentational attributes within your markup. Instead of using those attributes, the best practice is to attach event listeners dynamically instead. For example: Bad: evil popup Better: not-so-evil popup Good: Not an evil popup
Re: [WSG] how to emulate in xml
Torgny Rasmark wrote:
We cannot find a way to give an arbitrary element the characteristics of the html
element.
CSS 2.1, section 12.2 [1] states:
| Authors may include newlines in the generated content by writing
| the "\A" escape sequence in one of the strings after the 'content'
| property. This inserted line break is still subject to the
| 'white-space' property.
foo::after { content: "\A"; white-space: pre; }
linebreak
foo { ... } will also work, but Opera is one of the only browsers (if
not the only one) to support 'content' on any element, rather than just
::before and ::after pseudo-elements.
[1] http://www.w3.org/TR/CSS21/generate.html#content
--
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] standards or confusion?
Bob Schwartz wrote:
Below are a couple of "real world" (my world, anyway) javascripts, could
you re-do them as per "Good", then I would have an example for
reference that I could closely relate to.
These connected to a linked JS in the :
1. http://www.fotografics.it";
onclick="popUp(this.href,'elastic',500,650);return false;"> powered
by: FotoGrafics
The most unobtrusive version of this one is simply:
http://www.fotografics.it";>powered by: FotoGrafics
No script required. You won't get a new window for most users, only for
those that explicitly request it themselves. Otherwise, try this article:
http://www.alistapart.com/articles/popuplinks/
2. onfocus="P7_trigNV('p7NVim10')" onblur="P7_trigNV()"
onmouseover="P7_trigNV('p7NVim10')" onmouseout="P7_trigNV()">src="as/im/v2_01.jpg" alt="" width="88" height="25" id="p7NVim10"
/>
Those function names suggest that this was generated with a WYSIWYG
editor. That's never a good idea.
It depends on the purpose of the functions, but if they're simply
changing presentational issues (which is what they're commonly used
for), you could use a:hover and a:focus pseudo-classes in CSS to style them.
If not, then you need to find a way to access the a element (either
using a class, an id or some other method and then attach the methods.
var a = ... // get the element.
a.addEventListener("focus", P7_trigNV, false);
(make sure you omit the parenthesis from the end of the function name.
don't use P7_trigNV(), it won't work as exptected)
Unfortunately, that won't work in IE unless you use a DOM 2 patch script
to add support for it like I do, but the script I wrote and use isn't
quite ready, as it still suffers from memory leaks and a few other small
limitations.
a.focus = P7_trigNV; works in all browsers, you can use that instead.
You shouldn't need to pass the id of the image to the function, you have
access to the a element from the event handler, so you just need to get
it's child image element.
Since I'm guessing all this function actually does is swap the image,
you don't need JS, just use CSS image rollovers. There's many
techniques available, try google.
3.
function init() {
P7_setNV('p7NVim10',2);
P7_trigNV()
}
Then use either of these to attach it:
document.addEventListener("load", init(), false);
(won't work in IE or firefox without a patch)
or
window.onload = init;
(non-standard, but widely supported. Limited to a single function.)
You could also look up the addEvent() script.
This one all alone on the page, with no linked JS in the :
var d=new Date();
yr=d.getFullYear();
if (yr!=2003)
document.write("© "+yr);
Cedar Tree Books
© 2005 Cedar Tree Books
No script (or entity reference) required.
--
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] standards or confusion?
Bob Schwartz wrote:
This one all alone on the page, with no linked JS in the :
...
document.write("© "+yr);
Cedar Tree Books
© 2005 Cedar Tree Books
No script (or entity reference) required.
I'm going to take your much appreciated response one bit at a time.
By doing as you suggested, I lose the point of having used the JS in the
first place.
I realise that, but by using javascript to output content, you're not
really separating the layers. You could use a server side script to
generate it or simply use a serve side include file in all your pages,
where you would only have to update it once.
If you really want the client side script, you could do something like this:
© Cedar Tree Books
var txtCopy = document.getElementById("copy").childNodes.item(0);
var year = (new Date()).getFullYear();
txtCopy.replaceData(1, 0, " " + year);
--
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 check please - mime type!
designer wrote:
Forgive my labouring the point, but after our discussions I have done
what Gunlaug did, i.e., made a page as xhtml, with the headers as below:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
The Area
Changing the MIME type in the meta element is completely useless, as the
application needs to know the MIME type in order to know how to parse it
*before* it begins parsing. Once it has reached that meta element,
parsing has already begun. It is the MIME type sent by the server in
the HTTP Content-Type header that matters, and for your page it sends
text/html.
See the HTTP headers:
http://cgi.w3.org/cgi-bin/headers?url=http%3A%2F%2Fwww.rhh.myzen.co.uk%2Frhh%2Fthearea%2Farea.php
You may see what happens when the page is really served as
application/xhtml+xml.
http://software.hixie.ch/utilities/cgi/content-type-proxy/content-type-proxy?uri=http%3A%2F%2Fwww.rhh.myzen.co.uk%2Frhh%2Fthearea%2Farea.php&type=application%2Fxhtml%2Bxml
Note: The reason the stylesheet isn't applied at all in this case has
nothing to do with it being served as XML, it's only because it's linked
with a relative URI and via that proxy, it no longer points to the right
place. If you change all paths to absolute URIs pointing to your server
and the result will be better. It does, however, demonstrate that your
page is at least well-formed.
I saved as xhtml and IE went daft. I saved as html and all seemed fine.
However, the site I'm working on has a fair bit of PHP in it, so I saved
it as .php. All seems fine, including IE.
Because it's php, you can use the header() function to send the correct
Content-Type header. Place this before any content is output.
header("Content-Type: application/xhtml+xml");
However, doing so will lock out any IE users and Google, but you may as
well completely remove the meta element, because it's only an inferior
substitute for real HTTP headers. Use this instead:
header("Content-Type: text/html; charset=UTF-8");
If you choose to do content negotiation and serve application/xhtml+xml
to browsers that support it and text/html to those that don't, be aware
that it prevents incremental rendering in Mozilla.
You can see my test page at:
http://www.rhh.myzen.co.uk/rhh/thearea/area.php
So, my seemingly silly question is: Is this OK? Does it fall apart for
anybody? (mac esp?)
and, of course, is it OK to do this, and indeed, is this what I 'should'
be doing (Lachlan?)
You may as well just use valid HTML 4.01 Strict. See "XHTML is not for
Beginners", the MIME type issue is just one of the many reasons.
http://lachy.id.au/log/2005/12/xhtml-beginners
(yes, I'm aware of the irony that the article itself is XHTML as
text/html, but that's the useless default wordpress template that I'm
too lazy to fix up)
Lastly, with regard to the style element within the page:
/*<![CDATA[*/
<!--
@import url("../css/areastyle.css");
-->
/*]]>*/
You may as well remove the fake XML comment () in there,
it's effectively useless these days, although keeping it as is will do
no harm because of the CDATA section.
Keep the /**/ in there, they're the most effective
way to handle the different parsing requirements of HTML and XHTML. See
this article that discusses the issue in great detail:
http://lachy.id.au/log/2005/05/script-comments
--
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 check please - mime type!
Gunlaug Sørtun wrote: Lachlan Hunt wrote: http://lachy.id.au/log/2005/12/xhtml-beginners I am prohibited from getting comments through to that article. That's weird, if you contact me off list and let me know what error you received I might be able to do something about it. If you send me your comment, I can add it for you. However, it isn't important to me, since I can make up my own mind about the subject anyway. Hope others are able to do that too. As I wrote in the article, those who are competent enough to make an informed decision may do so. Beginners who've never even built a web page before can hardly be considered as knowledgeable on the subject and wouldn't be able to make a fully informed 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] Valid alternative to textarea WRAP
Sarah Peeke (XERT) wrote: Just wondering if there is an altenative to textarea wrap="soft" (for e.g.) that validates. Just wondering why you need it. In which non-obsolete browser does the value soft have any effect upon rendering or submission? -- 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] Valid alternative to textarea WRAP
Sarah Peeke (XERT) wrote: Lachlan Hunt wrote: Sarah Peeke (XERT) wrote: Just wondering if there is an altenative to textarea wrap="soft" (for e.g.) that validates. Just wondering why you need it. In which non-obsolete browser does the value soft have any effect upon rendering or submission? I'm modifying some of the Zen Cart code to ensure validation. That doesn't answer the question and explain *why* you need it. The FF Tidy plugin gives a warning on the wrap attribute, and I'm hoping to do a find and replace to fix it. Soft is the default value, so it's completely unnecessary. Remove 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] Valid alternative to textarea WRAP
Bert Doorn wrote: The FF Tidy plugin gives a warning on the wrap attribute, and I'm hoping to do a find and replace to fix it. Does that (proprietary) attribute actually do anything in any browser? It's being defined to accept the values "soft" and "hard" and determine whether or not line breaks are retained in form submission. http://www.whatwg.org/specs/web-forms/current-work/#extensions1 -- 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] real xhtml - last question!
designer wrote: However, the css behaves differently - the body background colour is not showing in the xhtml version, but the background image shows OK . . . ... Is this to do with relative and absolute links again, or what? No, that was when I linked to the content-type proxy. The relative paths didn't work because the page was routed through a different server. -- 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] italic and validator
Donna Jones wrote: is "i" (italic) deprecated in xhtml? No. Also, deprecated elements appear in Transitional DTDs, but not in Strict DTDs. This applies to both HTML 4.01 and XHTML 1.0. It does not apply to XHTML 1.1, which contains mostly the same elements and attributes as XHTML 1.0 but there are some significant differences. and even better, could someone point me to a w3c page that talks about what is deprecated in xhtml? This is the table of elements for HTML 4.01 and XHTML 1.0. http://www.w3.org/TR/html401/index/elements.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] CSS and the University Syllabus
Paula Petrik wrote: For example, I have been including a table on the schedule page of the course sites to delineate what's to be done when because it seems to be tabular data--"week" in one column and "work" (of various kinds) in another. (Yes, I have lived in fear of the Table Police.) I have tried to do the schedule using divs, but it seems hopelessly complicated and not worth the effort... Here are some examples from the past term: http://archiva.net/hist120ay05/hist120ay05_schedule.htm Your use of a table is indeed correct, the data is very much tabular. Please don't live in fear of the table police, anyone who tells you tables should never be used, unconditionally, doesn't know what they're talking about. Tables are only frowned upon when they are used to mark up data that is not even remotely tabular, simply to achieve visual layout. -- 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] JK Rowlings and Accessibility
Stephen Stagg wrote: Jared Smith wrote: Felicity Farr wrote: I love the attitude of the big players...provide a text alternative and it's instantly accessible. ... I'm no lawyer, but it sounds to me like using a text-only page as an excuse for otherwise inaccessible content is a violation. I'm no expert, but I thought that Flash WAS inaccessible and therefore when designing a flash-based site, compliance cannot be accomplished in any other way BUT by having a text alternative. It's necessary to have alternative content, but there is no reason for the alternative content to be nothing more than plain text. Good alternative content to flash would include relevant images, videos, audio, etc. Each of those should then also have appropriate alternate content. It should be built to look something like this diagram: __Flash__ / | | \ _Video_ TextAudio Images / \ |(PNG, GIF, SVG, etc.) / \ | | Images Text TextText | (captions/subtitles) (transcript) | Text -- 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] Justify this
Paul Noone wrote:
Hopefully a quick question, I hoope, as the W3C specs are no help on this
one.
No, they are usually always helpful but you need to know what you're
looking for.
I want to centre align text and justify it at the same time. I've applied
the following mark-up which, surprisingly, does the trick. But can justify
be applied as an optional extra parameter, or does this just work through
browser quirks?
text-align: center justify;
If that does anything at all, it's a browser bug. That property should
be ignored by a conforming browser. Centred and justified text are
mutually exclusive options and it makes little sense to combine them
like that. However, I'm going to assume you're looking for a way to
centre the box, but have the text justified within. In which case, this
should do the trick:
p { width: 50%; margin: 0 auto; text-align: justify; }
Just use an appropriate selector and width for your needs.
--
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] Justify this
Paul Noone wrote:
Lachlan Hunt wrote:
Paul Noone wrote:
I want to centre align text and justify it at the same time. I've applied
the following mark-up which, surprisingly, does the trick.
text-align:center justify;
p { width: 50%; margin: 0 auto; text-align: justify; }
Thanks for that but I was actually wanting to center align justified
text for a particular purpose. Evidently my experiment is invalid.
If that isn't a solution to your problem, then you need to more clearly
explain what you are trying to do. Conceptually, it makes no sense to
both center and justify text, since they are mutually exclusive values.
I tried your suggested code, but couldn't find any browser that produces
the result you described in either quirks or standards mode, all
browsers I tried correctly ignore the values and default to left alignment.
Please provide a better description, a sample document or some form of
illustration (eg. ascii art or a link to an image) that demonstrates the
effect you are trying to achieve. If, as you say, the sample code you
provided does produce the effect you want, please provide a test case
and indicate which broken browser gives the intended result so we may
see for ourselves.
--
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] Browser Resolutions
Stephen Stagg wrote: Slightly off-list but important all the same. I traditionally design sites to look good at 800x600 and best at 1024x768. Now, tho, it seems as if users visiting with resolutions of 800x600 are around the 1% margin... It is the viewport size that matters, the screen resolution is essentially irrelevant. It is an invalid assumption that everyone surfs with a maximised browser window; or even if it is, that it takes up all the space. The browser may also have a sidebar or anything else which can take up any amount of space. Personally, my screen resolution is 1280x1024, but my browser window is usually around 900x900 - I do not like a browser taking up my whole screen. In fact, that is even narrower than a maximised browser on 1024x768. dd a sidebar to that, which would be roughly 200px wide when open, that leaves less than 700px width for the web site to play with, which is almost half the width of my screen resolution. So please understand that any screen resolution statistics you find will be nothing short of completely useless. -- 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] XHTML1.1 differences
designer wrote: Are you serving the webpages as mime-type "application/xhtml+xml" ? Because that is the only mime-type that should be used with XHTML 1.1. It can also use application/xml or text/xml (although it's best to avoid text/xml completely), or other appropriate XML MIME type. Only 3 differences? I seem to remember more than a dozen . . . What are your 3? There's 3 listed in the XHTML 1.1 Appendix A [1]. However, there are other undocumented changes too. One that I can remember is that the usemap attribute changed from a URI in HTML 4.01 and XHTML 1.0 to an IDREF in XHTML 1.1. That means for image maps, it must be written using a fragment identifier like this in XHTML 1.0: but like this in XHTML 1.1: Both refer to: I've no doubt there are other differences too, but I've never really gone through and looked hard enough myself. [1] http://www.w3.org/TR/xhtml11/changes.html#a_changes -- 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] Help with CSS
José Kusunoki Gutiérrez wrote: I want to know why in IE my side bar is wrong i mean the bullets are not in the rigth place, and when i see it in Firefox its ok... is there a css hack that i need for IE? No-one can possibly offer you any useful advice on how to solve this problem because you haven't provided a link, we can't see the problem for ourselves, we don't know what styles you have applied and thus have no idea what may be causing the issue in IE. It may be a simple case of making sure you set the margin and padding on the ul and li elements, as they do have different default values in different browsers. It could be a double-margin float bug. It could be one of many thousands of IE bugs. Start at position is everything, look through the IE bugs and see if you can find one that resembles your problem. If not, provide much more information about your page. A link to the page is the most useful. http://positioniseverything.net/ PD: Sorry about the last message that i sent it had the wrong subject accidentally It's not a good idea to start a new thread by replying to another message in a completely unrelated thread. Simply changing the subject and deleting the quote (Both of which you initially failed to do.) isn't good enough either, since the message may still contain headers that indicate which thread it's in. Always start a new thread by creating a new message. -- 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] Help with CSS
Jorge Laranjo wrote: On 18/12/05 1:25, "Lachlan Hunt" <[EMAIL PROTECTED]> wrote: No-one can possibly offer you any useful advice on how to solve this problem because you haven't provided a link, we can't see the problem for ourselves, we don't know what styles you have applied and thus have no idea what may be causing the issue in IE. I think that is http://www.constantconcept.com/ My mistake, I didn't look in the sig. Although, it's generally a good idea to explicitly state which site is being talked about in the body of the message anyway. -- 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] weird IE6 doctype switching question
Marco van Hylckama Vlieg wrote: Question: Is it possible to make IE6 use the broken box model for a PART of the document? No, DOCTYPE switching applies to the whole document, not just parts of the document. The different box model may one day be able to be chosen using the proposed 'box-sizing' property [1] in the CSS3 box model module. Mozilla has some support for it as '-moz-box-sizing'. Although, as noted in the CSS3 draft, 'box-sizing' may actually be dropped in favour of a better solution. This means I have an XHTML 1.0 Strict / Transitional document with a in it for which the inner content should be rendered with the broken box model, only in IE 6, not Firefox. Your going about trying to solve this the wrong way. Instead of trying to solve the problem by making a browser use intentionally broken behaviour (quirks mode) because it gives the intended result, try and work out the cause of the different rendering and find an alternate method or (as a last resort) use a hack. You may find that your problem is one of the many well documented IE bugs for which many workarounds are readily available. As for quirks mode, you should basically try to forget it even exists as an alternative and never, under any circumstances, attempt to develop a page using it. Use of quirks mode is never a good solution to any problem. [1] http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-box-width -- 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] Setting Up Font Sizes
Nick Cowie wrote:
Samuel
You wrote:
body { font-size .8em; }
p { font-size : 90%;
(adjust per design to get the correct sizes etc)
}
That is asking for trouble, you really need to watch out for the cascade.
Get a p inside a p,
It's very rare that p elements would be nested like that and under
normal HTML conditions almost impossible, at least to do so
accidentally. It can be done using this, for example, but rare.
...
(object can also be replaced with other elements like ins and del for a
similar result)
an li inside an li or a li inside a p and suddenly
Again, li inside p is difficult to achieve, but nested lis are a good
example.
personally it is
body { font-size 76%}
That's extremely small for the main body copy. Such sizes should be
reserved for relatively unimportant footer text like copyright notices,
etc. I don't recommend anything below 80%, but I also don't recommend
using % (or em or ex) for setting font sizes for the reasons you gave above.
Personally, I recommend using the font-size keywords because they don't
suffer from such problems.
body { font-size: small; }
is generally acceptable and is approximately the same as 80% of the
default font-size. 'medium' is best for body-copy although many
designers would likely object. There are some obsolete browsers that
get the sizes wrong, for which there is a hack [1], but I don't bother
with it.
[1] http://diveintoaccessibility.org/day_26_using_relative_font_sizes.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] Setting Up Font Sizes
Felix Miata wrote:
Lachlan Hunt wrote:
body { font-size: small; }
is generally acceptable and is approximately the same as 80% of the
Definitely not acceptable to me for content paragraphs. :-(
Why not? Is it too big or too small for you? Or is it just not precise
enough?
If you say it's too small, then I'd accept that. There are many who say
anything below 'medium' is too small for body copy. If you say it's too
big, then I have to very strongly disagree and say that making it any
smaller, will make it very difficult or at least uncomfortable for many
users to read without increasing 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] xhtml DTD
Spark wrote: I use this W3C document as a reference to know which tag may go inside other: http://www.w3.org/TR/1999/xhtml-modularization-19990406/DTD/doc/xhtml1-t.elt.html I never found nothing else like that (such a DTD visual representation), but what I want to know is: is it the latest version? No, it's not. how may I know that ? If you go to the beginning of the spec (remove the /DTD/... from the URI). http://www.w3.org/TR/1999/xhtml-modularization-19990406/ Read the status and you'll see that it's an old working draft and that the latest version can be found at http://www.w3.org/TR/xhtml-modularization/ Specifically, I believe this is the closest to what you're looking for. http://www.w3.org/TR/xhtml-modularization/abstract_modules.html However, may I ask what your reason for choosing XHTML is? If you're simply looking for a good reference for elements and their content models, the index of elements in HTML4 is more suitable for most authors. http://www.w3.org/TR/html401/index/elements.html I checked today to answer a question about tags inside LI , and found by this very document, you may use any H tags , but H1 . Would it be a typo ? http://www.w3.org/TR/1999/xhtml-modularization-19990406/DTD/doc/xhtml1-t.elt.html#li Yes, it would be. There is no element in XHTML 1.x. -- 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] Best Web Standards thing I learnt in 2005.
Bob Schwartz wrote: Christopher, + getting into microformats I guess I missed something along the way. Where can I find out more about this? http://microformats.org/ -- 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] HTML Numeric and Named Entities
liorean wrote: On 11/01/06, Kat <[EMAIL PROTECTED]> wrote: Is it safe to use the named references that formerly refered to the control characters? Yes, it's safe to use the named entity references in HTML4, but it's easier to just use UTF-8 and type the actual characters instead. — (or any other entity reference) has never referred to a control character, you're getting confused by the fact that IE (and now every other HTML browser, for compatibility) incorrectly interprets character references from € to Ÿ (and their hex equivalents) as though the Document Character Set were Windows-1252. This has never been defined in any standard, it is nothing more than widely implemented broken behaviour. Multi level answer here: - text/html: Should be perfectly safe. Yes, it only depends on the availability of fonts and support for the characters used. Not all characters are supported by every browser. For example, the character referred to by (soft-hyphen) isn't supported by Mozilla yet. Also, some older and obsolete browsers don't support all named entities. - application/xhtml+xml: Should be, but isn't, safe except for the five named entities of XML. Use decimal or hexadecimal character references instead. - application/xml: Only safe in validating user agents. Which doesn't include browsers. So, use decimal or hexadecimal character references. There is no difference between the handling of the MIME types, both require the use of a validating parser to handle named entity references. The exception to the rule is that some browsers, such as Mozilla, despite not implementing a validating parser, may have a pseudo-DTD catalog containing just these entity references. Mozilla uses this catalog when it encounters an XHTML DOCTYPE in an XML document, regardless of the MIME type. (It works similarly for MathML too). Character references refer to Unicode code points independent of the document encoding and character set. At least for HTML4 and XML, if not for HTML3.2. As far as character references in HTML are concerned, they have always referred to the Unicode code points since HTML 2.0. See my article: http://lachy.id.au/log/2005/10/char-refs (take note of the comments too, which contain a few corrections) -- 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] CSS or JavaScript flyout menu
Taco Fleur - Pacific Fox wrote:
I am looking for some ideas on how to create a JavaScript/CSS fly-out menu,
the dreaded day has come that a client finally insisted on using one!
...
var menu = new Object();
menu[ "about_bdsrecruit" ] = new Object();
Yikes! Don't generate a menu like that, it's a waste of time.
Markup:
Item 1
Item 2
Submenu item 1
Submenu item 2
Submenu item 3
Item 3
Make them all links if you like, I just omitted the a elements for
simplicity.
CSS:
li ul { display: none; }
li:hover ul { display: block; }
/* Plus whatever styles you want to make it look good and layout
correctly. */
JS:
Attach mouseover and mouseout event listeners to the li elements to show
and hide the sub menus.
Google for "Pure CSS Menus", "Suckerfish Dropdowns" "CSS/JS menus" or
similar search terms.
--
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] HTML Numeric and Named Entities
liorean wrote: On 11/01/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: As far as character references in HTML are concerned, they have always referred to the Unicode code points since HTML 2.0. Ah. I just saw BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0" BASESET "ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1" in HTML3.2 and BASESET "ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6" Oh, you're absolutely right. My mistake, ISO-646 is US-ASCII, I forgot that it formally changed to ISO-10646 in HTML 3.2. However, ISO-10646 is mentioned in the prose of RFC 1866 several times and implementations are advised that numeric character references (beyond latin1) should reference those code points. However, HTML 2 does formally use Latin 1 (ISO-8859-1) for char refs, but these code points are a subset of ISO-10646 anyway. -- 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] pdf graphics
Bruce wrote: I was pleased recently to get a rather large project. It was also nice that they were sending the graphics for the site design. Today I got them, in pdf format! LOL! I wish all pdf files would get lost, feel they have no place on the web. They do have their place on the web, but they're certainly not for sending graphics. What do you do in a situation like this? I need them for the design, menu items and backgrounds... I've recieved the wrong file format from clients previously, it usually just takes a quick e-mail to get the right ones from them. Just ask for the original image files, they should have them in a format like suitable for Photoshop, Fireworks, CorelDraw, GIMP, or whatever app they used to create them. -- 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: Re; Re: [WSG] the correct use.
Alvaro Mouriño wrote: So many people think that should be avoided, but only for text layout or for the entire document? It's important not to get confused, nor put weight into such statements, they're usually either stated too broadly just plain wrong. can be used for explicit line breaks in text where it is semantically relevant, but it should not be used, for example, to increase vertical whitespace between paragraphs or other sections of content. The common usage to separate paragraphs like this is wrong: paragraph 1 paragraph 2 paragraph 3 In most cases, if you ever get the feeling to use 2 consecutive s, then you're most likely using it wrongly. But, for example, marking up a postal address, a poem or something where line breaks are semantically important, then the use of is ok. 123 George Street, Sydney NSW 2000 Australia Because I've been so tempted to use tables when formatting a form, and now I read that br tags should not be used... Tables for forms is ok in some cases, forms can be considered tabular. And I think that creating a unique CSS class with the absolute position for each control is as not-right as using tables. Using a class name to describe presentation is no better than using presentational elements and using absolute positioning for each form field and label would be overkill. However, I'm not sure what this has to do with the discussion of elements. -- 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: Re; Re: [WSG] the correct use.
Peter Firminger wrote:
The much maligned element is essential in our work. Sometimes we're not
just doing poetry and addresses.
Take for example the archive page of this very message (the one I'm replying
to).
http://webstandardsgroup.org/manage/archive.cfm?uid=C69ACE78-BB9A-910B-E6CC1A4A59BDF099
How else would I accurately display Lachlan's example below without . I
don't agree that is the answer because this may well force the
page into breaking due to width. Pre is pretty powerful and can break a layout
very quickly if something unexpected is forced into it.
For plain-text e-mails which are sent by behaving mail clients with
lines wrapped between 72 and 80 characters (preferably with
format=flowed set as well), then pre is perfectly safe. Although,
unfortunately, because not all mail clients are well behaved (in fact,
some are broken beyond belief), I agree it can be problematic in some cases.
However, there are various solutions you could try.
---
1. Process the e-mail before it's output so that line breaks are
automatically inserted into long lines, being careful not to break lines
wrongly, such as a really long URI, for example.
In other words, process it according to the algorithm in section 4.1 of
RFC 3676 and then wrap lines as though you were outputting to a viewport
80 characters wide. You could even markup things like the signature,
quoted text, etc. and render them in different colours, add excerpt bars
to the quotes, etc.
If format=flowed isn't specified, then you could either process it
according to the same algorithm and just hope it doesn't break anything,
or just assume the lines would be wrapped relatively short already
(which, in my experience, is usually the case) and output as-is.
---
2. Take the approach that the W3C have with their mailing list archives.
http://www.w3.org/StyleSheets/Mail/message.css
pre {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap;/* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+; makes the CSS
invalid :( */
}
This is an example of an e-mail sent by a mail client that isn't
well-behaved.
http://lists.w3.org/Archives/Public/www-style/2006Jan/
(take a look at the source and notice how there are extremely long lines
in there that should have been wrapped by the sender's mail client, but
weren't)
Of all the Windows and Mac browsers I tested, OmniWeb is the only one
that didn't wrap the text and Safari did something strange by wrapping
it anywhere in the line, not just whitespace (and other allowed
line-breaking points), but it was still readable.
---
There may even be other solutions I haven't thought of. #2 would be the
easiest to implement, but suffers from some browser limitations. #1 is
more difficult, but doesn't suffer from any browser limitations because
the line wrapping is done server side.
But, one thing I'm sure of is that is the most semantically
correct choice for marking up plain-text formatted e-mails. It also
defaults to a monospace font, which really should be used for plain-text
e-mails and solves the problems with multiple consecutive spaces, often
used for indentation.
Take the e-mail you linked to in the archive above. I used spaces to
indent the markup in the street address markup, yet it does not appear
indented in the archive. That's particularly important for mailing
lists like this where markup examples are quite common and indentation
increases readability, which is currently lost in the archive pages.
--
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: Tabluar forms WAS: Re: [WSG] the correct use.
kvnmcwebn wrote:
"
What's your favourite colour?
black
white
"
I just made a form without tables using something similar to the above.
With forms it seems like if you dont use the table you'll have to use a lot
of hacks for the browser discrepencies. Id rather use the hacks than the
table - is this the best practice?
No, it's best to avoid hacks and go for the simplest solution. Also,
you seem to be trying to work around a problem with semantics that
doesn't necessarily exist. That form could quite happily be marked up
as a table, as the data most certainly can be considered tabular - let
me explain.
Take this small example table:
Name
Lachlan Hunt
Gender
Male
DOB
1983-03-07
I'm quite sure that everyone would agree that is a perfectly legitimate
use of a table with the first column providing the field name and the
second the value. It could be rendered something like this:
---------
| Name | Lachlan Hunt |
| Gender | Male |
| DOB| 1983-03-07 |
-
Now, say, instead of knowing the values for each field when the page is
written, we want to ask the user to provide the values instead. That
would require a form, but those of you that question the semantic
appropriateness of a table for a form, please explain what makes the
following so questionable.
Name
Gender
DOB
That seems almost semantically identical to the above table, except that
the values will be provided by the user instead of the author.
Now, to make it a little more accessible and more explicitly associate
the labels with the form controls, we can throw in a few IDs and label
elements.
Name
Gender
DOB
And there we have it: one perfectly legitimate use of a table for
marking up forms. Although, we're not quite done yet. The example you
provided above used radio buttons instead and judging by your
explanation, I'm going to assume the intention is for it to be layed out
something like this:
+-- What's your favourite colour? -+
| |
| O Black |
| O White |
| |
+--+
For such a simple example, a table probably wouldn't even be necessary,
you could infact get away with changing the markup slightly like either
of these:
1. Make the association implicit, instead of explit
black
(That allows you to use label { display: block; } and have each one show
on a new line.)
2. Enclose each label/radio button pair within a p element.
black
Simiar to above, but p already has display: block; set by default.
3. Use a list (it's a list of options)
black
...
As for using a table, it's not usually good as for usability to separate
a checkbox/radio button from its label into different cells, as was done
for the textbox examples above. There may be some cases to do so, but
in this instance, I'd suggest the following would be more appropriate.
Say, for example, it were included within the example table I provided
above containing name, gender and DOB.
...
Favourite Colour
black
white
The final table could be rendered something like this:
---
| Name | |__| |
| Gender | |__| |
| DOB | |__| |
| Favourite Colour | O Black |
| | O White |
---
--
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] content type etc
Rimantas Liubertas wrote: As for omitting mime type from meta element and leaving only charset info... This might work only in text/html context, in which such omission makes no sense. Although I suspect it will work just fine in most, if not all modern browsers, that doesn't make it right. In fact, I read somewhere a long time ago that some browsers (NN4, I think) will accept something like. -- 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] content type etc
Paolo Dodet wrote: On 15/01/06, Rimantas Liubertas <[EMAIL PROTECTED]> wrote: When file is saved and then loaded Mozilla determines which parser - html, o xml to use by file extension. So if you save xhtml file as .html/.htm and then load it, it will be parsed by html parser, and in this case META is taken into account. If file is saved as .xhtml, .xml or .xht it will be parsed with xml pareser and META is ignored. So, what about files saved with a .php extension? Rimantas was talking about when the files are loaded from the local file system, where there are no HTTP headers available. In the context of the web, the file extension is essentially meaningless, it's the MIME type sent in the HTTP Content-Type header that matters. The file extension only exists as a means to determine the file type on your local file system and use by the web server to determine various HTTP headers. When served over HTTP, the file extension is (well, it should be [1]) completely meaningless to the browser. Most of the common extensions are associated with standard MIME types, so that, for example, when you upload a .html file to your server, the server (theoretically) knows what Content-Type to send (assuming it's been configured properly). These are some of the most common file extensions and their most commonly associated MIME types: Extensions | MIME |-- .html .htm | text/html .xhtml .xht | application/xhtml+xml .xml| application/xml (preferred) or text/xml (not recommended) .txt| text/plain .css| text/css .js | application/javascript, text/javascript, etc. .jpeg .jpg | image/jpeg .gif| image/gif .png| image/png PHP isn't directly associated with a specific MIME type, since it's dynamic content that can be anything at all. It is usually (and defaults to sending) text/html, but can be set to anything using the header() function. [1] The evil practice known as "Content Sniffing" makes use of the file extension (among other things) to determine the file type in the event that or no content-type information is sent by the server, or if it is believed by the browser that the server is wrong. This is why, for example, HTML documents served as text/plain will be incorrectly rendered as HTML by IE. -- 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] CSS Icon
Alvaro Mouriño wrote: Hi List, I was just wondering if it is possible to set an icon for my site with CSS (the one next to the title) Either way, how do I do it? Not with CSS, this goes in your HTML. http://en.wikipedia.org/wiki/Favicon -- 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] Article: MIME and Content Negotiation
designer wrote:
I have been using Neil Crosby's PHP approach on [1] (see signature,
below) and it works 'OK', BUT, if I omit the meta tag:
...
Lachlan says this is simply incorrect, so I'm a bit confused by all this.
Did you read my article [1] which Rimantas referred you to? That
explains what you're supposed to do. You need to use real HTTP headers,
not the inferior meta element. The end of that article links to another
that actually explains how to set the charset parameter in the HTTP
headers using various servers and server-side scripting languages [2].
For PHP, it's as simple as calling this PHP function before any of the
page content is output.
For HTML 4 and Appendix C compatible XHTML
header("Content-Type: text/html; charset=UTF-8");
Or, for real XHTML
header("Content-Type: application/xhtml+xml");
(The charset parameter is only really needed for text/* media types, for
XML served with an application/* media type, the XML declaration is
recommended for use instead which may be omitted for UTF-8 and UTF-16)
[1] http://lachy.id.au/log/2006/01/content-type
[2] http://www.w3.org/International/O-HTTP-charset
--
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] Article: MIME and Content Negotiation
Karl Dawson wrote: "From the Top" is a series of articles that I am publishing to concisely explain how and why to construct a high quality, web-standards compliant head section for a web page. The second article, just released, examines MIME and Content Negotiation. http://www.thatstandardsguy.co.uk/2006/01/16/content-negotiation/ It started out well and is covering a very important topic that isn't well understood by many, but there's a few issues you didn't cover and/or covered incorrectly. The following quotes are from the article: Code must be well-formed. Remember XHTML is a reformulation of HTML as an application of XML. As such it must validate. You're confusing well-formedness and validation. The first statement is correct, it must be well-formed, but the second that it must validate because it is XML, is not. The validation requirements are the same as HTML 4. In other words, it must validate to be a conforming XHTML document, but there is no requirement in XML for all documents to be valid (even if they have a DTD). # The XML Prolog is required for character sets other than UTF-8 and UTF-16. This is declared on line 1 of your code in the format version="1.0" encoding="yourChosenCharset" ?> That's the XML declaration, which forms part of the XML Prolog. The XML Prolog is always present and comprises the XML declaration, PIs and the DOCTYPE (although all of those parts are optional in XML 1.0) # Only five named character entities are “safe”: <, >, &, " and '. On 4 are safe when using text/html, because ' is undefined in HTML and is not supported by IE. However, the article of mine that you linked to does cover that issue so it's not a major problem. Standard Generalized Markup Language (SGML) comments () hide everything - including style and script tags. They're XML comments, which are based on SGML comments but still differ in significant ways. I have another article which covers this issue in great detail. http://lachy.id.au/log/2005/05/script-comments # Stylesheets need to be referenced with an XML stylesheet declaration. Wrong! That's just one of the myths in the widely criticised Appendix C. This is done by creating a fragment identifier, Slightly wrong terminology, a fragment identifier only occurs in a URI (after the #) which references an ID or an anchor in an (X)HTML document. for example id=”myStyle” in each <style> tag and reference this in the XML stylesheet declaration that goes above the DOCTYPE declaration in the format: type="text/css" ?>. Note that you will need this declaration for each stylesheet. This is unnecessary because any XML UA that recognises the id attribute as an ID must be either a validating parser or be an XHTML UA, in which case it will already recognise both the style and link elements, making the xml-stylesheet PI unnecessary. If it is a validating parser, but not an XHTML UA, the stylesheet would do much good anyway, because there wouldn't be any default UA stylesheet which would likely be depended upon for the styles to work properly. application/xhtml-xml That's written a few times in the article, it's just a small mathematical error. You need to add xml, not subtract it. i.e. application/xhtml+xml Lastly, there's one more issue that wasn't discussed which should have at least been mentioned. By serving application/xhtml+xml, Mozilla cannot yet incrementally render the document. It is a browser limitation, there's nothing in the spec that prevents incremental rendering in implementations, but it still needs to be considered for practical reasons. -- 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] Article: MIME and Content Negotiation
Paul Novitski wrote: At 04:02 AM 1/16/2006, Lachlan Hunt wrote: (The charset parameter is only really needed for text/* media types, for XML served with an application/* media type, the XML declaration is recommended for use instead which may be omitted for UTF-8 and UTF-16) http://lachy.id.au/log/2006/01/content-type For clarification, was your first clause above a sentence in its own right? I assume you meant, "(The charset parameter is only really needed for text/* media types. For XML served with an application/* media type... Yes, that's correct. It was just a typo. ** 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] Article: MIME and Content Negotiation
designer wrote:
However, I remain confused in the particular case of the PHP approach.
The PHP looks to see
"if(stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml"))" and on
that basis it describes the appropriate prolog, mimetype and charset. So
the final three lines of the php code (where the action takes place :-)
are:
header("Content-Type: $mime; charset=$charset");
header("Vary: Accept");
print $prolog_type;
One therefore assumes that the 'real http headers' ARE being used in
this case. However, if I do that I can only get Chinese unless I get
PHP to echo the meta tag:
Can you please make up a small sample document that clearly demonstrates
this issue occurring and post a URI so that we may see 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] Article: MIME and Content Negotiation
designer wrote: So I made a simplified version of my opening page (removed counters and other impedimenta) and removed the meta tags. All I got was Chinese and gobbledegook! So I uploaded it to: http://www.rhh.myzen.co.uk/rhh/gam/test.php Did it look anything like this? http://software.hixie.ch/utilities/cgi/content-type-proxy/content-type-proxy?uri=http%3A%2F%2Fwww.rhh.myzen.co.uk%2Frhh%2Fgam%2Ftest.php&type=text%2Fplain%3Bcharset%3DUTF-16 It could be that your testing server is sending UTF-16 (or some other incorrect encoding) for some strange reason. The easiest way to find out is by using Mozilla or Firefox, go to Tools>Page Info... and look at the MIME type and encoding information listed in the dialog. -- 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] content type etc
Paolo Dodet wrote: That is. If you access my personal site using IE you will notice that I use a meta tag to declare the mime-type, and in the case of IE it would be text/html, whereas if you access using any other browser the page will be served as XML, using a xml declaration, without any meta-tag to declare the mime-type. http://www.noblocodenotas.com/ That makes no sense whatsoever! You never need to use the meta element for content served over HTTP for *any* browser. IE supports the HTTP headers just fine: Besides, your server is not sending the correct HTTP response headers to any browser, even though it is stripping the meta element and adding the xml declaration for those that support it. These are the response headers sent to Firefox regardless of the value of the Accept header. HTTP/1.x 200 OK Date: Tue, 17 Jan 2006 21:49:22 GMT Server: Apache/1.3.34 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.25 OpenSSL/0.9.7e X-Powered-By: PHP/4.3.10 Keep-Alive: timeout=1, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Regardless of whether the Accept header contained application/xhtml+xml or only text/html, the meta element was stripped and the XML declaration was added, yet the Content-Type of text/html remained the same. These response headers were sent when the browser identified itself as IE (including Firefox when I modified the User-Agent header to match IE6): HTTP/1.1 200 OK Date: Tue, 17 Jan 2006 21:44:21 GMT Server: Apache/1.3.34 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.25 OpenSSL/0.9.7e X-Powered-By: PHP/4.3.10 Transfer-Encoding: chunked Content-Type: text/html Regardless of the Accept header again, the meta was element was included, the XML declation was not. This proves that not only are you failing to set the HTTP headers correctly, but you're changing the document based on the perceived browser support judged only by the the User-Agent request header. In other words, you're browser sniffing and that is never the right way to do things. If you wish to do content negotiation, please do so properly. This article [1] posted here earlier explains the correct way to set the headers and detect based on the Accept header. For HTML, the Content-Type response header should contain this: Content-Type: text/html; charset=ISO-8859-1 Don't include the XML declaration. (Note: I recommend you switch to using UTF-8 instead, but it requires that your files actually be saved as UTF-8, not just changing the value in this header) For XHTML, use this: Content-Type: application/xhtml+xml Include the XML declaration to declare the encoding. *DO NOT* use the meta element for any browser at all, in fact don't even include it in your document under any circumstances when serving over HTTP. (It can be useful for testing on the local file system, but useless for anything beyond that). [1] http://www.thatstandardsguy.co.uk/2006/01/16/content-negotiation/ -- 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] .htm include file into another .htm
Svip wrote: On 18/01/06, KJ Callender <[EMAIL PROTECTED]> wrote: I want to include a file to be included into about 10 htm pages, and to save time me updating them individually, i want to use a include file. Using standards, which is the best way to achieve this: 1. It could be done as following in PHP: Which would not include your "comment" mark, and I do not know either if your way is a standard, as I have never heard of it. Besides, I hate frames, and thus would not suggest your way. They're called server side includes and they work on Apache. They've got nothing to do with frames. I don't believe they're in any official standard, Apache is the only server I know of that implements them like that (though, I don't know much at all about other servers). http://httpd.apache.org/docs/2.0/howto/ssi.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] content type etc
Keryx webb wrote: 3. If not (2): If the content is (X)HTML, UAs use the meta-tagg. When loading pages from local files or from an FTP-server, where obviusly no HTTP-headers are sent, this is what the browser should use to get the encoding. Meta elements are *not* used in XHTML files at all, this only applies to HTML. But this needs to be clarified that XHTML served as text/html *is* HTML, regardless of what the DOCTYPE says. Value of declaratons: HTTP-headers > XML-prologue > Meta-tags It's not quite as simple as that. It's more like this: for text/html: HTTP headers --> element --> content-sniffing for application/xml and */*+xml (excluding text/*) HTTP headers --> XML Declaration --> BOM (UTF-8 or UTF-16 LE/BE) for text/xml HTTP headers --> US-ASCII (XML declaration is ignored) MSIE-values: It's own "judgement" > HTTP-headers > XML-prologue > Meta-tags Again, it's not quite as simple as that. For text/html, the XML declaration is *not* used at all, IE doesn't even understand it and triggers quirks mode if it's present. IE supports application/xml and text/xml and it will respect the XML declaration, but I'm not sure how standards compliant it's behaviour is with regard to encoding detection in XML. I'm not aware of any case where IE will override the character encoding in the HTTP headers, only the MIME type. Can you provide a demonstration or provide a link to some documentation of the bug? -- 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] Correct MIME types for non-standard file formats
Peter Levan wrote: Is there a good reference site that lists correct MIME types for various file formats? http://www.iana.org/assignments/media-types/ or is there a general rule to follow for non-standard file types? There is the x- prefix which is added to proprietary/custom MIME types, but you you should generally try to find one which is documented either with IANA or by the vendor of the file type, instead of making up your own. Specifically I'd like to know what MIME type should be used for SPSS portable (.por) files If you can't find an official one in IANA or find one documented by the software vendor, then you should use application/octet-stream for generic binary files. -- 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 and HTML5
Christian Montoya wrote: On 1/25/06, Brian Cummiskey <[EMAIL PROTECTED]> wrote: For example, they mention that footer is used a lot, and are thus suggesting a tag. http://whatwg.org/specs/web-apps/current-work/#the-footer Thoughts? My thought: they have no idea how hard it is to introduce a new tag. What exactly is hard about introducing a new element? Browser vendors have done it with hundreds of proprietary extensions in the past. What's different about doing it now, especially now that these new elements are being standardised and will be implemented by several major browsers relatively soon? -- 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 and HTML5
Christian Montoya wrote: On 1/25/06, Geoff Pack <[EMAIL PROTECTED]> wrote: We could have: If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. The problem with that approach is that generic XML, even with a stylesheet applied, doesn't have any formally defined semantics. It's not till the elements have been defined in a spec somewhere and implemented by UAs that they really become useful for anything more than just styling in a visual UA. Without formally defined semantics, you may as well just be using presentational HTML elements, which have precisely the same meaning: none at all! For example, with a nav element defined and implemented as a section of navigation, a UA could provide an easy way to either skip over it or skip to it, without relying on the author having to use skip links which would be good for screen readers. Likewise with the article element, which will usually contain the most interesting content on the page. -- 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] mailto: and email-subjects
Dylan Kinnett wrote: I'm working on a website whose "contact us" page has its email links set to include a subject link, like this: a href=mailto:person[at]server[dot]com?subject=Wesbite Support Question" Always use example.com, example.org or example.net in examples in the future. I edited the e-mail address this time because what if someone happens to own server.com (in fact, someone does own it) and a spamer's e-mail harvester finds that in some mailing list archive? this website is supposed to be written in html 4.0, but I can find nothing in the 4.0 specifications about this subject function. That's because you're looking in the wrong place. HTML doesn't define any URI schemes, it only defines a mechanism that uses them. I'm sure you wouldn't expect to find a defintion of http: or ftp: in the HTML spec, and that is also the case with mailto: URIs. See RFC 2368. http://www.ietf.org/rfc/rfc2368 -- 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] The dilemma: tabular data with sublevels
Andreas Boehmer [Addictive Media] wrote: Bert Doorn wrote: [ select category ] [ add ] [ edit ] [ delete ] You can have option groups in the select. Example: Select Product Apple Orange Lemon ... The problem is that we are not only allowing to add/edit/delete one level of the hierarchy, but all of them. Imagine it more to be like this: [Add] [Edit] [Delete] Folder 1 [Add] [Edit] [Delete]SubFolder 1 [Add] [Edit] [Delete]SubFolder 2 [Add] [Edit] [Delete]SubSubFolder 1 [Add] [Edit] [Delete]SubSubFolder 2 [Add] [Edit] [Delete]SubFolder 3 [Add] [Edit] [Delete] Folder 2 Although it's currently impossible with a normal select list, you can instead use radio buttons or checkboxes within nested lists. Fruits Apples Oranges Lemon ... Just fill that out with all the necessary attributes and values, then add some submit buttons for add, edit and delete. -- 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] The dilemma: tabular data with sublevels
Joshua Street wrote: The other thing (this list is definitely the wrong place for me to say this) is if this is for a content management system or the like, where the client's browsing capabilities are a well known quantity, What? How can you possibly assume that any user of a CMS will not have accessibility requirements? Is there some restriction on the web that I don't know about in which users of Lynx, JAWS or other assistive technology can't publish on the web, and therefore have no use for a CMS? -- 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 and HTML5
Nic wrote: What the WHATWG are doing which I think is clever, is they're reusing existing, meaningless presentational elements where they can. If I remember correctly, has been re-specified too. Quite the contrary, it's asking for problems. Yes, I agree. Reusing presentational elements for semantic purposes is a mistake and has been criticised on the whatwg mailing list several times. How long have and been deprecated? They're not deprecated. Why are some editors still using it? Because they target authors that still think presentationally about their documents, rather than those that think semantically. Do you *really* think that a re-specification will catch on? No, it won't for presentational elements. However, the refined definitions for the more semantic elements will probably stand more chance. -- 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 and HTML5
Christian Montoya wrote:
I think the W3C realized that a long time ago, and I think WhatWG will
go at this for a couple more years and say, "hey, this html thing just
can't define everything, we need a technology that can support
applications, one that allows developers to define their own
information, and we need to make ways to define standards for using
existing elements," and they'll realize that this kind of
extensibility is available in xml, and they'll make a new technology,
called HTXML, and they'll start working on 1.0, while the W3C is
celebrating the formalizing of XHTML 2.0 and it's correct support in
Internet Explorer 8.
IE8 will not support XHTML 2.0. It may support XHTML 1.0, possibly 1.1
as well, but definately not 2.0. In fact, I guarantee that there will
be browsers supporting new HTML5 features long before XHTML 2 is on the
road map.
Let's face it, HTML5 is just an attempt to make html work for web
applications,
It is in fact a lot more than that. While web applications are a major
use case, it's also an attempt to document and standardise the buggy
browser behaviour that we currently are and will always be stuck with in
the hopes on increasing interoperability, particularly with relation to
error handling; refine the semantics of existing elements and introduce
semantics that we have been waiting a long time for.
But even if you don't buy that argument, take this view: presentation
and semantics should be separate. Why? Because this is the problem
with HTML5: the person building the layout/structure has to also be a
semantics expert. With the complexity of web applications, this is
just not reasonable. Building the structure for a solid layout
shouldn't be mixed with making the content semantic. Just look at how
complicated this gets:
How is that at all complicated? It actually simplifies the markup a
great deal by removing several use-cases for div – a semantically
meaningless element.
If I want all four containers to have similar CSS, I have to do:
header, navigation, article, footer { same stuff here }
where id, class, rel, etc. could be used in place of title, and
section could be used instead of div. Also consider:
"Any time a div is the answer, there's a hole in HTML." -- Ian Hickson
Well, for that, you could use
div { same stuff here }
But, then you'd have to deal with all the other (ab)uses of div in your
document. Otherwise, you'd just have to give them IDs or classes and
style them like this:
#header, #navigation, #article, #footer { same stuff here }
Which, by your logic, is somehow better than using a semantically
defined element!?
Whatever we use, the point is that it's easy to go into an already
constructed HTML4 or XHTML document and add semantics to it (when the
presentation and semantics are separate), without having to mess much
with the CSS [1], or wait for tags to be introduced. This kind of
thing isn't supported by machines yet, but I would much rather prefer
to see support for attribute-defined semantics [2], than trying to
modify/add presentational elements that are semantic.
...
[2] Just peruse all the examples at http://www.microformats.org/wiki/
and imagine trying to make an html tag for every single one.
While it is good to reuse and refine the meanings of existing markup
where possible, and in fact Hixie would wholeheartedly agree with you on
that point:
(See the glossary example here, for instance)
http://ln.hixie.ch/?start=1129948617&count=1
The use of attributes for semantics is not always a good idea. If it
were, we'd have documents like this:
Heading
Div-Mania
It's great to use
div and span
for everything
This could be considered a joke, if it were not
for this kind of crap actually being used! Instead, consider
it a reality check.
Foo
Bar
Baz
If you prefer to mark up like that, then by all means, go for it. But
for those of us that actually like to put semantics in our documents,
we'll use the elements with formally defined semantics that UAs can
actually do something useful with.
--
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] Sitecheck: 7 Sunrise Family website [sunrisefamily.com.au]
Joshua Street wrote: http://sunrisefamily.com.au/current/content/ The site looks good, it's a huge improvement over all the other 7 network web sites. However, one issue I have with it is why when I go to: http://sunrisefamily.com.au/ I get a 301 Moved Permanently pointing to: http://sunrisefamily.com.au/current/content/ Firstly, good URI design is important and redirects like this are annoying (although, at least it hasn't been done with a refresh or javascript). Why not just serve the site from the root directory? Secondly, 301 Moved Permanently might not be the best status code to send because if they decide to change their mind in the future about their URIs (like removing the redundant "/current/content/") then it could cause all sorts of problems with caches that respect the HTTP protocol. -- 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] Sitecheck: 7 Sunrise Family website [sunrisefamily.com.au]
Joshua Street wrote: Yeah, I'm not a huge fan of the URI structure either. It's running on a Zeus web server, which has some weird-ass mod_rewrite equivalent, but I'm not comfortable enough with it to use it. As for why 301 redirects, I explicitly asked for that after carefully explaining that it couldn't EVER be moved from where the 301 pointed. Prior to launch we were using 302 redirects, which (mainly for search engine reasons... though I'll admit I only ever think about Google, not Yahoo ;-)) I wasn't happy with. Hence, 301 redirects are the lesser of two evils, and I'm assured it's not going to move! I wouldn't believe that. In fact, here's a perfect example of why 301 shouldn't have been used. On Today Tonight (another 7 network program, for those of you not in Australia), the host made a point of it to emphasise that the address had changed to: http://yahoo7.com.au/todaytonight The old site address has been this for a long time: http://seven.com.au/todaytonight I expected to get a redirect from the old site to the new site, but I didn't. So, I went to the new site address and guess what! I got a redirect from the *new* Yahoo7 address to the *old* (well, still current) address. Plus, it's a 301 Moved Permanently, so once they realise their mistake (assuming this is one, and not just some bogus advertising attempt) and they attempt to rectify it by redirecting in the other direction using a 301, I wonder what will happen with caches that still believe yahoo7.com.au is a permanent redirect to seven.com.au. I've never tried setting up a loop like that, but I'd imagine the results won't be too effective. Another thing, if they do decide to switch to redirection to work the other way, and when the deal between Yahoo and 7 expires, and they go back to the current address, it'll screw everything up. Trust me, they've gone through so many URIs in the last 6 years, it's not funny. There's i7.com.au, aol7.com.au (no longer belongs to 7 network), seven.com.au, sevennetwork.com.au, yahoo7.com.au and probably many more I'm unaware 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] Failed Redesign and the Media
Kat wrote: In the AustralianIT there is an article about the new redesign of the Sunbeam website (www.sunbeam.com.au). I looked it up and it seems to fit Joe Clark's description of a Failed Redesign. http://australianit.news.com.au/articles/0,7204,17957834%5E24169%5E%5Enbv%5E,00.html Yes, it certainly does. There's some hilarious mistakes in there, like intentionally choosing a DOCTYPE that triggers quirks mode, intentionally using JavaScript1.2, and even sticking a
Re: [WSG] Failed Redesign and the Media
Kat wrote: I sent an email with questions about two of their decisions : why table-based layout and why not include character encoding? Their answer was [...] that encoding is not utilised for search engine reasons. LOL! I thought I'd heard all the excuses in the world, but this one takes the cake! Did they elaborate on exactly what issues they believe search engines have with pages if you specify a character encoding? Do they have any idea what a character encoding is? Does the character-encoding in your web-page reduce your search engine positioning? No, not at all! In fact, if the search engine can't determine the character encoding properly, they're more likely to be indexed poorly. But since they're using US-ASCII only, it doesn't really affect them that much. It would have an effect if they were using some obscure encoding that can't be properly sniffed based on some form of frequency analysis, though browsers/search engines are relatively good at that these days. -- 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] 2 Q: New web site, which DTD I should use? and Compresion
Roberto Santana wrote: 1) I'm going to create a new website fully standard, CSS, XHTML, WAI... I'd like to know your opinion about which DTD I should use, advantages and disadvantages... XHTML 1.0 Transitional XHTML 1.0 Strict XHTML 1.1 HTML 4.01 Strict. http://www.w3.org/TR/html4/strict.dtd";> Strict DOCTYPEs are best because most of the deprecated features no longer need to be used. There are some exceptions, such as the start or value attributes used in ol and li elements, but you'll usually only ever need to use a strict DOCTYPE. Plus, a transitional DOCTYPE will actually trigger Almost Standards Mode in Mozilla. The differences are minimal and you probably won't even notice the difference, but just to be on the safe side, full standards compliance mode is best. I recommend HTML over XHTML for various reasons I won't go into now, but mostly because the world isn't ready for XHTML yet. (There's plenty of discussion of the reasons in the archives and elsewhere on the web if you want to go looking) 2) What's your opinion about HTML, CSS and Javascript compresion techniques, removing spaces, line breaks... these could save a lot of bandwidth in a high visited website... But this could affect to spiders, Googlebot? It's a waste of time to strip spaces like that, though there is little harm in doing so. It only affects the reability for anyone looking at the source. Just configure your server to use gzip or deflate compression. There's plenty of info in the Apache docs that'll tell you how to set that up (assuming you're using Apache). -- 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] 2 Q: New web site, which DTD I should use? and Compresion
Francesco wrote: So even if a site is written fully XHTML 1.0 Strict compliant, and validates as such, it is still recommended to use HTML 4.01 Strict? There is much much more to XHTML than just ensuring the pages are well-formed, validate and conforms to the XHTML recommendation, Many of the issues are solved (or at least more easily solved) by testing the pages under XML conditions, but most authors fail to do so, or even understand how. There's a list of such issues in this article. http://lachy.id.au/log/2005/12/xhtml-beginners -- 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: Moral High-horse
James Bennett wrote: And yet, in many other industries, "I was doing my best" would be considered a completely unacceptable response from a contractor who failed to adhere to the standards of that industry. If, for example, a construction firm puts up a skyscraper that doesn't adhere to building codes, do they get to say "Well, we did our best, but it's just so darned difficult to follow every bit of those standards"? Do they get to mumble about how they just haven't had time to pick up new versions of the building codes and learn how to comply with them? You make a very good point here and, indeed, I have come across this very same attitude, however there's is an important distinction that can be seen between the use of standards-based web development and that building-a-skyscraper analogy. In the case of failing to follow building standards or codes of practice, there are serious penalties enforced if such standards are not followed properly. For example, failing to follow a standard could lead to fines, injury, being sued for negligence or, in the very worst case, the whole building collapsing. There's also the issue of licensing. i.e. You need to be a licensed/registered/qualified builder to build a skyscraper, or nearly any building for that matter, and failing to follow standards could result in loss of licence, among many other things. However, in the case of building a website, there are very few penalties - actually, there are none. You don't need a license to build a web site, you don't even need to be qualified or educated in any special way to build and publish a website. You're not likely to get fined for failing to follow the standards, and not very likely to be sued (although, it has happened for accessibility reasons in the past). The problem is that many people see the issue as "what will happen if I don't follow standards?"; whereas the questions they should be asking are "what are the benefits of following standards?", "how much easier/faster is it to develop with standards?", etc. -- 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] Firefox being naughty
Joseph R. B. Taylor wrote:
Perhaps you can help me with this mystery. I built this site over a
year ago http://holidayrealty.com, and recently Firefox (I'm using 1.5
(could be the issue)) has stopped displaying my background image on the
main content (on subpages only) and is instead just making the
background black! I even went into the CSS and added a
background-color: #FF and it didn't affect the behavior at all.
The background is displaying just fine on all pages I checked. Have you
tried viewing the page from another computer, if you have one available,
and seen the same problem? Does the same problem occur whether you're
viewing the page from the web or from your local file system? Do you
have any firewall software enabled that could possibly be interfering
with the page? I've known Norton Internet Security to cause problems
with pages before, which are fixed by disabling it, though I've never
been able to work out exactly why it causes problems at all.
However, there is a problem with the CSS that you should fix.
body {
...
background-image: url(../images/greenBG.gif);
}
You should specify a background colour and a foreground colour as well.
You shouldn't rely on the browser defaults, some users may change them
and their choices may clash with yours.
background: #X url(../images/greenBG.gif);
color: black;
(where #X is roughly the same colour green as the greenBG.gif.)
--
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] Background-Image download order
Todd Baker wrote: We are finding that the background images for our main navigation are downloading last and as such the white text is unreadable untill the background arrives You're assuming the background image will arrive. What happens if someone has images turned off? You should specify a background colour as well. Is there any logic I can apply (ordering CSS etc) that will affect the order the browser requests and downloads background images? Browsers would likely request images in the order that they are required, though there is no guarantee of this. If the markup for the navigation appears last in the markup, then due to incremental rendering, it is likely that the images required to render it will be downloaded near the end. If it's at the top of the markup, then it seems logical that it would be downloaded near the beginning. -- 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] Background-Image download order
Todd Baker wrote: On 02/02/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: You're assuming the background image will arrive. What happens if someone has images turned off? You should specify a background colour as well. Yes indeed we are adding a background colour that its "close" to the graphic. But you stated that the text is unreadable until the text arrives. The background colour is obviously not suitable. Is there any logic I can apply (ordering CSS etc) that will affect the order the browser requests and downloads background images? Browsers would likely request images in the order that they are required, though there is no guarantee of this. If the markup for the navigation appears last in the markup, then due to incremental rendering, it is likely that the images required to render it will be downloaded near the end. If it's at the top of the markup, then it seems logical that it would be downloaded near the beginning. Thats what I would of thought but the list for this nav is right at the top.. Is there a URI so that we may see the page and this effect occurring? -- 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 **
