Re: [WSG] IE7 b1 :/
On Jul 31, 2005, at 3:19 PM, Justin Carter wrote: IE7 will be far from a disappointment. Sure Beta 1 doesn't seem to give us anything much new and the UI is a bit topsy-turvey but I think it's mostly due to the fact that it has come straight out of Longhorn (Vista). From the IMPRESSIVE list of fixes and newly supported features posted on the IE blog I think that IE7 is on the right track, and the fact that Microsoft have shared this information with the community is one of the most positive things to come out of Redmond in a long time. As a developer I'm quite satisfied with what I've seen so far, and if they can get the UI right then the end-users might be quite satisfied as well! I can't wait for Beta 2 to give it a real workout :) Hear, hear! I agree that the recent communication from the IE development team is exemplary. These people have convinced me more than Robert Scoble has done in his still pretty MS-tainted approach to blogging. It's time for the o so sceptical standards missionaries to wait for the proof of the pudding. They might be surprised at the taste of the new browsing Microsoft is cooking. Jeroen ** 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] Longhorn Avalon - seismic shift for web standards?
On Jul 15, 2005, at 2:54 AM, Paul Ross wrote: [From a PC mag article] In a nutshell, Avalon means developers are now free to code without considering the resolution of users' monitors. This ensures that apps developed in this environment will work on just about any display, from mobile phones and PDAs to wide-screen notebooks and high-end desktop systems. I would say that this statement is not the complete story. The available canvas still is of interest to web developers and coders -- whether the OS works with pixels or Bezier curves. Basically, the users' human factors, combined with the monitor's width, height and resolution, determine how many menu items (or icons) will fit next to eachother. A 23 widescreen display still would offer a lot more space to organize content, branding and navigation than a typical handheld device. Don't throw your dedicated handheld-optimized version out of the window yet. What does all this mean for the web standards community? Am I reading too much into this by thinking this is a seismic shift in the way we could be building websites in the future? In particular - what are the implications in the XHTML/CSS path versus something like Flash? If you want scalabale vector graphics online, I'd still go with Flash. It'll take some time before a version of IE with the necessary XHTML/SVG/CSS support has a strong enough user base to warrant a switch from plugin to browser-only. Jeroen ** 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] Need some MAC screen grabs
Jacobus van Niekerk wrote: Hi all, I need the MAC girls guys ;) to help me out. Can you please send me a screen grab of the following url http://www.parachute.com/te/smallbusiness/ Heard of http://www.browsercam.com/ perhaps? Jeroen PS: your character encoding is going bazerk (windows-1250?), better to fix that on an international mailing list. ISO-8859-1 will do just fine. -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] DTD is a formality?
Kornel Lesinski wrote: The issue at hand is that [productname] is completely compliant, but is more modern than HTML 4.01. If you remove the doctype tag, all your rendering issues should be resolved. This is sooo untrue. If they require invalid HTML, their product is NOT compiliant. Funny you reach that conclusion just on the OP's mail (in which te makers of the menu state it to actually be compliant!). If the menu at hand is written in valid XHTML strict, for instance, putting a HTML4.01/trans DTD in top of the html _will_ cause validation issues and _might_ cause rendering issues. If you remove doctype, browsers emulate IE5 invalid CSS interpretation. Far from being modern. I would dare say that this is at best partially true. Opera sure tries to emulate IE when it is told to do so (and even emulates some parts of IE's behaviour while in 'Opera' mode), but I'm not so sure that a Gecko in quirks mode mimics IE on purpose. Removing the tag will solve your rendering problems. ...will cause... Why? I'd get rid of that menu. It *needs* browser *bugs* in order to work! Is this menu accesible when: - javascript is off? - styles are off? - styles and js are off? - keyboard is used to navigate? The sequence of your advice and questions suggest you are assuming all answers to be 'no' beforehand, whilst you haven't seen any line of the menu code whatsoever. I'm sorry if my reaction feels a bit harsh, but jumping to conclusions like this just doesn't help the standards' case, does it? ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] DTD is a formality?
Sam Brown wrote: The issue at hand is that [productname] is completely compliant, but is more modern than HTML 4.01. If you remove the doctype tag, all your rendering issues should be resolved. Using one of our older and backwards compatible menu packages might be the only solution if you must have the doctype tag. However the doctype tag is really a formality used for checking compliancy and nothing more. Removing the tag will solve your rendering problems. I was not aware that a DTD was a mere formality. In my experience, operating without a DTD puts most browsers into Quirks mode which, by its very definition, isn't a standards compliant rendering mode. Basically, my purpose for sending this is to acquire more understanding of the purpose of the DTD. Is it there to set the rendering mode, or is it, as this support person purports, simply a formality? Russ's response covers the purpose of adding a DTD to your HTML code (DTD meaning Document Type Declaration in this situation - not to be mistaken for Document Type Definition, to which the declaration actually refers). A now common 'feature' of DTD's is that it puts modern browsers into a specific rendering mode (quirks, almost-standards or standards-compliant). [2] You already know this part, I understand, but this effect of a DTD is not what DTD's 'are there for'. It's just a handy way for browsers to deal with the fact that the _large_ majority of web pages is a 4th generation legacy that just isn't going to go away. And it's pretty hard to market a browser that renders only a handful of real-world sites (apart from all the geek webdev blogs ;-). So -here it is- the world is not perfect, the majority of web users still surf with IE5.x or 6, the latter possibly having more issues with standards-compliant code than with tagsoup. [2] Some web developers purposefully keep IE6 out of standards compliance mode, because this saves you from coding two separate IE css files in some cases. In this particular case, you may want to: - try and find out to which standard the menu is coded and use that for your own code as well; - or try and convince the makers of the menu to provide you with a HTML4.01 version (could be hard to achieve ;-); - or ditch the menu (which apparently is out of your reach); - or ditch the doctype. I'd try the first option, but when that fails, stick with the last. Pursuing standards is not the way to go if this could result in a majority (!) of your visitors not being able to use the menu normally. [1] http://hsivonen.iki.fi/doctype/ [2] http://www.positioniseverything.net/ Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Advantage of word-wrapping? (was: Re: [WSG] double space after period)
David R wrote: I do have a relevant question relating to this problem: Is there any advantage in word-wrapping markup'd paragraphs? The most important situation in which word-wrapping is useful is with justified text. Good word-wrapping prevents awkward word spacing in such text, rendering it more legible. There are a few pittfalls though, with word-wrapping: it is language dependent and browsers are basically morons with regard to text-handling in general and word-wrapping in particular. The only element I know to provide predictable word-wrapping is [wbr], but this is a non-XHTML element, thus needing a modified DTD which includes this element. And then again: [wbr] doesn't add a hyphen when a word is actually wrapped, so it is mainly useful in wrapping URL's and the like. The soft-hyphen (shy;) is sometimes used for wrapping purposes, but it was never intended for such use and produces unpredictable results across browsers. Word-wrapping will only become a viable online typesetting option when browsers are capable of tapping into an OS provided spelling/wrapping/ grammar system. In such a situation, I can imagine a browser actually picking up [lang=] attributes in mark-up to switch between wrapping rules and authors only needing to specify 'on' or 'off' for word-wrapping, e.g. through: p { word-wrap: (auto|no-wrap); }. Until then, I just don't use any justified texts online. ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] empty named anchors
David R wrote: Andy Kirkwood | MOTIVE wrote: I have come across a couple of instances of this where headings have been enclosed in an anchor, i.e. a name=anchor id=anchorh1Heading text/h1/a This causes the text colour of the heading to change when moused-over (although not a link). From an interface perspective this can be quite confusing. (A feedback cue that suggests interaction is possible when it is not). This is why a:link:hover and a:visited:hover are preferable over simple a:link :) Maybe I've missed some standards or accessibility point, but I'm accustomed to coding as follows: h2a name= id=/aSome heading/h2 Jumping works like a charm, and no hyperlink behaviour other than that ever shows up. Afaik, there are no problems with this method whatsoever, plus you don't rely on CSS to prevent a particular GUI behaviour. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] Non-validation and web standards
Lyn Patterson wrote: Bert and Jeroen Your advice much appreciated. You're welcome. Am blushing as I report that when I removed ALL the hacks, the site stayed the same and it now validates perfectly. I think those hacks came from a very early attempt at css and I just kept putting them into stylesheets. I haven't tested in older browsers yet but it looks OK in current ones. No problem, I've been there myself. Next to writing CSS rules, deleting them can also prove to be very enlightening. ;-) Good luck with the site, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] pop quiz: calculating specificity of group selectors
John Allsopp wrote: OK, thanks for all the answers, I buy them :-) That would be four cents then, please. Anything else? ;-) Jeroen Visser -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] Learning to design Accessibility
David McDonald wrote: Try the W3C as a good starting point: http://www.w3.org/TR/WAI-WEBCONTENT/ http://www.w3.org/TR/WCAG10/ http://www.w3.org/TR/WCAG10/full-checklist.html http://www.w3.org/TR/WCAG10-TECHS/ And possibly --as 2.0 is in its final stages--: http://www.w3.org/TR/WCAG20/ This second version of WCAG is set up in a somewhat different way than WCAG1.0 so it may be of interest to learn about them before it actually becomes a W3C recommendation. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] 88x31 WSG Buttons?
Peter Tilbrook wrote: [request for a 88x31px WSG button] Get. A. Life. I always find it funny that people who post such replies do not seem to grasp the inherent reciprocal nature of them. Make my day! :-) For Mike: if no button in that particular size exists, you could do a proposal based on the 88x15 version. I doubt that our fellow WSG members would disagree --just make sure the 'WSG style' is sustained. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] forcing IE6 into quirks mode
Gunlaug Sørtun wrote: Wayne Godfrey wrote: Enjoy your upcoming Mac, I know you will. So I've been told by many. Hope to have an iMac up and running before x-mas (have already paid for it). Now I only have a dual-processor high speed multi-tasking workstation with multiple screens, and support-units with more screens-- all running win2K-pro. Not bad for a carpenter. ;-) I think your iMac will fall silent in such company. :-D Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] forcing IE6 into quirks mode
Gunlaug Sørtun wrote: Jeroen Visser [ vizi ] wrote: Gunlaug Sørtun wrote: I know of no limitations in IE6 when doing this, and it saves some coding too. The improved box-model isn't reason enough to debug several versions of IE/win. IE/win can be made to almost behave like a good browser should-- in quirks mode. It's really weird. On one side (Robert Scoble's IE wishlist entries) developers are screaming that IE should adhere to standards (box model, XHTML as application/xhtml+xml etc), but when there's actually some progression, you stick to the nineties' quirks approach. ;-? I don't belong to the group of screaming developers. Hi Georg, Sorry for this misunderstanding --I didn't mean to group you in any way. It's just that I was a bit amazed about your view when in general, the web standards 'society' regards IE as the largest obstacle in standards-compliant webdesign. To me it seems that 'we as webdesigners' (pro or amateur doesn't matter) should show some appreciation towards MS for steps they do take, not just complain about what they don't do. I _stick to_ the browsers which are giving me what I want; Opera, Moz/FF, Safari... If Scoble wanna know what I want, he can surf over to W3C and take a look. The rest is just noise-- to me. I only support IE/win because I can, not because it matters to me. IE6 is less of a problem in quirks mode, because it doesn't need so many alterations to a page that works well when developed in Opera and the other good browsers. I don't like to kill browser-bugs in more versions than I have to. Guess I'm lazy. :) I can understand that you want to minimize the number of hacks and time invested in them, but I don't think a designer's opinion on a browser matters. If a majority of visitors to his clients' site use IE/win, then he should cater for that. And in my opinion he should do that in the best possible way (i.e.: use IE6 standards mode whenever possible). Also; it's easier to code for Lynx when I don't have to change things to make IE6 happy. _That_ matters to me. Could you explain this to me? In the end, the website visitor matters. I think we agree on that. But if I were to choose between using an extra hour to improve a design for 80% (or more) of the visitors or using that hour to improve it for a browser like Lynx (or Omniweb, or iCab, for that matter), I'd go for the 80%. Don't get me wrong: I'm all for semantically correct, usable, accessible and standards-compliant sites that look great and degrade gracefully. But practice --as usual-- is far different from such theory, and every designer has a limited supply of time and money for any given project, so you have to choose how and where you invest your resources. I think those resources should go where they have the largest impact on the largest audience. If / when some software are reasonable in line with the standard code I use, it will be supported by me. That includes everything Microsoft launch-- but only if it is up to the job. Can you point to a case where IE is not 'up to the job'? What constitutes 'not up to the job'? Once again; my preference is Opera-- latest stable version available at any one time. Those of you who make a living out of web design may, reasonably enough, have other preferences and priorities. Which browser I use is not that important (other than that developing in Mozilla is faster and more reliable than in IE, for instance). What the people out there use, who visit the site I design, that's important. Thanks for the example. I'll look into it. Maybe I'll use it-- if IE6 will behave on all the rest. For more background information on the exact differences between IE6 in standards mode and IE5+ quirks: http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Usability dogma's [was Re: [WSG] Font size]
Felix Miata wrote: David Laakso wrote: Jeroen Visser [ vizi ] wrote: I myself set a base size on the body element (most of the time 76% like Owen Briggs) and then use em's to set up the rest of the typography. Hmm, 76% on the body element, thats 24% smaller than my default? Kinda tough on us older folks. David, you understate the problem. I don't know why there's this 'designers who reduce browser base font size are evil' attitude. I go with Owen Briggs, who relates browser default size to general OS GUI elements' font size. If I follow your and Davids train of thought, I can bet that I get several reactions by visitors 'complaining' that the type is so large, and if I can't make it smaller (no, I'm not kidding). Bottom line: there's no general _rule_ you should apply as a designer, other than that for every design decision you should have a good reason. I.e.: you never should apply something just because 'you feel like it', but instead have arguments why you do it that way --be it usability concerns, market or site audience analysis, or conceptual/design aesthetics. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] forcing IE6 into quirks mode
Gunlaug Sørtun wrote: Terrence Wood wrote: Does anyone on this list deliberately force IE6 into quirks mode? Yes, always... :) No, only if it's necessary and unavoidable, e.g. in Eric B. Bednarz's fixed-positioning solution: http://devnull.tagsoup.com/fixed/. I have seen this done on a couple sites (ok...one), where the site has a comment in the first line before the doctype ( = quirks mode ).the notion of doing this seems attractive at first glance because you can lump IE5, 5.5 and 6 together and develop for a single IE box-model. If you want to flip IE6 into quirks, the only way would be to place an XML declaration before the DTD. As far as I know, no other elements are allowed before the DTD. Are there any other benefits/limitations of doing this? IE6 seems to be more stable and predictable in quirks mode than in its almost standard mode. I use IE-expressions to get 'max-width/min'- imitations to work in IE6, and they are almost always killing IE6 in almost standard mode. My gamble: you're referring to 'document.body.clientWidth', whereas this object doesn't exists in IE6/standards mode. Instead, IE6 then uses the DOM-compliant 'document.documentElement' approach. If you use expression() in CSS rules for IE, you should check for IE6 to be in 'CSS1Compat' mode before choosing element notation: width:expression(((document.compatMode document.compatMode=='CSS1Compat') ? document.documentElement.clientWidth : document.body.clientWidth) 780 ? 780px : auto); (Just an example.) I know of no limitations in IE6 when doing this, and it saves some coding too. The improved box-model isn't reason enough to debug several versions of IE/win. IE/win can be made to almost behave like a good browser should-- in quirks mode. It's really weird. On one side (Robert Scoble's IE wishlist entries) developers are screaming that IE should adhere to standards (box model, XHTML as application/xhtml+xml etc), but when there's actually some progression, you stick to the nineties' quirks approach. ;-? Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Font size
Javier wrote: I'm trying to develope a site with proportional font size. I've seen people that apply a font small in body and then use em's in all other settings. I've seen people that apply a 65% font-size in body, others a 100%, etc.. and then use em's in other settings but others use percentage... Now I'm really confused... Hi Javier, All the trouble of font-size in a nutshell: http://www.thenoodleincident.com/tutorials/typography/ I myself set a base size on the body element (most of the time 76% like Owen Briggs) and then use em's to set up the rest of the typography. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Site-Check:
Felix Miata wrote: Kristof Rutten wrote: http://www.sportopolis.be 12px body is bad, bad, bad. You make it sound like Kristof is your little puppy who has just taken a leak on your precious new carpet. ;-/ A little explanation or a link to background info would've been nice. For Kristof: http://www.thenoodleincident.com/tutorials/typography/ This pretty much covers the issues involved: typography, design decisions, browser hick-ups and usability. You can also check out the font-sizing page at the CSS-discuss wiki: http://css-discuss.incutio.com/?page=FontSize Good luck, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] (another) Site Check :)
Dave Elkan wrote: Fellow WebStandardites, I've just finished my first site since moving over here to the UK from Australia. Unfortunately for that reason I don't have all of my equipment with me and to make matters worse we don't have a mac testing station here at work. Is there any chance someone could have a look at this site in ie5 for mac and tell me/take a screenshot so I can see how horrid it looks? The URL is http://www.wallpaper.com Thanks for your help! Hi Dave, Wellcome to Europe for starters, then. :-) It must be really a treat to design a site for Wallpaper*, or am I too biased by the style of the magazine? ;-) I've looked to your page in IE5.1.7/MacOS8.6 and Mozilla1.3.1 (same OS), and there are a few problems: http://www.vizi.nl/temp/wallpaper/ie517.png (28 KB) http://www.vizi.nl/temp/wallpaper/mozilla131.png (102 KB) So the searchbox is a problem in Mozilla, causing the layout to be stretched broader than you probably intend. In IE, the footer section floats beside the header, so the page gets really wide. IE/Mac is notorious in floats, so I guess a little bit of googling should give you a hint for a solution. Ciao, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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 Lindsay Method, version 2
Lindsay Evans wrote: In order to stop Russ from hassling me about it every time I see him, I've thrown together a small demo/explanation of the latest greatest image replacement method (well, 'fancy heading method', really): http://lindsayevans.com/experiments/lindsaymethod_2/ Just to be somewhat annoying: what are the advantages of your method over sIFR2? Despite (or thanks to) its dependancy on Flash, it has a broader support (IE/mac, Opera, Gecko, Safari). If I would be a frantic typography guy, I'd use sIFR. ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] pt, em and ex
Felix Miata wrote: Jeroen Visser [ vizi ] wrote: 'px' is the worst unit to define font size in, as Internet Explorer still cannot increase or decrease the size of fonts set in pixels. pt is worse. IE can't resize it either, and it depends on both DPI and resolution, not just resolution, making its ultimate size even more difficult to predict. Ack. Common accessibility and usability practice is to allow visitors the freedom to adapt font sizing to their personal preferences. I don't think common is the best choice of word for that sentence, unless you take the word common to mean something merely more than rare. It really isn't that common yet except among students of accessible design. Best or good would be better choices. Obviously you're right. Consider it wishful thinking on my part. ;-) Pixels are not a relative unit; they're as absolute for screen rendering as point sizes are for the printing press. IOW, the problem is that px is not relative to anything inside a browser viewport, the only place the term relative has relevant meaning in the world of CSS. Unfortuately, the CSS spec makes people think px is a relative unit :-( http://www.w3.org/TR/CSS21/syndata.html#value-def-length Reminds me of a discussion on Bugzilla covering a rounding error that Gecko introduces while computing layouts because the engine internally works with a smaller virtual 'pixel' which gets converted to screen pixels only afterwards. :-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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 Lindsay Method, version 2
Lindsay Evans wrote: No Flash, works with scripting turned off, text is selectable (yes, I know you can select the individual sIFR bits, but that just ain't the same :)), colours, size, etc. are easily manipulated via. CSS, As I have understood, you can select large text blocks with sIFR also; you just don't see the headings being selected (this is a serious flaw, dont' get me wrong, but you can select textblocks). probably has a better chance of being understood by screenreaders that are in use today. Would be nice if someone could test this (sIFR vs @font-face) with Jaws and a tactile viewer (braille). This is especially interesting as most accessibility applications tap into IE's rendering engine. I'm sure there are ways around it in sIFR, but from what I can see it doesn't scale the text according to user font size preferences, or obey user style sheets. sIFR scales headings to the box available at script execution, basically allowing you to set the size in the stylesheet. It doesn't do dynamic scaling (i.e. scaling after document load), however, which is a pity. Plus it just doesn't feel as 'hacky' to me :) Anyway, it's just an idea, if you want more control over typography, then go with sIFR (or get Quark start doing print design :p) Am there, doing that. ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Question to the others ...
Marilyn Langfeld wrote: Hi folks, My first post, since I've worked in print longer than web. In print, an em (and en) are mostly used to describe dashes (of the width of M and N) in a font. So they are appropriate to the task when used for that. They have been slightly redefined for the web (since an en is not always half an em). Hi Marilyn, To add to your posting: and the capital M or roman m are nowadays not really an em or en wide. An em is a unit of measurement defined as the point size of the font12 point type uses a 12 point em. An en is one-half of an em. http://www.alistapart.com/articles/emen/ An excellent explanation of the em and en units: http://css.nu/articles/typograph1-en.html#Ch23 As always, someone has dug up al the idiosyncrasies that made id from the physical world to the digital space. :-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] pt, em and ex
Mary Krieger wrote: Barring browser weirdness for a brief utopian moment, is this the way it is supposed to work.? In order for any text to appear, someone somewhere has to have chosen a font face and size. So choosing to use relative rather than absolute units for font size moves where the decision occurs. Precisely. This also is the reason why 'px' is the worst unit to define font size in, as Internet Explorer still cannot increase or decrease the size of fonts set in pixels. Common accessibility and usability practice is to allow visitors the freedom to adapt font sizing to their personal preferences. If the stylesheet belonging to the page uses an absolute unit like pt to set the size of the base font, the browser will attempt to use the page's stylesheet to set the default font size. The specified author stylesheet will almost always be used; only an !important in a user or browser stylesheet will override this. See: http://www.blooberry.com/indexdot/css/topics/cascade.htm If the stylesheet belonging to the page instead uses the relative unit % or ems to set the size of the base font, then the browser will set the default font size relative to the local machine's default stylesheet's font size. Here 1 em behaves the same way as 100%. What happens is that instead of forcing an absolute reference font size (in px or pt), you take the user's font size as the basic type size.. If the stylesheet belonging to the page instead uses the relative unit px to set the size of the base font, then the browser will set the default font size relative to the local machine's resolution. Pixels are not a relative unit; they're as absolute for screen rendering as point sizes are for the printing press. If the remainder of the font-sizes in the stylesheet are set with relative units, the page should retain the size relationships of the page's stylesheet no matter where the decision about default font size occurs. Unless the user declares he wants to see h1 elements at 400% of the base font size. ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Site Critique
Laurie Keith wrote: Hi, If any of you busy people have a spare 15 minutes, can you give me an honest evaluation on our new corporate web site. http://www.createwith.com Hi Laurie, Others have cracked down on the Flash thing, so I'll focus on some other issues. Basically, it's a clean, neat site, but it has some problems: - The site doesn't show the usual 'hand' cursor when hovering a link. While this may look cool at first, it is a serious usability problem. The hand cursor is the single most effective way to say: 'this is a link'. - The scrollbar on the Press page is a bit 'under designed'. :-) If you choose to use Flash, make the scrollbars blend in with the overall design; a standard Windows bar just is out of place, so it seems. - Why the arrow in the top right? Why not maximize the width of the Flashmovie in the first place? Bonus: it looks better, too. - The small type in the portfolio sections (the text under the images) is pretty hard to read; I'd suggest to (a) increase the font size, or to (b) take a lighter weight _and_ to make the type pitch black, or to (c) disable anti-aliassing for that type. - The placement of the submenu is not really logical. I understand the design choice to place the menus on top of each other, but I'm a graphic designer, so that doesn't really count. ;-) My guess would be that the feedback (I click on Work and there's a submenu for this 'Work' section) would be much stronger if the menus would be next to eachother, or if a line or other visual clue would connect the highlighted menu-item with its submenu in the bottom half. The portfolio is pretty neat, so it's a pity the rest of the puzzle doesn't really fall in place to convince people to stay and click around (and that's what this site needs, right?). Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] 10,000 posts, we have a winner...
russ - maxdesign wrote: OK, we have decided to give the person who did the 10,000th post a prize (thanks to Core member David McDonald for the idea). Re: Web Standards Eye Candy: http://www.scottschiller.com/ By Nick Lo - Fri 12 Nov 2004 at 10:33 PM So, what does Nick win? One free copy of Apache Essentials: Install, Configure, Maintain from Friends of Ed: http://www.friendsofed.com/books/1590593553/ Congratulations to Nick! (Just wondering: what if Nick is an IIS developer? ;-) Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Re: It's all in the MIME
Alan Milnes wrote: So does anyone have a link to an article which can tell me how to properly serve up application/xhtml+xml using PHP? Jeroen Visser shared http://www.workingwith.me.uk/articles/scripting/mimetypes/ as a link before... that tells you how. The datestamp on the message was Thu, 11 Nov 2004 01:48:36 +0100 if you want to read the original. Thanks - unfortunately it seems to have some errors - no content type is sent and Firefox seems to have problems with it as well. Why is the content-type not sent? What errors or warnings does PHP display? What content-type _is_ sent? What problems does Firefox have? Some possible reasons for this script not to work: - headers are already sent out by PHP; - one ore more conditions are too narrow or wide (especially if regular expressions are used, as in the above example); - your application conflicts with the output buffering in the script. The script on the above URL is not something to just cutpaste into an exisiting PHP application. I guess it would need some tuning and work to integrate it into an exisiting site. For example, this script also buffers all PHP output to transform it into HTML4.01 for IE and other non-XHTML-savvy user agents. For most sites, you could strip that part and serve XHTML1.0 corresponding with the HTML4.01 compatibility guidelines. In that case, you only need to switch the content-type header and need not tweak the actual HTML document. Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Re: It's all in the MIME
Alan Milnes wrote: Why is the content-type not sent? What errors or warnings does PHP display? What content-type _is_ sent? What problems does Firefox have? Some possible reasons for this script not to work: - headers are already sent out by PHP; - one ore more conditions are too narrow or wide (especially if regular expressions are used, as in the above example); - your application conflicts with the output buffering in the script. Thanks for your feedback. I put it into a test site to try it out - I've actually tried a lot of these scripts but not gotten any of them to work satisfactorily yet! My pleasure! I know it's sometimes frustrating when a script doesn't work the way you would dexpect it to, but also that it is very satisfying when you get it to work and see the results. :-) I have now gone back and spotted a mistake that I made and it now seems to be working fine! That's good news! For some additional info: I usually perform three tests to make sure these content-type things work properly: - Firefox infopanel should show 'application/xhtml+xml'; - IE/Win shouldn't pop a 'save as' dialog but show the site (the dialog is the sign you're serving application/xhtml+xml to IE); - the following testpage of a friend of mine shows 'text/html': [http://sandbox.bednarz.nl/http/get.html?host=www.google.comuri=/] (Just to be concise: fill in the host and uri of the page to check instead of the 'www.google.com' and '/'.) Good luck, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] Vertical Alignment of Relatively Sized Text
Paul Farrell wrote: I have a series of floats in a header. In particular I have a string of text on the right marking the spot for a date script output. I would like to know if anyone knows a way I can maintain an alignment where the bottom of the date string is aligned to the bottom of the text in the logo as a user increases/decreases font size. Hi Paul, You might want to check out Doug Bowman's article on the positioning solution for the menu at http://www.adaptivepath.com: http://www.stopdesign.com/articles/absolute/ In this article is the answer to your question. While it might not be an exact 'baseline' match, I think you can get very close if you tinker with the technique Doug describes. (For something totally different: I would advice against using [h3] for your date script output. Use a [span] or [div] instead, maybe a [p], but reserve [h3] for a real heading at the third level of a document structure.) Good luck, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] Creating Nice Pop-Ups
Mark Harwood wrote: Hey list, Right im using the good old methord of nice pop-ups as shown by by idol youngpup (http://youngpup.net/2003/popups) now as soon as you use onClick in your HTML WebXACT and Bobby throw up a fit saying that it does not pass AA thanks to 9.3 Make sure event handlers do not require use of a mouse. Now that is why I don't like these automated 'get yourself a Johnny Accessibility approval' sites. I can't see what is wrong with extending the plain href= with an extra feature for able UA's with 'onclick'. Just make sure you get the thing to fall back gracefully. Which my links dont require, now what im wanting to know is there away to call onClick form a external JS and then apply it through another function? Allowing us to have Accessible Pop-ups? An excellent article on ALA covers just this: http://www.alistapart.com/articles/popuplinks/ It is a bit complicated, as it uses the long route to connect a function to an event bubbling through the DOM, but it covers the things you describe. I've written a smaller, dedicated piece of script to add popup behaviour to links. It's not as elegant as Caio Chassot's solution, but still: // Start when XHTML document is loaded completely... // window.onload = function() { if (document.getElementsByTagName) { var allLinks = document.getElementsByTagName('a'); // Loop through all hyperlinks in the document. // for (var i = 0; i allLinks.length; i++) { switch (allLinks[i].className) { case 'popup': // Define onclick event for this hyperlink. allLinks[i].onclick = function () { // Fetch ID for this link. var thisPopupVars = this.id.toString(); // Fetch params from id attribute. var thisPopupWidth = thisPopupVars.substring(1,4); var thisPopupHeight = thisPopupVars.substring(4,7); var thisPopupScroll = thisPopupVars.substring(7,8); var thisPopupName = thisPopupVars.substring(8,(thisPopupVars.length)); // Fetch URL from href attribute. var thisPopupURL = this.href; // Prepare string for popup. var thisPopupParams = 'width=' + thisPopupWidth + ',height=' + thisPopupHeight + ',location=1,menubar=1,scrollbars=' + thisPopupScroll + ',status=1,toolbar=1,resizable=1'; // Check if a popup already exists and close that popup. if (popupWin) { popupWin.close(); } // Open the popup with the defined parameters URL. var popupWin = window.open(thisPopupURL,thisPopupName,thisPopupParams); // Prevent the event from bubbling on. return false; } break; // End of first-and-only case in this switch. } // End of switch. } } If you include the above script through an external .js file or in the head, you can use an XHTML syntax such as: a href=http://www.google.com/; class=popup id=x4003001GoogleGoogle/a With the ID attribute you set some params for the popup: x - ids should start with [a-zA-Z], useful to make multiple links with the same params (e.g.: 'y4003001Google'). This first letter is neglected by the routine. 400- Width of the popup (100-999). 300- Height of the popup (100-999). 1 - Toggle for scrollbars: 1=yes, 0=no. Google - Name of the popup window; no spaces I guess. Maybe you'll find this useful. I have taken this from a larger routine, so the warranty ends at the front door. ;-) Good luck, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] discussion at juicy studio: It's all in the MIME
[EMAIL PROTECTED] wrote: I have been following this discussion (belatedly) It's all in the MIME http://www.juicystudio.com/all-in-the-mime.asp first paragraph: There have been a lot of articles recently about web standards; in particular, using XHTML and serving it as text/html. Personally, I'm not that bothered whether people serve XHTML as text/html, but think it's important that authors understand why this is wrong. Although I'm not bothered about content developers serving XHTML as text/html, I don't agree with people encouraging content developers to deliver XHTML as text/html. I wondered what other memebrs on the list thought about it and its implications? Others have written about it and about server-side solutions to cater for IE while still sending application/xhtml+xml to the likes of Mozilla, Opera and the W3 HTML validator: 1 - The issue [http://www.hixie.ch/advocacy/xhtml] 2 - The parsing consequences (old, but still valid): [http://www.hut.fi/~hsivonen/test/xhtml-suite/xhtml-index] 3 - The solution (PHP) [http://www.workingwith.me.uk/articles/scripting/mimetypes/] 4 - The solution (.htaccess, can't recall the source): RewriteEngine On RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0 RewriteCond %{REQUEST_URI} \.html$ RewriteCond %{THE_REQUEST} HTTP/1\.1 RewriteRule .* - [T=application/xhtml+xml] Ciao, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** 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] Well since everybody...
Kim Kruse wrote: [sitecheck on http://www.mouseriders.dk/] Hi Kim, It's a clear and easy to navigate site. Some small remarks: * In my Mozilla, the subheadings are smaller than the copy text. I assume that is not your intent, but if it is I'd advice against it as (descending) font-size is a key aspect in recognition of page structure (title, subheading, text). * I see a one pixel difference after hovering over the menutabs (the bottom 2px blue line becomes a 1px line). This usually is a result of sub-pixel rounding in Mozilla, and most of the time this can be solved by explicitly setting a value for line-height on the pundits. * I think your logo in the top right could use some more whitespace; it's a little close to the tab 'Kontakt os' (to my taste). * It would seem more logical to use bold (emphasis) for the selected tab and normal font-weight for the others (just the other way around ;-). I thought a lot about tab index. Is there any need for them... unless you want to direct tabbers a certain way round the pages? If the underlying code results in an odd 'natural' tab sequence (for instance due to floats), you could use tabindex to restore a logical behaviour. Otherwise, don't bother. ;-) I'm also very unsure about the access keys. (I have one skip to content - accesskey=S) I read a lot about access keys and most of it was actually negative! What to do? Certainly 'S' as an accesskey is not a very fine idea, as it can be easily 'mistaken' for Save, instead of Skip. Because the implementation of accesskeys varies from browser to browser and from OS to OS, it's best to be cautious. I've heard of accesskeys conflicting with widespread shortcuts for cut, copy and paste, for instance --can't recall the browser in which this happened though. An blind friend of mine told me once he almost never uses accesskeys to navigate through a site, because of these conflicts and because there's no clear and common usage on websites. For 'heavy' users, accesskeys sometimes come in handy (e.g. on forums or community sites), but then you'd have to signal that you've provided accesskeys by underlining the relevant character in menu items (just as Windows does). Just my two cents. Good luck, Jeroen -- vizi fotografie grafisch ontwerp - http://www.vizi.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **