Re: [WSG] Talking about odd user behaviour (was Re: PopUp windows)
It sounds ridiculous! And I do it!! haha, I can't believe I do that, reading this information made me understand. I don't know why, it's obviusly not necessary, and of course I try not to do it in gmail, but I like to have the back list almost empty. If I'm using google search, and send many queries, I almost always go back to clean them. And I know how to use computers...! I recently changed to Mac, and maybe not having the list of sites in Safari as in Firefox may change this unexplaiable custom. This is not a reason to keep the back functionality, just a weird, web developer case. Regards; Eugenio. On 3/8/07, libwebdev [EMAIL PROTECTED] wrote: Hi folks, Someone wrote: One of my favourite stats is that 30% of browser activity involves using the Back button .Proceedings of the Third International World Wide Web Conference, Darmstadt, Germany (1995). To which someone else replied: and the web, users and people have changed a lot since 1995, I would say so much so that that stat would know be unreliable... I did usability testing with 10 users of a medium-sized library website 18 months ago. Every single person, withOUT exception, failed to use either the breadcrumb navigation, or the left sidebar navigation. Each time they wanted to return 'home' or to somewhere they'd been before, they simply hit 'back, back, back' until they got there. If they needed to go somewhere new to complete or begin a new task, they still didn't use the side nav, they backed up to the 'home' page to start from there. I wondered if they did it because they thought that each new task should begin on the 'home' page, but every one I asked (about half of them) said 'no', they always used a browser like that (note that they didn't say they used my site like that, they used the browser like that). I was astounded. lib. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] (X)HTML best practice cheat sheet
Good! Maybe it's interesting to note here that when working in real projects, it doesn't matter if the future is (X)HTML 5 or XHTML 2: the thing is that today (for example) XHTML 1.0 or HTML 4.2 works properly everyehere. I was unquiet not knowing what to read, and heard this these days while asking which is the future. I found it useful and reassuring, and it's not ignorating in what people are working now. Well, hope this helps a bit. Regards; Eugenio. On 3/7/07, Keryx Web [EMAIL PROTECTED] wrote: This message has already been posted to the what-wg mailing list and to the wasp-edutf mailing list. Please forgive duplication and feel free to ignore... Hello yet again! For the benefit of myself and my students I have started to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) It is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. A few notes: - I have grouped the elements according to how I teach. It may not reflect the way you think of them, and it does not reflect any spec. Known issue - I won't change it. - All advice is appreciated, but if it can't be boiled down into something short I can't use it. Please feel free to suggest a wording. - If you would like to give me feedback by changing the OO-document and mailing it to me, please use the versioning so I can track your suggestions and criticism. Many thanks. Lars Gunther P.S. I'll include anyone who provides feedback in the document. It currently says: The recommendations in the table above represents the personal opinion of Lars Gunther, although valuable suggestions have been provided by April Siegfried, Christian Montoya, Alexey Feldgendler and Simon Pieters. This list is intended to be used as a reference while coding (or seeing other's code) and as notes for learning (X)HTML. Strict doctypes that are supported by the browsers of today is recommended for normal web pages. XHTML 1.1 Mobile is recommended for pages primarily intended for cell phones and similar devices (WAP 2.0). Proprietary elements are included for reference if stumbled upon. A few XHTML 2.0 and most (X)HTML 5 elements are included as examples of where (X)HTML might be heading in the future. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Javascript to check for Handheld Devices
Once I saw a Nokia trying to serve a wide (media=screen) CSS, I solved it using a media=handheld stylesheet, almost empty. It would be a problem if these little devices are trying to load the 'screen' sheet, do you have handheld specific defined sheets in your code? Sorry to ask, but if it doesn't help you then it'll help me. Best regards; Eugenio Costa. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Content negotiated links: why so bad?
That's what I do, and it's really swift of doing, even though you never saw an htaccess file. I use it, there are some disadvantages on server load but in my projects, I don't care. Well, it works as expected. Best regards, Eugenio Costa. On 3/1/07, Adrian Lynch [EMAIL PROTECTED] wrote: Or just use mod_rewrite to rewrite the URL's from nice clean URL's into the crusty querystrings on the fly. If you are familiar with mod_rewrite it would take 15 minutes, otherwise might take an hour or so to work out what you need but you wouldn't need to even touch the backend. A *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
