Re: [WSG] Time element question
Hi Tom, (Different forum, still me ;-) ) My understanding is that yes you can (put anything you like in the text). It's the @datetime data that is restricted to a machine-readable format. If, however, you don't give the @datetime value then the content of the element itself must be a valid date. So this is OK: now and this is OK 2012-05-22 HTH Phil. On 22/05/2012 19:43, Tom Livingston wrote: Hello list, i wasn't able to find an answer on google specifically for what my question is, so here goes: when using the time element, can you put ANY text within the open and close tags? Like: 02.03.12 - Asia Pacific Is the addition of " - Asia Pacific" ok to do here? Wasn't sure if *any* text was ok to be inside the time tags. I found a lot of info on the datetime attribute, but not if the above type of thing is allowed or not. Thanks -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Mobile sites
I think it's worth noting that there is a lot of commonality between accessibility and mobile optimisation. When the W3C Mobile Web Best Practices Group began its work (way back in June 2005 - I'm feeling old) our starting point was WCAG. They're not the same, of course, but the ways of thinking do share a lot. Designing accessible sites means making very few, if any, assumptions that given features will be available to all your users and therefore coding to offer various fallbacks/alternatives. On mobile, you're targeting devices that *may* be restricted in their capabilities. Others have advocated looking at logs to see which devices your users are accessing the site with. That's always an important data point of course, but beware: if the only mobile devices accessing your site are top end smartphones that could be telling you that those are the only mobile devices that *can* use your site, not that others (the majority) are not interested in what you have to offer. I agree the RWD gets you a long way - we advocate and teach it on the W3C Mobile Web course that Frances de Waal and I run - but it only answers style adaptation. A properly mobile-friendly site is likely to offer (slightly) different content too. At a simple level this means different sized images but it's deeper than that. Mobile users will often have different priorities than those browsing on a desktop and that can affect what you present as well as how you present it. My mantra is content adaptation should be done server side, style adaptation is done client side. Do it right and you almost certainly do not need a separate mobile site. More ramblings at http://philarcher.org/diary/2011/mobilecontentandstyle/ HTH Phil. -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 On 16/05/2012 03:43, grant_malcolm_bai...@westnet.com.au wrote: Hello, I was wondering whether having a dedicated mobile site represents an improvement with regard to accessibility and standards, or whether it is acceptable to have a single site that is adaptable to different screen widths (e.g. by means of CSS media queries). Of course, setting up a separate mobile site requires additional work and therefore expense. I would be grateful for comments. Thank you and regards, Grant Bailey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] w3c mobile validator and html5?
The mind is willing, Rick. It's finding the time that's the problem as ever but yes, I'd be happy to try and create something that could be downloaded and used directly. Cheers Phil. On 15/01/2012 20:55, Rick Lecoat wrote: On 12 Dec 2011, at 21:18, Phil Archer wrote: Hi Nancy, On 12/12/2011 20:25, Nancy Johnson wrote: I have been moving image sizing to the style sheet and not left inline.. NNo!!! That's one thing that the mobile checker is definitely good for - stopping this bad practice of using CSS to define the size of an image and, even worse, using CSS to resize the image. W3C Best Practice: http://www.w3.org/TR/mobile-bp/#IMAGES_SPECIFY_SIZE My take on it: http://philarcher.org/diary/2011/phpimageadaptation/ That’s a great article Phil, so thanks for sharing. As somebody who is completely unversed in PHP, however, I was having a hard time figuring out how all the pieces fit together. Do they end up as one PHP file? or as a collection of PHP files that call each other? And how does the connect with the HTML markup? Any chance that you can you expand upon your explanation for PHP no-nothings like me? The article is fantastic on detail, but I think I need help forming an overview. Thanks, and warmest regards; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Expected behaviour of links to external websites
As a matter of policy, all links on w3.org open in the same window. The reasons for this are, as some have already alluded to: - the user remains in control and can choose to open in a new tab/window or not; - mobile devices, even where they support multiple windows, don't display the tabs at the top (as there's so little space), so keeping track of what is in which window is just not as easy on mobile as it is on desktop; but the *main* reason is - accessibility. Navigating across multiple windows means you have to maintain a mental map of what is open in which tab. This is more difficult for a variety of disabled users. Actually, this highlights the relationship between mobile and accessibility. One window only AFAIAC. HTH Phil On 20/12/2011 05:57, Mathew Robertson wrote: Of course that will break everyone with a device that limits the number of browser instances, as your device will probably expunge instances that haven't been used recently - which is rather a pity as I like to keep instances open so that I can go back to them. If I really wanted to expunge an old instance, I can do so if I choose. The point of hyperlinking is that linking from one context to the next, is seamless; opening up another window isn't seamless. And since the web is stateless, there is no reason to think that staying on a given domain/path is more special than jumping to some other random path -> the modern example of this is twitter. cheers, Mathew Robertson On 20 December 2011 15:42, Grant Bailey wrote: Alex, If the link is to an external site then personally, I prefer the link to open in a new window automatically. Also, not all devices make it easy for users to open a link in a new window on request. Regards, Grant Bailey On 20/12/2011 1:09 PM, Alex Mironov wrote: Hi I have been doing some research on expected behaviour of clicking on links from within a website to other external websites. Much of my research suggests that the recommended practice is to keep people within the same window/tab except in some instances. This gives users maximum control as they have the choice to left click on the link and open in a new tab/window. I have included a few links: http://uxdesign.**smashingmagazine.com/2008/07/** 01/should-links-open-in-new-**windows/<http://uxdesign.smashingmagazine.com/2008/07/01/should-links-open-in-new-windows/> http://www.useit.com/alertbox/**9605.html<http://www.useit.com/alertbox/9605.html> I was wondering if anyone had any views/resources as to whether users should remain in the same window or should be taken to a new window/tab when they click on an external link? Regards Alex Mironov *** List Guidelines: http://webstandardsgroup.org/**mail/guidelines.cfm<http://webstandardsgroup.org/mail/guidelines.cfm> Unsubscribe: http://webstandardsgroup.org/**join/unsubscribe.cfm<http://webstandardsgroup.org/join/unsubscribe.cfm> Help: memberhelp@webstandardsgroup.**org *** *** List Guidelines: http://webstandardsgroup.org/**mail/guidelines.cfm<http://webstandardsgroup.org/mail/guidelines.cfm> Unsubscribe: http://webstandardsgroup.org/**join/unsubscribe.cfm<http://webstandardsgroup.org/join/unsubscribe.cfm> Help: memberhelp@webstandardsgroup.**org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] w3c mobile validator and html5?
Hi Nancy, On 12/12/2011 20:25, Nancy Johnson wrote: Thanks, I love the more graphical layout and organization putting critical issues on top. Yes, that's a good feature. There's a half-made plan to use the same design for the main validator but it's a big job. [..] I have been moving image sizing to the style sheet and not left inline.. NNo!!! That's one thing that the mobile checker is definitely good for - stopping this bad practice of using CSS to define the size of an image and, even worse, using CSS to resize the image. W3C Best Practice: http://www.w3.org/TR/mobile-bp/#IMAGES_SPECIFY_SIZE My take on it: http://philarcher.org/diary/2011/phpimageadaptation/ HTH Phil. On Mon, Dec 12, 2011 at 1:19 PM, Phil Archer wrote: On 12/12/2011 17:28, Patrick H. Lauke wrote: On 12/12/2011 17:18, Nancy Johnson wrote: I noticed this validator only checks for xhtml 1.1 basic or mp1.2. Is it going to checking again html5? http://validator.w3.org/mobile/ Not to my knowledge, no. You could argue that it's aimed at older generations of phones/browsers. We (W3C) have been discussing this issue. The mobile checker is an implementation of the mobileOK Basic Tests [1] which is the machine testable subset of the Mobile Web Best Practices [2]. As long as that is true we have: - a checker rooted firmly in a specification - which is a good thing; - a checker that is growing old and, as is obvious, increasingly out of date - which is a bad thing. If we were to update the checker to, for example, cover HTML5 or any other technology (CSS3, SVG or whatever) then how would we root that in a spec? It becomes a dynamic system without a reference point. Now - since a lot of work went in to the checker (and the specs behind it) and it's a potentially useful tool, we don't want to lose it. However, we would need some sort of community effort to determine what the checker would check. There's also an issue of cost - maintaining the validation suite means writing new code. For now, I think we can say that the mobileOK checker is a useful guide. A lot of the best practices are still entirely valid. Taken with the Mobile Web Applications Best Practices [3] they form good advice to any mobile developer. However, it does need some interpretation - which is a pity. For example, the checker will warn you if you don't use the application/xhtml+xml MIME type. If you're coding in HTML5 that's simply wrong and I haven't seen an instance where there's an advantage in using the XHTML MIME type. The checker will scream at you if you don't include cache control or image dimensions - those are very much right! What about media queries... Is the mobile checker suitable for if you are creating one set of htmls code and for mulitple devices? No. I'd say not yet. What we need is the mechanism for how to manage change and how to effect change in the checker. Keep nagging us - that might help us get it higher on the agenda. HTH Phil. [1] http://www.w3.org/TR/mobileOK-basic10-tests/ [2] http://www.w3.org/TR/mobile-bp/ [3] http://www.w3.org/TR/mwabp/ -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] w3c mobile validator and html5?
On 12/12/2011 17:28, Patrick H. Lauke wrote: On 12/12/2011 17:18, Nancy Johnson wrote: I noticed this validator only checks for xhtml 1.1 basic or mp1.2. Is it going to checking again html5? http://validator.w3.org/mobile/ Not to my knowledge, no. You could argue that it's aimed at older generations of phones/browsers. We (W3C) have been discussing this issue. The mobile checker is an implementation of the mobileOK Basic Tests [1] which is the machine testable subset of the Mobile Web Best Practices [2]. As long as that is true we have: - a checker rooted firmly in a specification - which is a good thing; - a checker that is growing old and, as is obvious, increasingly out of date - which is a bad thing. If we were to update the checker to, for example, cover HTML5 or any other technology (CSS3, SVG or whatever) then how would we root that in a spec? It becomes a dynamic system without a reference point. Now - since a lot of work went in to the checker (and the specs behind it) and it's a potentially useful tool, we don't want to lose it. However, we would need some sort of community effort to determine what the checker would check. There's also an issue of cost - maintaining the validation suite means writing new code. For now, I think we can say that the mobileOK checker is a useful guide. A lot of the best practices are still entirely valid. Taken with the Mobile Web Applications Best Practices [3] they form good advice to any mobile developer. However, it does need some interpretation - which is a pity. For example, the checker will warn you if you don't use the application/xhtml+xml MIME type. If you're coding in HTML5 that's simply wrong and I haven't seen an instance where there's an advantage in using the XHTML MIME type. The checker will scream at you if you don't include cache control or image dimensions - those are very much right! What about media queries... Is the mobile checker suitable for if you are creating one set of htmls code and for mulitple devices? No. I'd say not yet. What we need is the mechanism for how to manage change and how to effect change in the checker. Keep nagging us - that might help us get it higher on the agenda. HTH Phil. [1] http://www.w3.org/TR/mobileOK-basic10-tests/ [2] http://www.w3.org/TR/mobile-bp/ [3] http://www.w3.org/TR/mwabp/ -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Breaks within table cells
So you're just trying to create a blank line between Client / solicitor and Client / accountant ? Two ways to do that I'd say: use two elements (i.e. Client / solicitorClient / accountant or two paragraphs: Client / solicitor Client / accountant The latter creates two block level elements that you can style with extra padding or whatever. HTH Phil. On 23/11/2011 11:25, Grant Bailey wrote: Hello, I would be grateful if someone could help with this, as I'm not a tables expert. I want to separate two separate entries in the one cell, to indicate alterntatives. Like this (see picture): The coding for this part of the table looks like this: Client / solicitorClient / accountant Bad advice Economic loss Unfortunately, I have not been able to style the left-most cell so that it looks like the picture attached. I tried to style the using the line-height property but this only worked in Google Chrome. If anyone could offer hints I would be grateful. Thank you and kind regards, Grant Bailey (attachment) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] nav element
Hi Frances, I think you might be missing some of the semantics. I might include a list in a page, such as a list of references, or a friend list where each friend was linked to their public profile - but those aren't navigation links. The element tells search engines etc. what this list of links is for. Dunno if that makes sense, Phil. On 22/11/2011 14:32, Frances de Waal wrote: Hi, Working with the semantical HTML5 elements I keep feeling aversion to the extra elements I am producing. Like the nav element, using it as a container for a menu in an list does not feel as an advantage, I never needed a container for the list before. I trained myself in keeping the code as clean and small as possible and now I am simply creating more elements. How about a nav element containing just links? I can think of answer myself like that a nav element may also contain a header, or contain paragraph with links inside the text. So this could lead to the conclusion that (with keeping in mind to never use an element unless you need it) that I should only use the nav element in such cases, and that a nav element around a simple list is not adding anything to it but creating more code. Anyone having any thoughts on this? Bye, Frances www.waalweb.nl www.smartscripts.nl Zelfstudiehandboek Websites Ontwikkelen met HTML, CSS en Dreamweaver WaalWeb | Halfweg, Noord-Holland | KvK 34350833 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] ems versus pixels
I must offer a contrary view to Edward! Any page that requires a user with normal vision to have to zoom on any device is, in my view, a sign of a really badly designed page on a really smart device. Pixels can be regarded as a proportional measure since pixel density varies between screens. Ems are proportional to the size of text you're using - and that's generally the thing you want to be proportional to. For me, line thickness can justifiably given in pixels (and that's mainly because 'thin' means 1px in the standards browsers and a different measure, 2px, in you-know-which browser). Image sizes should always be specified in the markup, so that's in pixel sizes too. Apart from that, it's ems all the way for me. Phil. Edward Lynn wrote: Modern browsers now implement page zoom, and so using ems for me is becoming unnecessary. I get much better x-browser control with px's and so that is the direction im moving in Ed On Tue, Jul 20, 2010 at 2:53 PM, wrote: Hi, I've been converting some of our company public-facing static web-sites from pixels to ems for layout and font-size. But just recently I encountered several references that pixels are getting back into popularity - "as it offers absolute control over text", and that most browsers now can resize font based on pixels. Any thoughts/suggestions on whether I should push the effort on converting our sites to ems? Anya Gerasimchuk *** This message may contain confidential information intended only for the use of the addressee(s) named above and may contain information that is legally privileged. If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message immediately thereafter. Thank you. *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] that old IE6 thing...
Dan, I agree that libraries have played a special part in the evolution of many standards directly or indirectly related to the Web. But, there's always more to do. You and others might want to check out a new W3C Incubator Group in this area http://www.w3.org/2005/Incubator/lld/ Incubators don't produce standards, they report on what standards work needs to be done. At least please join the public mailing list! Cheers Phil. -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org Dan Webb wrote: Andrew wrote: (and perhaps that librarians are a bit slow to upgrade ;) And then tee wrote: I think it's more to do with the fact that librarians are always getting hand-me-down hardware :) That is indeed often the case. And it's not only that. If given a choice of buying 3 or 4 new books for the researchers and clinicians, or buying library staff a shiny new computer when the one they have can clunk along just fine for another year ... well, it's a simple choice. Budgetry constraints hit libraries hard. And while I'm here, I'll point out that librarians happen to be quite early adopters of new technologies and web trends, and have been since the days of ARPANET. Libraries have been quick to embrace all kinds of services (Facebook, Twitter, SMS) to push information out to and connect with their patrons. It's thanks to advice from librarians that, from the time I put my hand up and told my boss "yea, I can make you a website", and then wonderened how the heck to do it, I headed down the Web Standards path. They're generelly pretty technologically aware, and do the best with what they have. dan. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Mobile Page Passes but MIME Type Fails
The Doctype for XHTML Basic 1.1 is: http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd";> HTH Phil. Kevin Erickson wrote: Question: For the line, "http://www.wapforum.org/DTD/xhtml-mobile10.dtd";>, would I change this to, "http://www.wapforum.org/DTD/xhtml-mobile10.dtd";>, ?? And change, , to, charset=utf-8" />, ?? I have not been able to find the answers on the web. Thanks. Kevin -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Phil Archer Sent: Tuesday, June 15, 2010 6:15 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Mobile Page Passes but MIME Type Fails Hi Kevin, The answer is in your e-mail. You have created a page using a version of XHTML for which the correct MIME type is application/vnd.wap.xhtml+xml or application/xhtml+xml but you're sending text/html so there is a mismatch, hence the warning. The recommended markup for mobile is now XHTML Basic 1.1 for which the appropriate MIME type is application/xhtml+xml but if you're sending to a device that doesn't support that (essentially just IE) then you'll need to do as you are doing and use text/html. However... this is a warning, not a failure, so you may decide just to leave things as they are ;-) Presumably you got this warning from the mobi Ready tool? This uses the same core code as the W3C mobileOK checker http://validator.w3.org/mobile/ (although we've added a lot of extra UI stuff over the last year or so). HTH Phil. Kevin Erickson wrote: Hello All, If anyone can help me understand why my mobile page passes all accept the MIME type. Page code: http://www.wapforum.org/DTD/xhtml-mobile10.dtd";> http://www.w3.org/1999/xhtml";> Virginia.gov Mobile - Home /> you to access key services from Virginia state government on your mobile device, such as news, alerts, weather, and contact information." /> @import url(../../css/m_index.css); Switch to Expanded Mobile Pages Home Mobile Virginia.gov Services: Home Search Virginia.gov People: Citizens Families State Employees Students Information: href="info_government.html">Government Online Services Business href="info_employment.html">Employment Education Tourism and Travel About Virginia: Facts and History Mapping Virginia mobile.virginia.gov http://www.virginia.gov";>Virginia.gov Home href="http://www.virginia.gov/cmsportal3/about_virginia.gov_4096/web_policy. html">Site Policies href="http://www.virginia.gov/cmsportal3/about_virginia.gov_4096/contact_us. html">Contact Virginia.gov To test the page I used http://ready.mobi/launch.jsp?locale=en_EN and the error says: Incorrect or missing MIME types were detected The MIME types sent by servers give very important information to browsers as to how to treat a document. If incorrect MIME types are sent with a document, it may prevent the browser from correctly interpreting the document and failing to render a document. For XHTML-MP, the recommended MIME type is application/vnd.wap.xhtml+xml or application/xhtml+xml. Unlike HTML, XHTML-MP should not be served as text/html. Web servers are often set up correctly for common document types such as HTML and CSS, but often do not have the correct doc types for XHTML-MP. Please refer to mobiForge <http://mobiforge.com> for instructions on how to set up your MIME types correctly. WARN MIME type was detected as text/html I would send a link to the page but it is on a secure server. Thank you very much for any help on this, Kevin *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Mobile Page Passes but MIME Type Fails
Hi Kevin, The answer is in your e-mail. You have created a page using a version of XHTML for which the correct MIME type is application/vnd.wap.xhtml+xml or application/xhtml+xml but you're sending text/html so there is a mismatch, hence the warning. The recommended markup for mobile is now XHTML Basic 1.1 for which the appropriate MIME type is application/xhtml+xml but if you're sending to a device that doesn't support that (essentially just IE) then you'll need to do as you are doing and use text/html. However... this is a warning, not a failure, so you may decide just to leave things as they are ;-) Presumably you got this warning from the mobi Ready tool? This uses the same core code as the W3C mobileOK checker http://validator.w3.org/mobile/ (although we've added a lot of extra UI stuff over the last year or so). HTH Phil. Kevin Erickson wrote: Hello All, If anyone can help me understand why my mobile page passes all accept the MIME type. Page code: http://www.wapforum.org/DTD/xhtml-mobile10.dtd";> http://www.w3.org/1999/xhtml";> Virginia.gov Mobile - Home @import url(../../css/m_index.css); Switch to Expanded Mobile Pages Home Mobile Virginia.gov Services: Home Search Virginia.gov People: Citizens Families State Employees Students Information: Government Online Services Business Employment Education Tourism and Travel About Virginia: Facts and History Mapping Virginia mobile.virginia.gov http://www.virginia.gov";>Virginia.gov Home http://www.virginia.gov/cmsportal3/about_virginia.gov_4096/web_policy. html">Site Policies http://www.virginia.gov/cmsportal3/about_virginia.gov_4096/contact_us. html">Contact Virginia.gov To test the page I used http://ready.mobi/launch.jsp?locale=en_EN and the error says: Incorrect or missing MIME types were detected The MIME types sent by servers give very important information to browsers as to how to treat a document. If incorrect MIME types are sent with a document, it may prevent the browser from correctly interpreting the document and failing to render a document. For XHTML-MP, the recommended MIME type is application/vnd.wap.xhtml+xml or application/xhtml+xml. Unlike HTML, XHTML-MP should not be served as text/html. Web servers are often set up correctly for common document types such as HTML and CSS, but often do not have the correct doc types for XHTML-MP. Please refer to mobiForge <http://mobiforge.com> for instructions on how to set up your MIME types correctly. WARN MIME type was detected as text/html I would send a link to the page but it is on a secure server. Thank you very much for any help on this, Kevin *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE6 Finally Nearing Extinction [STATS]
Again, interesting, stuff, Dave. Concerning your remark: > If I was Microsoft I'd be quite worried that the IT support pros, > influencers and developers have such a different make-up than the > mainstream. I believe they are indeed concerned about this. AIUI they're a little fed up with the constant remarks on fora like this where we're broadly able to talk about "the standards browsers" and mean "every browser except IE for which, everyone knows you need to put in workarounds." IE9 is going to take a big step towards changing that with support for SVG, XHTML and more. As for when IT departments get around to changing over to it, who can say? Any bets for it being done in time to watch the 2018 World Cup on an HTML 5 video feed? Phil. Dave Lane wrote: For what it's worth, some of our non-techie sites (with much smaller user numbers, as they're focused on the relatively tiny New Zealand market) are showing a slightly rosier picture over the past month: Advocacy website for cyclists (4544 visits): IE: 41.57% (IE6-15.09% 7-37.96% 8-46.96%) FF: 40.29% CHROME: 9.09% SAFARI: 7.68% OPERA: 0.62% IE6 = 6.27% Sports clothing (28,337 visits): IE: 49.92% (IE6-13.8% 7-27.06% 8-59.11%) FF: 24.87% CHROME: 6.20% SAFARI: 17.82% OPERA: 0.77% IE6 = 6.88% Brewers website (3,300 visits): IE: 45.97% (IE6-10.42% 7-30.72% 8-58.87%) FF: 30.06% CHROME: 11.27% SAFARI: 10.03% OPERA: 1.03% IE6 = 4.79% Tourism operator (4,041 visits): IE: 54.84% (IE6-11.60% 7-28.07% 8-60.24%) FF: 26.73% CHROME: 4.80% SAFARI: 12.77% OPERA: 0.42% IE6 = 6.36% For contrast, here're the stats for a tech company. IT services and software dev company (3,050 visits): IE: 15.02% (IE6-8.52% 7-19.87% 8-71.62%) FF: 56.20% CHROME: 18.52% SAFARI: 5.48% OPERA: 2.82% IE6 = 1.28% If I was Microsoft I'd be quite worried that the IT support pros, influencers and developers have such a different make-up than the mainstream. Cheers, Dave On 12/06/10 00:32, Lea de Groot wrote: On 11/06/10 9:32 PM, Foskett, Mike wrote: I just took a peek at our own stats for May 2010. A very large set limited to UK online shoppers only. And I couldn't agree less with the article. I have a couple of large .au 'mum and dad' sites (ie, not techie) and I have similar results to your .uk figures: Internet Explorer67.11% Firefox17.19% Safari9.70% Chrome4.67% with specific IE figures of IE8.059.08% IE7.028.46% IE6.012.44% ie IE 6 is at 8.3% overall - lower than your numbers, but still worth testing for. Interestingly, I have iphone/ipod numbers at 2.77% and rising fast - I guess I better get those mobile versions up! Lea -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE6 Finally Nearing Extinction [STATS]
Thanks everyone for these interesting stats - depressing as they are. Lucien - I assume it's not a typo when you say your IT department is now rolling out IE7. I'm curious to know the rationale behind that cf. going straight to IE8. If they're doing all the testing to ensure that IE7 is safe from a company point of view, why not go for the current version? What am I missing? Thanks Phil. -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org @philarcher1 nedlud wrote: Our site is a large health care site. Of the ~25 visitors in the last month, Google says the break down by browser is... Internet Explorer 69.44% Firefox 15.98% Safari 9.32% Chrome 4.20% And of the IE traffic, we get... IE 8.0 37.90% IE 7.0 32.87% IE 6.0 29.23% And that is only our external traffic. Our intranet traffic is a different story since IE6 is still our "official" browser, although our IT department has finally started rolling our IE7 as of this week. So for us, IE 6 can't be ignored, as much as we would like to. Lucien. On 11 June 2010 23:17, Duncan Hill wrote: On Fri, 11 Jun 2010 12:32:03 +0100, Foskett, Mike < mike.fosk...@uk.tesco.com> wrote: Hi all, Ref "Links for light reading" article: http://mashable.com/2010/06/01/ie6-below-5-percent/ Which basically states IEv6 has dropped below the 5% threshold across USA and Europe. Nice figures, the stats were produced for May 2010, and calculated for 15 Billion page views. The quoted 4.7% using IE 6 therefore still amounts to around 70 Million page views during May 2010. (that's the entire population of the UK, and then some) . dead? Duncan *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Help with mobile MIME type always fails test
I agree that serving XHTML with the text/html MIME type isn't a cardinal sin. Also, as ever, you need to work around IE which offers a download dialogue when given the (correct) application/xhtml+xml MIME type. The good news is that IE9 /will/ support the XHTML MIME type (as well as SVG and more) so we might yet live in a world where cross-browser issues can be less dominant in developers' minds. When devising the mobileOK tests (as implemented by mobiready and our own mobileOK checker http://validator.w3.org/mobile/) we wanted it to be possible to pass without scripting and/or server config. You'll get warnings, but not a fail condition. HTH Phil. Andrew Harris wrote: Well, well, well, you learn something new every day eh? On Sat, Apr 17, 2010 at 9:47 AM, wrote: Just cancel on the login but load the page into the test site please to see the results. I still couldn't get into a page, but it doesn't matter - I think I see the problem. According to dot-mobi: "For XHTML-MP, the recommended MIME type is application/vnd.wap.xhtml+xml or application/xhtml+xml. Unlike HTML, XHTML-MP should not be served as text/html." Consequently the mobile site I maintain at: http://m.unimelb.edu.au also generates a warning. On the other hand, I get the feeling it's pretty much an 'edge case' as far as failure goes. Serving as text/html isn't going to break many browsers. I suspect only most primitive wap only browsers will fail to load the content. If you look at dot-mobi's little graph, it indicates that such browsers are likely to be on mobiles greater than 5 years old - pretty minor stuff given that, if you're anything like our site, more than 95% of your mobile traffic is going to be from Apple devices. However, there's nothing wrong with being fussy, so getting you server to use the correct MIME type will require you either getting into the apache.conf file or using .htaccess to set the mime type for the file extensions you're using. This can get tricky and will break things if you don't know what you're doing. (I don't!) In my case - using the MySource Matrix CMS, it's just a matter of adding a line to the beginning of my mobile template, if you are running a CMS you may have a similar setting. I'm going to leave that until Monday when I've got time to back out of it if it causes problems :-) -- Phil Archer W3C Open Media Web http://www.w3.org/ http://philarcher.org @philarcher1 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Help with mobile MIME type always fails test
Kevin, That's a password protected page so I can't see it. Not sure what you man by the 'Mobile MIME type'. Can you elaborate please? Phil. Kevin Erickson wrote: Hello all, I am hoping someone can help me with a MIME for mobile sites problem I am having. I have a page, http://devel.virginiainteractive.org/demo/portalredesign2010/mobile/mobile_p ages/, that will not pass the test for mobile MIME type using the http://mobiready.com/launch.jsp mobile site tester. I have tested other big brand mobile sites for government and commercial and none seem to pass this either. Can someone please advise? Thank you very much, Kevin *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C Open Media Web http://www.w3.org/ http://philarcher.org +44 (0)1473 434770 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Use CSS to target last 2 list items
Paul, A quick look at [1] suggests that you might be able to do li:nth-last-child(-n+2) But I haven't tried it... (I didn't know you could target the last element so I was intrigued by your question and that lead me to this. Don't assume that all W3C team folk know what each other is up to!) Phil. [1] http://www.w3.org/TR/css3-selectors/#nth-last-child-pseudo Paul Collins wrote: Hi all Just wondering, is it possible to use the nth-child in CSS2 to target the last 2 items of an unordered list? I know you can do nth-last-child, but I wanted to target the last TWO list items. Is this possible? Thanks for any help *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Phil Archer W3C Open Media Web http://www.w3.org/ http://philarcher.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Ordered list start value
As I understand it, I'm afraid there is no way to do this in XHTML. I've wanted to do the same before now and I don't think you can (whilst remaining valid). If someone does know a technique that works, I'd be interested too. Phil. T. R. Valentine wrote: What is the proper way to start an ordered list at a value other than '1' in XHTML? I had flagged because 'there is no attribute "start"' TIA -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***