[WSG] 301, 302 and Referer
How do different browsers handle the Referer header when redirecting with a 301 or 302? Thanks. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] WSG Digest
Durante los días 21 y 22 me encontraré fuera de la oficina por vacaciones. Si es un asunto urgente por favor llame a Marcela Nabalón al 6947216 y le pondrá en contacto con quien corresponda *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] iphone should not be part of your url
It's just a name branding exercise... having an "iphone" in your domain, e.g as a subdomain has more to do with marketing efforts and user identification (I've got an iphone and I want to use it on something) than it does with the code it actually presents. Look under the hood at iphone.news.com.au and you'll see it presents HTML, JS and CSS that works in any browser. I browse it on my desktop because it presents information quicker than the main news site. News could quite easily have shown it under the mobile.news.com.au subdomain but do you think that their marketing bods would have gotten the exposure/revenue they wanted ? As long as the code served is device agnostic, you can serve it out from one or more domains of any choosing... Cheers J On Monday 21 July 2008 19:14:14 Keryx Web wrote: > Ted Drake skrev: > > Slightly off topic... > > There is a really good Wordpress template/plugin that detects the very > > specific user-agent for iphone and touch and changes your theme to an > > iphone specific layout. > > There is a plethora of such solutions covering most major > PHP-frameworks, RoR, etc. That is the really scaring part! However, I > suspected that most people on this list would stay away from that > solution. I thought that on this list that would be well understood by now. > > Then I saw that even so called standrads aware developers started to use > "iphone" as part of the URL instead, which IMO is perheps less evil. But > only by a few degrees. > > > Sure, it's arguable if you should design for a particular appliance. > > However, they've done the work for you and it works great, although a bit > > generic in look and feel. You can always make adjustments to the theme > > for personalization. > > No it is not "arguable". Within the web standards aware community this > argument has been settled! > > Come on people. Can't you see that this is *EXACTLY* the arguments ´that > were used in 1998 when people forked their code for MSIE and Netscape? > It "worked". It really did. In the short term. > > Developing with the iPhone in mind (not "for" the iPhone) really should > mean nothing else than what it means to develop with e.g. Firefox 3.0 or > Opera 9.5 in mind. You can take advantage of the advanced features, if > you use them as progressive enhancement and capability test for them. > > The only hard question is how you deal with what's *lacking* in the > iPhone: A cursor and a pointer! > > Ohh, it's from Apple, it's shiny, it has no buttons - what is 10 years > of hard fought struggle for web standards worth in that perspective? > Zilch. It seems. > > > Lars Gunther > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: [EMAIL PROTECTED] > *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Mobile graded browser support
FYI: David Storey is one of the lead engineers of Opera Browser. It's a rare honor to have a browser architect reflect on the industry in mailing lists. Do you see similar responses from Firefox, Safari, or IE architects? So, keep his suggestions in mind, he knows what he's talking about. I just wanted to make sure people realized the relevance of his comments. You may want to go back and restore any of his messages that were deleted and save them for future use. Ted *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mobile graded browser support
On 21 Jul 2008, at 14:52, Keryx Web wrote: All right. I will stop complaining about "designing for the iPhone" and try to attack this from a positive angle. How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had. Borrowing the terminology from Yahoo: It is hard to say. I'd ask, do you really want to make a mobile version in the first place? Same issues hold true about making a specific mobile version as does with making a specific print or accessibility version. In many cases giving the regular desktop version is as good or better, plus any optimisations done for mobiles can also benefit those with disabilities as there is a lot of synergies between making a site accessible and making it mobile friendly. We at Opera also experience a huge flood of bug reports every time a site blocks our mobile version from accessing the regular version of a popular site and give it a reduced version. Our experience is most users want the regular version and don't like reduced mobile versions. Your milage will vary on a case by case basis however. You can also use media queries and/or handheld media to optimise styling for mobiles (you can give a different style to menus to avoid the issue browsers like Mobile Safari has with not supporting :hover for example) . If the best option turns out that you want a mobile site, and can cope with the overhead in maintaining two web sites, then a) always make sure you give the user a way to access the regular version if they do so choose to (and not hidden away where it can't be found), and b) don't remove too many useful features. There is a W3C document on Mobile Web Best Practices, from the Working Group that I've just become a member of. The URL is http://www.w3.org/TR/mobile-bp/ and the mobileOK checker is at http://validator.w3.org/mobile/ These seem to be restricted to mobile specific sites and to the baseline of support, as they recommend XHTML Basic and using no JavaScript, which almost excludes regular web pages that have been made mobile friendly, and high end mobile browsers such as Opera Mobile, Opera Mini and WebKit based browsers can cope with more than what is recommended. - What is the current baseline of A-grade browser capabilities? More or less the same as desktop browsers. Transcoded browsers will have some issues with JavaScript that requires user interaction as they are compiled on the server, but can cope well with regular DOM scripting. - What browsers should receive A-grade support? Difficult as there are so many mobile browsers, and depends what market you want to target. It is easy to say to exclude any browser that can only cope with WAP (WML). W3C MWBP recommends XHTML Basic 1.1, so I would think that should be a base-line at the very least. It should probably be higher in my opinion though. There is also the case of which browsers are the most popular as you don't want to cut off the most potential visitors to your site (one of the reasons why IE6 is still A grade). This link http://theregoesdave.com/2008/07/18/iphone-users-only-a-small-percentage-of-overall-mobile-we/ shows the most popular OS on the mobile web (hint: not iPhone), from that studies point of view (always take stats with a pinch of salt, they never even agree with each other), but doesn't show which browsers are being used. From the information we know, Opera Mini is very popular in the US with Palm and RIM Blackberry users (the default browsers are not exactly standards compliant modern browsers). - How do we on purpose disable CSS and/or JS for our C-grade browsers? Many of the basic browsers will not render the CSS (or do it very badly) and wont process the javascript, so as long as you use progressive enhancement and semantic well structured XHTML then that may be enough, but there needs to be more studies on what all of these browsers support. You can, if building mobile specific versions, apply the Mobile Web Best Practices, and progressively enhance for better browsers such as Opera and WebKit. I'd recommend not using browser sniffing at all possible as that is not scaleable and often breaks. For CSS you could add CSS with media queries (modern browsers support media queries), so the low end browsers will not be able to read the CSS- and you can even check for larger screens and give different styling for those screens.For JavaScript you can just use Object Detection. - Should we perhaps have A-grade (Safari, Opera, Fennec and ?) and B- grade (MSIE Mobile, Netfront, Blackberry, Dillo, Obigo???) - And perhaps A- (for devices without a pointer and cursor)? Oh, and while we are at it, check this out: http://www.w3.org/WAI/mobile/experiences-new Lars Gunther
RE: [WSG] Mobile graded browser support
SUGGESTION IS TO FOCUS ON WEB BEST PRACTICES AT ALL TIMES: Referring to Andrew Maben's question/comments, namely: "How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had." -- I suggest adherence to Web Best Practices regardless of the device(s) used, screen sizes, features (or lack thereof), and so on as the dominating consideration to be kept in mind at all times when designing Web sites/pages. PROOF BY EXAMPLE: I know that this approach works as I have implemented Scsi's Web Best Practices throughout the two URL addresses listed below. Check them out for yourself, and please note that the tenth Web Best Practices is "Every (Mobile) Web Page Validates " Good luck! Raymond Sonoff, President Sonoff Consulting Services, Inc. 271 Saxony Drive Crestview Hills, KY 41017 Bus. Tel. No.: 859.261.5908 Scsi P&KT Web site URL: http://sonoffconsulting.com/ Gen'l e-mail: [EMAIL PROTECTED] Corp. e-mail [EMAIL PROTECTED] Scsi P&KT Mobile Web Site URL: http://sonoffconsulting.mobi/ _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Maben Sent: Monday, July 21, 2008 9:37 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Mobile graded browser support On Jul 21, 2008, at 8:52 AM, Keryx Web wrote: All right. I will stop complaining about "designing for the iPhone" and try to attack this from a positive angle. I think "designing for the iPhone" is somewhat irrelevant, (but I'd agree that iphone specific URLs are a scary throwback to the bad not-so-old days). I have found that any thoughtfully designed - standards-compliant, usable/accessible - site works just fine in the iphone. How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had. A much more productive line of enquiry... Andrew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mobile graded browser support
On Jul 21, 2008, at 8:52 AM, Keryx Web wrote: All right. I will stop complaining about "designing for the iPhone" and try to attack this from a positive angle. I think "designing for the iPhone" is somewhat irrelevant, (but I'd agree that iphone specific URLs are a scary throwback to the bad not- so-old days). I have found that any thoughtfully designed - standards- compliant, usable/accessible - site works just fine in the iphone. How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had. A much more productive line of enquiry... Andrew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] iphone should not be part of your url
On 21 Jul 2008, at 01:24, Rimantas Liubertas wrote: let's not forget that the iPhone's browser is (as of right now) the largest mobile browser, Not true. Opera Mini has more active users per week than iPhones that exist on the market. http://blogs.computerworld.com/iphone_users_search_google_5000 : "The Financial Times talked to Google at the Mobile World Congress in Barcelona and found some interesting figures. iPhone users do an average of 50 times more Google searches than their nearest competitor." not wanting to turn this into a popularity contest (this is about writing device and browser specific sites vs writing for the open web), don't believe all the statistics you read. Google may say that, but there is one major flaw. Opera Mini, didn't, at that time of writing, use Google is its search engine. We had a deal with Yahoo at that time. Obviously a device with Google is its default search engine would give them far more traffic. Today we use Google, except for our most popular markets (Former soviet states), where we use Yandex. You'll find Opera Mini is hugely popular on Yandex. I've a company wide NDA with Google, so can't say anything about how any stats may have changed since we changed to Google as the default search engine in Opera Mini and Mobile. Many stats are also heavily US centric. http://localmobilesearch.net/?p=513 : Roughly 85% of iPhone users access news and information and 59% search on their devices. That compares with 13% and 6% in the broader market. <...> Again not true. Take the HTC Touch Diamond. It has both a superior screen resolution, and similar hardware specs, and a full HTML browser (Opera Mobile 9.5) with arguably greater standards compliance. Cannot tell about the mobile versions, but from what I see going on with Webkit it is ahead of all other engines. In what ways? I represent web developers in our roadmap discussions on what goes into our Core rendering engine. As far as I can see Core-2.1 is on par or above other rendering engines in many areas, from DOM 3, HTML5, CSS3, SVG etc. We lack some of the more eye candy aspects of CSS3 (such as border-radius and multiple background images), which is something I'd like to remedy in future versions, but are ahead in other areas of CSS3 (Full selectors support, dynamic media queries, generated content on any element, SVG as background- image etc.) They do also have some experimental none standard stuff that they invented (that it is perfectly possible to do with SVG in Opera) that we don't have as they invented it, and Opera generally makes experimental builds for these types of new features, instead of putting them into a full release build (vendor specific features harm the open web). I'm not sure if mobile safari has these things included however. If there is anything you see that Opera is lacking that is useful for web developers then do let me know. I'll do my best to analyse it and see if it can be added to the road map. And unlike Mini it has a full JavaScript implementation. And let's see what's going on with JavaScript on iPhone: http://daringfireball.net/2008/07/webkit_performance_iphone I'm not sure what that proves. iPhone wasn't tested against any other browser. Mobile Safari can't ever be tested fairly for performance against other browsers as there are no other browsers on iPhone. I think it may be against the agreement to make iPhone apps that anything with a JavaScript engine can't be made for iPhone without breaking the terms of agreement. We do have videos of Opera Mini on a low end phone destroying the iPhone in performance (the original). This is unfair of course as Opera Mini compresses the page to get a big performance boost. Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** David Storey Chief Web Opener, Product Manager Opera Dragonfly, Consumer Product Manager Opera Core, Mobile Web Best Practices Working Group member Consumer Product Management & Developer Relations Opera Software ASA Oslo, Norway Mobile: +47 94 22 02 32 E-Mail: [EMAIL PROTECTED] Blog: http://my.opera.com/dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Mobile graded browser support
All right. I will stop complaining about "designing for the iPhone" and try to attack this from a positive angle. How can we go about making our mobile websites according to sound principles. Bearing in mind that mobile browsers often lack the features we wish they had. Borrowing the terminology from Yahoo: - What is the current baseline of A-grade browser capabilities? - What browsers should receive A-grade support? - How do we on purpose disable CSS and/or JS for our C-grade browsers? - Should we perhaps have A-grade (Safari, Opera, Fennec and ?) and B-grade (MSIE Mobile, Netfront, Blackberry, Dillo, Obigo???) - And perhaps A- (for devices without a pointer and cursor)? Oh, and while we are at it, check this out: http://www.w3.org/WAI/mobile/experiences-new Lars Gunther *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] iphone should not be part of your url
Ted Drake skrev: Slightly off topic... There is a really good Wordpress template/plugin that detects the very specific user-agent for iphone and touch and changes your theme to an iphone specific layout. There is a plethora of such solutions covering most major PHP-frameworks, RoR, etc. That is the really scaring part! However, I suspected that most people on this list would stay away from that solution. I thought that on this list that would be well understood by now. Then I saw that even so called standrads aware developers started to use "iphone" as part of the URL instead, which IMO is perheps less evil. But only by a few degrees. Sure, it's arguable if you should design for a particular appliance. However, they've done the work for you and it works great, although a bit generic in look and feel. You can always make adjustments to the theme for personalization. No it is not "arguable". Within the web standards aware community this argument has been settled! Come on people. Can't you see that this is *EXACTLY* the arguments ´that were used in 1998 when people forked their code for MSIE and Netscape? It "worked". It really did. In the short term. Developing with the iPhone in mind (not "for" the iPhone) really should mean nothing else than what it means to develop with e.g. Firefox 3.0 or Opera 9.5 in mind. You can take advantage of the advanced features, if you use them as progressive enhancement and capability test for them. The only hard question is how you deal with what's *lacking* in the iPhone: A cursor and a pointer! Ohh, it's from Apple, it's shiny, it has no buttons - what is 10 years of hard fought struggle for web standards worth in that perspective? Zilch. It seems. Lars Gunther *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] iphone should not be part of your url
Slightly off topic... There is a really good Wordpress template/plugin that detects the very specific user-agent for iphone and touch and changes your theme to an iphone specific layout. Sure, it's arguable if you should design for a particular appliance. However, they've done the work for you and it works great, although a bit generic in look and feel. You can always make adjustments to the theme for personalization. Ted www.last-child.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keryx Web Sent: Sunday, July 20, 2008 2:44 AM To: wsg@webstandardsgroup.org Subject: [WSG] iphone should not be part of your url I am feeling moody today, but... Are we selling our soul for a shiny newish toy from Apple? A specific app or device should not be part of an URL. Period. URL's like iphone.domain.com are an abomination! Even if the content is standards based. Lars Gunther *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
