Re: [WSG] advice on background images?
On 26 Nov 2010, at 22:32, cat soul wrote: > Any tips on how to minimize or eliminate how obvious it is where the "tiles" > meet when you have the background image repeat? Use a better background-image? I’m not sure what you mean? bg images repeat if you tell it to do. You either have an image designed to repeat or you don' (or you have a vector image via SVG that scales instead). > > > thanks > > cs > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > ******* -- David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] XHTML or HTML?
On 11 Nov 2010, at 00:17, Mathew Robertson wrote: > Here is a reasonably good example: > > http://www.texaswebdevelopers.com/blog/template_permalink.asp?id=136 > > In particular, the 'dir' and 'lang' attributes -> most people just assume > that english is the only language… dir isn’t needed unless you are using rtl or something more exotic. The default is ltr. Also be aware if you are using a HTML5 structural elements like section and so on, while they work in modern browsers by adding “display: block;” and IE by the HTML5 Shim (createElement), they will not work on the BlackBerry browser (Pre-BB6, but that is most BBs on the market). BlackBerry is highly underrated, but by some measures it is the second most popular mobile browser after Opera: http://gs.statcounter.com/#mobile_browser-ww-daily-20091001-20101109 > > regards, > Mathew Robertson > > On 11 November 2010 09:53, Thierry Koblentz > wrote: > > Any thoughts on which we ought to be using, and what information > > ought to be up at top of an HTML page, along with , etc? > > I'd go with with nothing above that > > -- > Regards, > Thierry > www.tjkdesign.com | www.ez-css.org | @thierrykoblentz > > > > > > > *** > 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 > *** -- David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Mobile Phone Emulators
On 3 Oct 2010, at 06:02, Cole Kuryakin wrote: Hello All - I've been tasked with setting up a few form pages to be viewed on mobile phone devices. Currently I'm using Adobe's Device Central - which is okay but it really doesn't show how the forms (particulary select lists) will be shown on various mobile devices. I've also tried the online Opera emulator which seems to work pretty well This emulates Opera Mini. You can get a downloadable Opera Mobile emulator at http://www.opera.com/developer/tools/ . It isn't strictly an emulator. It is the actual browser ported to Windows/Mac/Linux, but it is easier to name it that way. , but what about Nokia, Motorola, Samsung, Apple, etc., etc. I've read on-line that for Nokia and Apple you've really gotta download their SDK in order to accuratly test webpages - true? It comes as part of the SDK package for iPhone at least. An emulator also comes as part of the Palm (It is a copy of the OS that you have to run through a virtual machine like VirtualBox) SDK, and the Android SDK. Would greatly appreciate any advice from those of this group who develop mobile viewable pages (particulary forms) on where to test your efforts for the best compliant and visual result across the largest number of mobile devices possible. Cole *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* -- David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Mini rendering issue with HTML5 doctype
On 5 Sep 2010, at 23:53, tee wrote: Sometimes next week I maybe able to setup a test site with pages that show different doctypes and widths. Just a quick question, shouldn't Opera Mini obeys the rules even when a desktop doctype is used? @media screen and (max-device-width: 480px) Opera Mini doesn't support the viewport Meta element (yet). Opera Mobile does though. It is something Apple invented and isn't standardised (yet). We reverse engineered it for Opera Mobile, but there is some cases where it doesn't work exactly the same due to assumptions and the two step zoom. We are fixing those issues though and trying to standardise Viewport so it is consistent across browsers without having to make assumptions die to lack of a spec. We are looking to standardise it in CSS though, where it belongs (some people on the WG consider it to be like the font tag when used in HTML rather than CSS). For the initial proposal, look at http://people.opera.com/rune/TR/css-viewport/ . I expect we’ll support some form of viewport (be it element or CSS properties) in Opera Mini eventually. I can't say how soon (yet). Without them, I would take what I saw isn't a bug. I am pretty sure it's more a HTML5 doctype issue than desktop doctype because when this site was created, There shouldn't be a difference between a regular desktop doctype and the HTML5 one. It was designed so that it just works in current browsers, rather than browsers doing something special when they detect it. I adapted a base template that uses XHTML 1.0 strict, in the first round mobile browser check I didn't change it to XHTML Basic 1.1, and I didn't see the horizontal scrolling bar (will remember to add it to my test). Since that this browser is intended for mobile devices, your reasoning is sound, but I guess developers won't be accepting it if we specifically tell the browser to follow the above rules. Make me think maybe I should wait till 2022 to start using HTML5! tee Will the media='all' affects how Opera Mini renders Desktop Doctype that it ignores the @media screen and (max-device-width: 480px) rule? Some sort of specificity that media='all' overrules other media types including media queries? No, it shouldn’t. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Mini rendering issue with HTML5 doctype
On 5 Sep 2010, at 13:49, tee wrote: I have a mobile site (just using media queries) that initially used XHTML Basic 1.1, the site rendered fine except with a few glitches (bugs!!??) that I know existed in this browser. Decided to convert the site to HTML5 and all I did was change the HTML5 doctype, it has no validation error, it renders the same in Safari Mini and Andriod, yet in Opera Mini it results a very long horizontal scrolling bar in portrait view, in landscape view it's a bit shorter (about 50px I think). I switched back to XHTML Basic 1.1, the horizontal scrolling bar gone! Without seeing the site it is hard to tell, but it i probably due to the rendering mode. When using a mobile doctype (such as XHTML Basic), the site displays as the author intends (i.e. assumes the site is designed for small screens and the author knows what they are doing). For the HTML5 doctype, it is a regular (you could say desktop) doctype, so Opera Mini/Mobile use the overview rendering mode. This is when the browser has the zoom in/zoom out mode. The viewport becomes the width of the virtual viewport (around 8xx pixels, I forget offhand), so that the full page is laid out/rendered to this virtual width, rather than the device viewport (the width of the device screen). It is probably taking 98% and 100% of this virtual viewport, but I'd have to see and understand the code to know exactly what is going on. Like other mobile browsers, it does this to be able to render sites designed for desktop without breaking the layout. The user can then zoom in to sections to make the content readable. The cause: The #container width is 98% + 1% left/right margin. A plugin that the site used, has a style sheet that has a 100% width in the div.widget. The 100% width from .widget should obey the #container width because it's wrapped inside the #container but it doesn't. There is an even scary bug, I brought the widget class to @media screen and (max- device-width: 480px), if the width stays between 95 to 100% the horizontal scrolling persist, if 94% or less, it disables the entire @media rules, the site shrinks to minimum view just like you see in NYTimes the none-mobile optimized site. However I also used 100% width for a child class (forgot to get rid of it) that causes no issue when I display none the plugin. It appears that the bug is triggered by a combination of javascript - jquery-ui-accordion.min.js (other scripts are fine). If the width is removed in the widget than the bug gone, so the bug is avoidable if one knows it. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Mini
On 23 Aug 2010, at 20:28, tee wrote: Hi David from Opera, Quote you: I'm a member of that WG but honestly it is complete useless and out of date. It was commissioned when 12kb all together was a big deal. From the Mobile Web Best Practices course class I got an impression the mobileOK Checker is an improved version (v1.4.1) but I have no prior experience to compare it. Improved as in improved to test to the requirements to what MobileOK was set out to test when it was commissioned, yes. That was when things like Palm WebOS, Android, iOS etc didn't exist and browsers for low end devices which can handle heavy content like Opera Mini were in their infancy. I am working on a mobile version WordPress site that I have not done content negotiation yet, but display none the content including inline images that I don't want them show up in mobile version. The homepage is a little heavy due to a large image (display none already), both mobileOK Checker and mobiReady test showed the page is over 80K and picked up all inline images. I'd forget .mobi. It is already dead. People like Cameron Moll which were early cheerleaders of .mobi are already not renewing their .mobi domains. I consider that a checker bug if they are counting resources that are not loaded. Of course there are some devices that load them (which are also devices that are commonly pay per kb of content downloaded) so you have to decide if you are targeting your content at those browsers (if there are a significant number of your users using those browsers). If not then you can ignore it. If so then you have to care about it. Is there a way to find out exactly how many kilobyte Opera Mini loaded the page since you said it doesn't load anything sets to display none. for us (Opera) yes, but I'm not sure there is for developers We average 90% compression so you can look at what Opera desktop does and remove 90% (just a guestimate on the avg). You mentioned Dragonfly, I do use this tool when I check site in Opera, but it will not be a tool that can be replaced by FF Web Developer tool for most developers who live and breath by FF and the extension I believe Ok, your choice. I'm PM of DFL so I'll aim to remove that argument by improving our tool, but sure… (the UI is more intuitive and easier to navigate for layout troubleshoot or to find what classes/ID are in a block etc. ), and I do not see Dragonfly for Opera Mini and Opera Mobile. I searched for it few months ago. You don;t need to download DFL for a device. DFL is the first tool that supports remote debugging (WebKit is now coming out with this). Basically you can set it in the desktop browser to remote debug mode (in settings, but we'll make it more obvious soon) then you can go to opera:debug on the device and connect to the desktop Opera DFL. It currently works on Opera Mobile and opera for devices. It can't work on Mini as the client uses some binary content rather than HTML/CSS (as it transcodes). IT may be possible in the future to debug what the Opera Mini sever sees, but as the client isn't HTML, there isn't much point to expose that in any meaningful way. Another thing, Opera Mini does not load the font family (along with many other elements) but the default Sans-serif, however it's able to pick up some CSS3 elements (one that I see is text-shadow). Is this a device restriction preventing Opera Mini from doing this? I have a doubt because iPod (I think iPhone too but I don't have one to check) is capable of loading both default Sans and Sans-serif. Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Getting my feet wet in HTML5
On 19 Aug 2010, at 11:51, Rob Crowther wrote:
Patrick H. Lauke wrote:
On 19/08/2010 10:13, David Storey wrote:
So the section or article elements could be taken out of context
and
displayed elsewhere but retain their headings.
You could, but I still use the h1 to h2 inside the sections
because no
browser uses the sectioning algorithm for thing like styling.
I think Firefox 4.0 will, this will also be the first version of
Firefox to have the HTML5 parser enabled by default. Styling is
especially fun because it's not just sections you have to worry
about, several other elements also create a new sectioning context.
Life will be made easier by the new any() selector:
maybe, but any is not backwards compatible so not really an option to
use any time soon, and is (AFAICT) a Mozilla only extension that is
not in any specification. As it isn't even in any spec, even if it
does get accepted by the CSS working group, it will take ages to be
specced up, refined and included in the other browsers.
This is why I just stick to using the appropriate h* element for the
section level that stick to h1, as it is more backwards compatible and
solves all the head scratching.
/* Level 0 */
h1 {
font-size: 30px;
}
/* Level 1 */
:-moz-any(section, article, aside, nav) h1 {
font-size: 25px;
}
/* Level 2 */
:-moz-any(section, article, aside, nav)
:-moz-any(section, article, aside, nav) h1 {
font-size: 20px;
}
/* Level 3 */
:-moz-any(section, article, aside, nav)
:-moz-any(section, article, aside, nav)
:-moz-any(section, article, aside, nav) h1 {
font-size: 15px;
}
https://developer.mozilla.org/en/CSS/:-moz-any
Also worth pointing out that, to my knowledge, no AT/screen reader
currently supports it either, so this may cause some issues for
these users at present.
Similarly the native semantics of elements like header and nav don't
yet have any impact on screen readers which support the similar ARIA
roles (unless NVDA added support?) so you should add them even when
there's duplication:
http://www.w3.org/TR/html5/content-models.html#annotations-for-assistive-technology-products-aria
Rob
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter:
dstorey
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Getting my feet wet in HTML5
On 18 Aug 2010, at 23:40, Rob Crowther wrote:
On 18/08/10 17:51, tee wrote:
This example doesn't look very semantic to me :-) Is there a tag
that can replace or substitute the use of headings?
If you properly nest your and elements then you
can use just everywhere:
Monday
First post
...
Second post
...
Tuesday
First post...
The weight of each heading is then determined by the outlining
algorithm:
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outlines
So the section or article elements could be taken out of context and
displayed elsewhere but retain their headings.
You could, but I still use the h1 to h2 inside the sections because no
browser uses the sectioning algorithm for thing like styling. So all
the H1s will be the size set by the h1 selector, unless you do
something like:
section h1 { }
section + section h1 { }
section + section + section h1 { }
etc… which is verbose.
Is this what you meant?
There was some discussion about replacing h1-6 with, simply, and
letting the outline algorithm determine the weight, but this was
eventually dropped for backwards compatibility reasons.
Rob
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter:
dstorey
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Yes or No? HTML5 FOR WEB DESIGNERS
On 18 Aug 2010, at 21:17, Prisca schmarsow wrote: Hi ;) as the subject has expanded to HTML5 - use it or not yet - I thought I might throw in a sample site. This is a new site for a webdesign course I run and teach, recently put live, setup in WordPress, and using some HTML5. (I will not teach next year's students HTML5 yet - but will introduce it in the last term, according to the latest spec) I would not say the site is pure HTML5 in the strictest sense just incorporating suitable HTML5 tags in the theme, as appropriate (I hope). It still uses a few standard HTML tags and is a bit of a hybrid, I suppose. I aim to keep working on improving the source and tweak it all as time goes on ~ and/or specs change. For now, I hope it meets with your approval and I would be curious to hear your thoughts - if anyone is interested in having a look: http://webeyedea.info The HTML5 validator throws up 2 errors, 1 for a span and 1 for a paragraph used in the . I did find sources which approve of a being used inside the . So I will leave that as it is for now. Any thoughts and feedback would be most welcome :) hgroup is as far as I can tell a hack to hide a subtitle or such marked up as a heading element (h1–h6) from the sectioning algorithm used to calculate the structure of your document . “The hgroup element is typically used to group a set of one or more h1- h6 elements — to group, for example, a section title and an accompanying subtitle.” Thus I think you only use the hgroup if you are using another heading such as an h2 for your subtitle, otherwise it isn't really needed and you can avoid using the hgroup all together. I could be misinterpreting it though. Prisca __ Prisca Schmarsow — 07969 713 329 graphiceyedea.co.uk --- eyelearn.org --- webeyedea.info student forum: eyelearn.org/forum __ On Wed, Aug 18, 2010 at 7:45 PM, tee wrote: On Aug 18, 2010, at 7:06 AM, jeffrey morin wrote: It's a good starter book to introduce you to HTML5. It's not a reference manual just a good starter book. You still should read the W3C spec and get the other book Introduction to HTML5. I will disagree with Jason Grant that it's too early to start using HTML5. Because HTML5 supports the older tags you can start using it today by simply using that's it and you're site is now considered html5, and if you're site validated for XHTML or HTML prior it should validate for HTML5. Months ago I tried converting a theme to HTML5, but had to give it up for the following reason: Ran into a number of validation errors with obsolete tags which are no longer supported by HTML5. Though they were all fixable but it gave me a second thought perhaps it's not such a good idea to be progressive with newer markup technology for sites that need to go live today, tomorrow, next year and that I have no control, no way to know how the site owners going to use their sites and how many plugins they will be using which have terribly markup in the template files. I can't remember exactly how many errors I encountered except this one that had me a change of heart because I am not certain of the impact on the WCAG 2.0 success criteria and how today's Screen readers handle the HTML5. W3C validator flagged Summary attribute as obsolete. Quote: "The summary attribute is obsolete. Consider describing the structure of complex tables in or in a paragraph and pointing to the paragraph using the aria-describedby attribute." So this is more a validation error than accessibility issue right? TotalValidator doesn't find it wrong. So I assume it's not an accessibility issue, or TotalValidator got it wrong. Last time I checked, browsers are buggy rendering Caption element, not sure if this is still the case but I certainly don't want to go find a hack or invent a hack to make caption element render correctly in all browsers. Aria-described attribute maybe a way to go but I don't know little about it. tee *** 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 *** David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices /
Re: [WSG] Yes or No? HTML5 FOR WEB DESIGNERS
On 18 Aug 2010, at 20:45, tee wrote: On Aug 18, 2010, at 7:06 AM, jeffrey morin wrote: It's a good starter book to introduce you to HTML5. It's not a reference manual just a good starter book. You still should read the W3C spec and get the other book Introduction to HTML5. I will disagree with Jason Grant that it's too early to start using HTML5. Because HTML5 supports the older tags you can start using it today by simply using that's it and you're site is now considered html5, and if you're site validated for XHTML or HTML prior it should validate for HTML5. Months ago I tried converting a theme to HTML5, but had to give it up for the following reason: Ran into a number of validation errors with obsolete tags which are no longer supported by HTML5. Though they were all fixable but it gave me a second thought perhaps it's not such a good idea to be progressive with newer markup technology for sites that need to go live today, tomorrow, next year and that I have no control, no way to know how the site owners going to use their sites and how many plugins they will be using which have terribly markup in the template files. I can't remember exactly how many errors I encountered except this one that had me a change of heart because I am not certain of the impact on the WCAG 2.0 success criteria and how today's Screen readers handle the HTML5. W3C validator flagged Summary attribute as obsolete. Quote: "The summary attribute is obsolete. Consider describing the structure of complex tables in or in a paragraph and pointing to the paragraph using the aria-describedby attribute." So this is more a validation error than accessibility issue right? TotalValidator doesn't find it wrong. So I assume it's not an accessibility issue, or TotalValidator got it wrong. ”The following attributes are allowed but authors are discouraged from using them and instead strongly encouraged to use an alternative solution: […] "The summary attribute on table. The HTML5 draft defines several alternative solutions." Last time I checked, browsers are buggy rendering Caption element, not sure if this is still the case but I certainly don't want to go find a hack or invent a hack to make caption element render correctly in all browsers. Aria-described attribute maybe a way to go but I don't know little about it. The caption element no longer exists for figures in HTML5. It has been replaced by figcaption. This was because captions were unstylable in browsers outside of tables. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Yes or No? HTML5 FOR WEB DESIGNERS
On 17 Aug 2010, at 16:49, jeffrey morin wrote: Does anyone have an opinion on whether the book, HTML5 FOR WEB DESIGNERS by Jeremy Keith is worth the purchase? I want to learn more about HTML5 but am turned off by the shameless promotion they've done for this book. Does anyone have any suggestions on other books or if this is worth it? Depends what you want it for. I've not read it, but I heard it was a good primer to introduce you to the topic. It is a fairly short book, so doesn't go indepth. There is another book, "Introducing HTML5" - introducinghtml5.com - which is more indepth. It covers the semantics and such in the first half and the JS APIs, Cavas and such in the second half. I've just started reading this, but it is by all accounts a good book. A disclaimer is that I work with one of the authors at Opera. Thanks, Jeff *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] :: opera mini 5.1 ::
On 7 Aug 2010, at 00:44, tee wrote: On Aug 5, 2010, at 4:23 PM, David Storey wrote: Not strictly true. First of all Opera Mini compresses the content and images (which is one of the reasons for the image quality setting - it will compress it less on high setting) to optimise it for low bandwidth devices. Opera (in general) also doesn't load resources that are set to display: none; until they are set to show on the page. Hi David, This is interesting but I am not sure I fully understand it. Compression this I understand, but not loading the display none part. Are you saying that Opera Mini able to exclude inline elements in the markup that are declared display none in the style sheet. Yes that is correct. If a resource is display: none, opera will not load it until you set it as display: block or whatever. Providing I understand your english correctly. If so, I would like to learn more the technical aspect how Opera Mini does it. Not much to learn (not that it really matters to you). Basically the browser reads the style sheet and doen't load the resource that are not displayed. If David L display none his 170kb inline image, Opera Mini will not load that 170kb or whatever reduced size that is after the compression? Not sure I understand but if it is what I think then no it will not display. When I did my final assignment for the Mobile Web Best Practices course I mentioned, I needed to make a page (a WordPress blog) stay within 10k file size I'm a member of that WG but honestly it is complete useless and out of date. It was commissioned when 12kb all together was a big deal. Now it is trivial. On smart phone no one cares as it is often unlimited data. On regular devices it matters cause you often pay per kb, but devices like OM have compression and 12 kb is too small for a realistic page. The limit is set brcause many on the WG are browser vendors or such from WAP browsers who have poor quality products (only IMHO) , that can't cope with real web sites (unlike Opera Mini or webkit browsers_ , it was more than a challenge having to watch over every byte in a dynamic page. I first used the media queries, "display:none" side column items (e.g., tags, archives, recent comment and inline image etc...) that I wanted to exclude in mobile version. Visually I get the result I wanted, but as far as markup and file sizes are concerned, they were still there in the source code. But not loaded unless the browser is very low quality. I tested the page over MobileOK Checker, the validator picked them up too, and that is how I concluded without some sort of content negotiation Don't trust automated systems. They will lead you up blind ally without a paddle. (along with other more aggressive methods), media queries is just a very nice idea for mobile version of site without much practical use, Bull terds. unless, we don't care at all optimization. unfounded and incorrect. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] :: opera mini 5.1 ::
On 5 Aug 2010, at 23:51, tee wrote:
On Aug 5, 2010, at 2:05 PM, David Storey wrote:
On 5 Aug 2010, at 21:12, tee wrote:
Hi David,
Having done 2 full sites+ many exercise mobile sites, I view at
Opera Mini (including the Mobile 10) the Internet Explorer 6+7,
it's a browser one will hate it, curse it more than praise it :-(
What are your issues with Opera Mobile (Opera Mini has known
restrictions as it is designed for low-end devices which can't
power a full browser; .
Are you mixing up Mini and Mobile,
Oops, I must be. Mini and Mobile sounded very much the same browser
to me, and I got an impression that Opera had consolidated the two
name from Mini to Mobile 10 since the version 5.
No. Opera Mini is for JavaME enabled feature phones and restrictive
devices (such as iOS), but does work on Smart Phones as it works
anywhere (and there are special versions for a number of smart phone
platforms to take advantage of features they offer such as being able
to be set as the default browser, which Java often can't offer)
Opera Mobile is for Smartphone platforms: Symbian, Windows Mobile,
Maemo and Android.
So the one I been using is Opera Mini 5 in my iPod (should this be
called a smart phone equivalent?)
No, iOS doesn't allow Opera Mobile due to its licensing terms and
conditions. It is capable of running browser such as Opera Mobile
technically, but not politically.
, but it does look to me like a full browser (and with many quirks).
We have a shared UI layer across our mobile (and a number of other
devices such as TV) products. On the surface the UI is the same
between Mini and Mobile, but the engine is different. Mobile is a full
Opera Presto rendering engine under the hood. Mini is a thin client
(you could almost think of it as something like a PDF viewer) which
renders on a server and sends the transcoded content to the Opera Mini
client. Mobile runs on more advanced platforms so it will allow for
more things in the UI like higher DPI rendering and such. Mini can
also cope with those things if running on smart phones.
I have experienced many issues in Opera Mini 5 which took quite a
bit of time to get rid of, some were fixed, but these two are quite
stubborn.
1. Pre tag - in portrait view if a line of content is longer than
the device width, it doesn't wrap.
Pre is special in that it doesn't suppose to wrap.
2. padding issue (I think) in the input. If I add a background image
like so and the image has a width of, say, 12px
input {
background: url(search-icon.png) no-repeat left top;
padding: 1px 2px 1px 16px
}
The input has a value of "search site", the text should be pushed
16px to the right. Andriod and Safari obeyed the rule, but Opera
Mini ignores the padding rule which resulting the text and
background image overlapped.
I'd need to see an example, but Mini makes a number of trade-offs to
fit on basic devices, such as the transcoding I mentioned earlier.
This does some reformatting to wrap content to a page width so no
horizontal scrolling of text and such is needed when zooming in
(horizontal scrolling is often difficult on feature phones, and
generally isn't a good experience in general to have to scroll left
and right to read text). This transcoding and line length wrapping
could be causing issues, especially if it works on desktop. The engine
on desktop and the engine run by the Opera Mini server is basically
the same. Some advanced graphical features are not supported (eg.
transforms, border-radius etc.) as they require our Vega graphics
engine to render, which isn't available in the device as it is a thin
client. We could transcode such things technically to images, but that
would be too costly in terms of bandwidth.
I am sure I will find more issues in this browser as I get more
opportunities to work on Mobile version of websites.
Sure. Remember to file bugs: bugs.opera.com/wizard/ . That way we will
fix them if it is possible, as we can't fix issues we don't know
about. Of course there is always trade offs in making a browser for
such limited devices, so we can't promise we will be able to fix
everything.
I often think Opera desktop has paddings/margins/line-height bug
related to EM and % which seems never fixed, but then it might be
Opera way of handling them, and they are carried over to Mini.
Opera has some rounding issues with large values of em's and % yes.
They are on the roadmap to be fixed but it takes time as browsers are
complex and there are always lots of things to fix, and lots of new
HTML5 or CSS3 or SVG features to support which are used by many
popular services and need to be supported. There are trade offs to be
made to support the rounding correctly, but we will fix it sooner
rather than later.
A browser that has only 5+
Re: [WSG] :: opera mini 5.1 ::
On 6 Aug 2010, at 00:48, tee wrote:
On Aug 5, 2010, at 1:41 PM, David Laakso wrote:
Whoops. Hit send too soon. Here's the rest of it...
Got the iPod screenshot, thanks -- will look into it.
The image issue has been resloved in the Opera Mini Simulator and
in the Sany Mirro handset [a low-end device] with Duncan's
suggestion of setting Image Quality High. This makes the image from
too narrow to too wide.
I changed the CSS as follows to reduce the image width: /* was 96% */
@media handheld, screen and (max-width: 480px), screen and (max-
device-width: 480px) {
body#p #main img {
max-width : 35% !important;
height : auto !important;
}
} /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/
If you add this in the above @media rule the horizontal scrolling
will go away.
header, #page {
margin : 0 auto;
width: 100%;
}
I was not aware the Opera Mini image rendering differences in image
quality setting with low, medium and high until Duncan pointed out.
From the mobile user point of view, changing image quality to high
might not be a good approach though. In my iPod, the default quality
is medium, and I assume this is the majority will see in their
Opera Mini.
Some thoughts, not related to the issue you are having, but I think
they are valid points for your mobile users.
A side note, I have just completed the W3C Mobile Best Practice
course taught by Phil, and have learned many practical, useful
skills and knowledges. One of the strong emphasizes Phil taught us,
is to "Specify the size of images in markup, if they have an
intrinsic size."
To get a Mobile OK (optimized) site, a page cannot be more than 10K.
That image you have, is 170kb and that you using one style sheet
with media queries to target all devices, if I am a user on the go
who needs to watch over bandwidth and monthly phone bill, I don't
think I would be happy visiting your site.
I was very excited when I first learned how to use media queries
just few months ago, but after the course, I found that just the
media queries will not do if you need to optimized a mobile version
site.
I completed the course with a conclusion that Content negotiation
almost is a must just for one simple reason, using media queries to
"display:none" only makes the content/element you do not want mobile
user to see off the screen, it does not eliminate the sizes that
slow the page load, eat up user's phone bill.
Not strictly true. First of all Opera Mini compresses the content and
images (which is one of the reasons for the image quality setting - it
will compress it less on high setting) to optimise it for low
bandwidth devices. Opera (in general) also doesn't load resources that
are set to display: none; until they are set to show on the page. Your
mileage may vary with other browsers though. Opera Mini is designed
for feature phones with slow networks that cost per kb. This is why it
is hugely popular across Asia, Africa and South/Central America. It of
course has some trade offs in what it can support using the client
server approach, but those trade offs are worth it for the users, as
the alternatives would be no internet at all or one that costs too much.
Ignoring the strengths of Opera Mini, you can easily use Media Queries
without just using it to override screen styles to hide them for
mobile. For example you can provide two stylesheets; one only for
screen and one only for small screen devices. you can set the media
query to be mutually exclusive so the mobile browser never gets the
stylesheet designed for desktop and thus doesn't have to override the
styles. Or otherwise you can use the default stylesheet to style the
mobile page, and use another stylesheet to override those styles for
desktop. The mobile will then never download those styles.
Depending on the context, it is often best to try to keep the images
linked from the style sheet, rather than in the HMTL (especially if
presentational ) so you can specify an optimised one to the device
based on the media query. This doesn't matter for Opera Mini as it
will optimise it anyway (and not load it if display: none;, but will
benefit less bandwidth-smart browsers and devices.
This site may give you a general idea how much it may cost your
mobile user per page.
http://mobiready.com
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 3
Re: [WSG] :: opera mini 5.1 ::
On 5 Aug 2010, at 21:12, tee wrote:
Hi David,
Having done 2 full sites+ many exercise mobile sites, I view at
Opera Mini (including the Mobile 10) the Internet Explorer 6+7, it's
a browser one will hate it, curse it more than praise it :-(
What are your issues with Opera Mobile (Opera Mini has known
restrictions as it is designed for low-end devices which can't power a
full browser; which are the majority of the worlds devices people use
to access the web. Smart phones are only big in the West).
Are you mixing up Mini and Mobile, as you state "In my iPod Opera
Mobile 10". Opera Mobile doesn't exist for iPod as Apple do not allow
full browsers on iOS as JavaScript engines bar their own pre-installed
one are banned.
I think the problem might be this:
body#p #main img {border: 3px solid red;display: block;
max-width : 96% !important;
height : auto !important;
margin : 20px 0 0 0;
}
Should it not be "body#p, #main img"?
Apart for this, I don't think it's a good idea to declare max-width
for any mobile browsers, be it container or inline image. This rule
you have should take care of the width for portrait and landscape
view:
@media handheld, screen and (max-width: 480px), screen and (max-
device-width: 480px)
In my iPod Opera Mobile 10, your site results horizontal
scrolling, you might want to overwrite all the EM declared in
(max)widths to % in your @media.
A side note , next time you might want to post a tinyURL or bit.ly
(I like this!) address if ask mobile browser check because typing on
a tiny screen keypad on a tiny screen for a long url address is no
fun :-) Some mobile emulators do not allow copy and paste either.
tee
On Aug 5, 2010, at 11:27 AM, David Laakso wrote:
markup
<http://chelseacreekstudio.com/site/portfolio/01.php>
css
around line 669
<http://chelseacreekstudio.com/site/css/sisu.css>
The image does not fill the width of the window in
Sanyo Mirro scp3810 for BoostMobile running Opera Mini 5.1
nor in the Opera Mini Simulator.
<http://www.opera.com/mobile/demo/>
What to do?
It does fill the window in Mac OS X 10.4 at 600, 480, and 400.
And it fills the window in the iPhoney Simulator...
Best,
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter:
dstorey
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] @media ordering in stylesheet
On 5 Aug 2010, at 19:20, Jody Tate wrote:
Hi all,
Does @media rule ordering in a stylesheet matter? For example, given
the following order:
@media print {
body {
#FF;
}
}
@media all {
body {
#99;
}
}
Will @media print override the @media all in this ordering?
No. the @media all will apply (well if there were any valid rules in
the block). If the specificity is the same (as is the case in this
example) and the query conditions both apply then source order wins.
Googling around, I've not found a clear answer to the question. So,
any help is appreciated.
Thanks in advance,
jody
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter:
dstorey
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
[WSG] Opera Dragonfly survey
Hi, The Opera Dragonfly team is conducting a survey to gather feedback on how we can improve and tailor our developer tools to meet the needs of developers and designers, such as yourselves. This is your chance to have a say in the future direction and road map for Opera Dragonfly. We'd very much appreciate it if people on this list can take a short amount of their time to fill in this survey and let us know how we can surve your needs better. The link is http://bit.ly/b8sAbJ Thanks for your time, David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] 「Opera」 Percent with css
On 5 Aug 2009, at 06:31, Bruno Fassino wrote: ピエール・アンリ・ラヴィン wrote: I don't understand the following issue with Opera: Let's set a container to 4000px, and children elements to 12.5% 4000px / 12.5 = 320px. But for Opera, * 12.5px => 12px : I can understand * 12.5% => 12% : I don't understand I can only say that this is an old issue with Opera, still present in beta versions of Opera 10: it simply ignores the fractional part in percentages used as width. In the past Opera had even worse "approximation" problems, see [1]. Now most of these are fixed, but percentage widths are still "stepped" [2], and borders expressed in em still have a crazy behavior [3]. Yes, we have had and do have a number of rounding issues in Presto. The worst issues that were causing the biggest problems have been fixed but there are some left. They are something we are looking into fixing but they need to be put into priority with other bug fixes and new capabilities. I'd be careful with pixel perfect layouts in general as it is difficult getting them consistent across browsers, and especially platforms. Just the different anti-aliasing can change things, or is often the case in our bug reports, developers line things up pixel perfect and don't take into account platforms like Linux have different fonts with different x heights and the whole layout falls down like a stack of cards as the linux font takes up more space. Best regards, Bruno [1] http://brunildo.org/test/emarg.pl [2] http://brunildo.org/test/percwidth2.pl [3] http://brunildo.org/test/embord.pl -- Bruno Fassino http://www.brunildo.org/test *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ******* David Storey Chief Web Opener / Product Manager, Opera Dragonfly W3C WG: Mobile Web Best Practices / SVG Interest Group Opera Software ASA, Oslo, Norway Mobile: +47 94 22 02 32 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] HTML 5 and XHTML 2 combined
ild upon HTML and XHTML (work with it, fix it, whatever) suppose to conform to browser vendor's goals? They should not be allowed to tell working groups what should and should not be allowed! It is not up to them. If it is, what is the purpose of the working groups? Are the working groups composed only of browser vendors, or both designers/coders and browser vendors? Vendors should be made to follow the standards and codes, and ideas and goals of the working group, should they not? -- Brett P. On Tue, Jan 13, 2009 at 3:10 AM, wrote: Hi, On Fri, Jan 09, 2009 at 06:50:18PM +, Philip TAYLOR (Ret'd) wrote: > I am arguing that HTML 5 should stop carrying with it the baggage of > earlier, arguably poorly thought out, standards and should rather have > the courage to propose how things will be expressed /in the future/. > By definition, this will require browsers to parse (and process) HTML > 5 documents differently to how they parse and process documents > conforming to earlier standards (and, of course, how they parse and > process documents that lack a DOCTYPE directive and which therefore > cannot be safely assumed to conform to any standards whatsoever). By > so doing, HTML 5 could define the element to be a container (in > HTML 5), even though it was not a container in previous > specifications. I think this is precisely what XHTML2 set out to do. HTML5 came up because browser vendors didn't agree this is the right way... How do you imagine this could be reconciled? If you hijack HTML5 to effectively become XHTML2, browser vendors will just again come up with something different conforming to *their* goals. (HTML4.5 or whatever.) -antrik- -- Molte CosSinCalc http://cossincalc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** David Storey Chief Web Opener, Product Manager Opera Dragonfly, Consumer Product Manager Opera Core, W3C 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: dsto...@opera.com Blog: http://my.opera.com/dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Examples of great high-school websites?
nux: it just tastes better = nosoftwarepatents http://egressive.com we only use open standards: http://w3.org Effusion Group Founding Member === http://effusiongroup.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** David Storey Chief Web Opener, Product Manager Opera Dragonfly, Consumer Product Manager Opera Core, W3C 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: dsto...@opera.com Blog: http://my.opera.com/dstorey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] div over flash
On 23 Oct 2008, at 15:35, kevin mcmonagle wrote: hi, forgive me if this it ot, if so please reply off list. Whats the best cross-browser way to get a div on top of swf with css. If i use: For having things like dynamic menus over flash using javascript, wmode needs to be set to transparent. with z-index will it be sufficent? -best kevin *** 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, W3C 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] ***
Re: [WSG] Coding for CSS3?
There is a CSS3 profile for the CSS validator, so just switch to that. http://jigsaw.w3.org/css-validator/#validate_by_uri +with_options (choose the profile) Note that much of the CSS3 spec is not stable so many implemented properties use the vendor prefixes (- o-, -webkit-, -moz- for example), and these will not validate. I don't see any harm in using them, as we need usage of these properties to see if the spec and implementations are on the right lines. The only thing would be to make sure that the none-prefixed version is also used so it will work when other browsers add support, and they are used in a way that the page degrades gracefully if there is no support (border-radius degrades gracefully as the user will just get square corners if it isn't supported in their browser. Opacity is supported by all major browsers (without vendor prefix) except IE. You can use CSS filters in a IE only stylesheet (via conditional comments for example) to add IE support. There will be no official release of CSS3 as such. It is broken into modules, and each module matures as it is ready. The closest we have is the 2007 profile of CSS, which defines what is ready circa 2007. This is CSS2.1, CSS 3 Namespaces, CSS3 Colour module and CSS3 Selectors. I'd expect CSS3 background and borders and CSS3 Media Queries and perhaps CSS3 Web Fonts to make it in the 2008 version. http://www.w3.org/TR/css-beijing/ On 2 Oct 2008, at 16:09, Ben Lau wrote: Hi all, I'm having trouble deciding whether to begin coding using CSS3, such as using (but not limited to) opacity. Although the CSS validator returns an error, but it claims it'll be supported in CSS3. As far as i know, FF2, FF3, Opera and Safari already renders the opacity property, leaving Internet Explorer, which we could use alpha properties in separate stylesheets and conditional comments. Anyone know if IE8 supports it? I haven't had a good look at all CSS3 properties yet, but I'm wondering if this is a good time to code for the future? Or better to wait for official release of CSS3? If CSS3 is released tomorrow, what about older browsers like IE6? Cheers, Ben *** 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, W3C 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] ***
Re: [WSG] Uppercase Tag Names
Seems like a common issue of out dated methods being taught. Feels free to pass the lecturer in question to me. I'd be quite happy to discuss it with them. Also feel free to point your school towards the opera wsc at opera.com/wsc On 26 Sep 2008, at 13:59, Anthony <[EMAIL PROTECTED]> wrote: It's no wonder students are coming out with such strange ideals. Tell him WSG says so. Regards, Anthony. Sent from my iPhone! On 26/09/2008, at 10:40 PM, Todd Budnikas <[EMAIL PROTECTED]> wrote: it's irrelevant according to HTML 4 how you write the tags, so on one front, your instructor is ok to say you should code that way (as it does conform) but you have every right to say that he's *incorrect* when saying you "need to so that you can conform to HTML 4.01". Tough spot to voice your opinion perhaps, but you're not wrong, and i would agree about your readability statement which might be a good point to make, since it can be written either way. Heck, it might be easier to use upper and lowercase: http://htmlhelp.com/reference/html40/structure.html#elements Also, attributes *names* (ie. WIDTH) are case-insensitive but attribute values may be case-sensitive. From: "James Jeffery" <[EMAIL PROTECTED]> Date: Fri, 26 Sep 2008 12:38:39 +0100 To: Subject: [WSG] Uppercase Tag Names I am at university at the moment, and they said to use uppercase text for tag names and lowercase for attributes. I have to do it because otherwise I will lose a mark. I disagreed (because it makes the source hard to read) but he said you need to so that you can conform to HTML 4.01. I think this a case of someone reading far to deep into the specs. I didn't really want to argue with him because he assumes I know nothing. I do know that the source code has become difficult to read using that method. *** 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] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Google chrome...
On 7 Sep 2008, at 04:52, MichaelMD wrote: They block themselves too. Google has a history of browser sniffing and blocking browsers such as Opera. On Google groups for example, they block Opera, Safari *and* Chrome when trying to change your profile photo. I'm sure there are other examples too as the block Opera on many sites. It's an example why browser sniffing is so bad. Not only is it often used to block browsers that would otherwise be capable, but you never know when a new browser will come out (even from your own company). Yes its funny watching this common scenario with large organisations.. one department is often not aware of what another department is doing until they start getting complaints from the public about something not working! ...most likely it has something to do with the browser-specific javascript quirks you are likely to come across when trying to build those fancy drag'n'drop user interfaces. Do they have an alternate way to change that photo that doesn't use javascript? The point is it works fine in Opera, Safari and Chrome, if they didn't have the browser sniffing there. You can test it in Opera by masking the user agent as Firefox. It's the same with the majority of the cases I deal with, with browser sniffing and Opera. It just blocks a browser that would otherwise be capable to access the content. *** 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, W3C 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] ***
Re: [WSG] Google chrome...
On 6 Sep 2008, at 04:12, Marius Milcher wrote: Has anyone noticed how Hotmail is 'unavailable' in Chrome?? Recommending one upgrades to either: IE, FF or Safari. Could this be a snub by Microsoft?? Innocent browser compatability issue? What's the opinion? Seconds out...Round 3 They block themselves too. Google has a history of browser sniffing and blocking browsers such as Opera. On Google groups for example, they block Opera, Safari *and* Chrome when trying to change your profile photo. I'm sure there are other examples too as the block Opera on many sites. It's an example why browser sniffing is so bad. Not only is it often used to block browsers that would otherwise be capable, but you never know when a new browser will come out (even from your own company). 2008/9/5 Michael Horowitz <[EMAIL PROTECTED]> Because that is an intentional part of the way the system is designed. Read the comic for all the details http://www.google.com/googlebooks/chrome/index.html Michael Horowitz Your Computer Consultant http://yourcomputerconsultant.com 561-394-9079 Nancy Gill wrote: One thing I have noticed today is that it creates 3 different processes in the Task Manager to run one coyp of chrome. I have tested this several times with the Task Manager open and everytime I open the browser, I add three processes all named chrome. They vary from 5mb to 44mb of memory usage. I can't figure out why it has to load the process three times in order to run. Nancy - Original Message - From: "kevin mcmonagle" <[EMAIL PROTECTED] > To: Sent: Thursday, September 04, 2008 2:42 PM Subject: Re: [WSG] Google chrome... First i thought it felt unfinished, but then the minimal design grew on me. Very uncluttered. And drop down menus consolodate a lot of screen real estate. Well designed gui, all its needs now is firebug and id use it. And i like the incognito windows, thats a slick feature. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** __ Information from ESET NOD32 Antivirus, version of virus signature database 3416 (20080904) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com *** 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] *** -- -- Marius G. Milcher Web Design & IT Consultancy -- w: http://www.mariusmilcher.com e: [EMAIL PROTECTED] t: +44(0)7961 436 733 skype: mgmilcher -- *** 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, W3C 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] ***
Re: [WSG] Google chrome... Coming very soon...
On 3 Sep 2008, at 13:08, Todd Budnikas wrote: On Sep 3, 2008, at 6:19 AM, David Storey wrote: On 3 Sep 2008, at 11:42, tee wrote: On Sep 3, 2008, at 2:36 AM, David Storey wrote: On 3 Sep 2008, at 11:28, Regnard Raquedan wrote: Well, if it's akin to Safari, then it's as good as testing it there, right? :) Or is it...? No, it has a different JavaScript engine, and doesn't support a number of things the regular WebKit supports, such as text- shadow, @font-face and a few others. Does it support border-radius or -webkit-radius? no browsers support border-radius. It does support -webkit-border- radius, as far as I know (I'm running on Mac and parallels doesn't work on my 64-bit Vista, and I can't be bothered to do the few hours re-install process of Vista) -webkit-border-radius renders just fine. Running Chrome on XP on VMWare Fusion. http://www.css3.info/preview/rounded-border/ Without WebKit's anti-aliasing as far as I can tell from Twitter posts. I'm wondering if this is due to webkit using platform specific code for things like this and text-shadow, as being a reason why they are not in Chrome (Safari on Windows has a compatibility layer), or if it is a older branch. I'm thinking more the former. tee *** 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, W3C 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] *** *** 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, W3C 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] ***
Re: [WSG] Google chrome... Coming very soon...
On 3 Sep 2008, at 11:42, tee wrote: On Sep 3, 2008, at 2:36 AM, David Storey wrote: On 3 Sep 2008, at 11:28, Regnard Raquedan wrote: Well, if it's akin to Safari, then it's as good as testing it there, right? :) Or is it...? No, it has a different JavaScript engine, and doesn't support a number of things the regular WebKit supports, such as text-shadow, @font-face and a few others. Does it support border-radius or -webkit-radius? no browsers support border-radius. It does support -webkit-border- radius, as far as I know (I'm running on Mac and parallels doesn't work on my 64-bit Vista, and I can't be bothered to do the few hours re-install process of Vista) tee *** 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, W3C 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] ***
Re: [WSG] Google chrome... Coming very soon...
On 3 Sep 2008, at 11:28, Regnard Raquedan wrote: Well, if it's akin to Safari, then it's as good as testing it there, right? :) Or is it...? No, it has a different JavaScript engine, and doesn't support a number of things the regular WebKit supports, such as text-shadow, @font-face and a few others. I'm giving Chrome a test run right now and eerily, it's as if I'm using Firefox. But then again, I've only used it for less than a day. On Wed, Sep 3, 2008 at 4:51 PM, Naveen Bhaskar <[EMAIL PROTECTED] > wrote: so one more browser to check for browser compatibility in future...like other google products this is going to be the popular one. thanks and regards Naveen Bhaskar Bangalore - Original Message From: kate <[EMAIL PROTECTED]> To: wsg@webstandardsgroup.org Sent: Wednesday, 3 September, 2008 12:06:49 PM Subject: Re: [WSG] Google chrome... Coming very soon... Works great for my needs, I can use Google's Gmail to delete and send mail at home..I like it! Kate - Original Message - From: Anton Babushkin To: wsg@webstandardsgroup.org Sent: Wednesday, September 03, 2008 1:50 AM Subject: Re: [WSG] Google chrome... Coming very soon... Google Chrome wasn't working for me in the office either, but I think its all due to the firewall and proxy that we have setup here. It couldn't seem to negotiate between the proxy and the installer. I just hooked it up to an outside ADSL connection (my work PC that is), and typing this Email through Chrome right now :) Its a brilliant browser, a true innovation to the way we use the web. Too bad Java and Shockwave don't work on it yet. On Wed, Sep 3, 2008 at 11:43 AM, Blake <[EMAIL PROTECTED]> wrote: Indeed. We have some very clunky sites and they loaded almost instantly. I couldn't believe the rendering speed. However Gmail won't load on any computers with Chrome on at work (in fact, I can't sign in to any google services). Is this problem affecting everyone or is it just our network? If it's affecting everyone that's pretty massive fail for Google. (e-mail sent from Gmail in Firefox!!) On Wed, Sep 3, 2008 at 10:15 AM, Jeffery Lowder <[EMAIL PROTECTED]> wrote: > > I know, I tired it on a couple of the more intensive ajax dependent pages I've been working on and it puts FF to shame. > If people realize how much faster they can surf the web - this thing is going to take off big time. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- - Anton Babushkin *** 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] *** Did you know? You can CHAT without downloading messenger. Click here *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Regnard Kreisler C. Raquedan, MSc. mobile: +63.919.2907711 email: [EMAIL PROTECTED] web: http://www.raquedan.com yahoo!/skype: rkraquedan -- Building websites the Standards way: http://webstandards.raquedan.com -- Movie & TV Review Blog http://www.screensucked.com -- The AIM Blogger http://theaimblogger.blogspot.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, W3C 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] ***
Re: [WSG] Code for Firefox, hack for IE
If coding for the most standards compliant browser, then hack for IE, then you wouldn't code for FF first. Maybe third. It however comes with the best developer tools on the market, which makes it easier to developer for, and that comes from someone that is working as the product manager for Opera Dragonfly. We are working to catch up with and surpass the likes of Firebug and friends, but we are not there yet. It is probably best in my opinion to develop while checking in at least two of the major none-IE/Trident browsers engines (preferably three), especially after making major changes, just to make sure you are not relying on a browser bug or a vendor specific property. Then make it work for IE using conditional comments, as they are much less frail than css hacks and browser sniffing. With CC's you can override the properties IE gets incorrect or doesn't support by using the CSS cascade, and you never have to worry about them affecting the other browsers. On 1 Sep 2008, at 12:55, David McKinnon wrote: Hi, For a while now, I've been operating on the principle "Code for Firefox, hack for IE". That is, writing CSS for the most standards-compliant browser, and then making adjustments for non-standard behaviour. I said this in a meeting last week to argue a point and my boss said "who says?". I could have said "me", but maybe that's not a good enough answer. Somewhere some years ago I read this, or heard someone at a conference or something and it got stuck in my head. Is this the way anyone works? Is it the best way to work? Does anyone know where I got this idea from? Book? Blog? A bit of googling this afternoon turned up not very much. Thanks, David *** 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, W3C 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] ***
Re: [WSG] ARIA
On 10 Aug 2008, at 04:57, [EMAIL PROTECTED] wrote: It would be really nice, that instead of introducing more and more design element features like ARIA markup, that what is and isn't supported at different levels (HTML4 or HTML5 or XHTML), ARIA is about accessibility, not design. that w3c and the browser vendor's worked together to properly come to agreement on what should be used rather then what they want to make as they're own spin off. We are. WHAt-WG was a co-operation between three major browser vendors, and the work they produced in Web Applications 1.0 has been rolled into the W3C as HTML5. Apple have made a number of vendor specific extensions to CSS recently, but they've submitted them to the CSS WG for consideration for CSS3. I mean, look at what IE does to CSS, and then Opera uses the standards differently although much better. At least, as far as I can tell Mozilla are the only ones to get it completely right, but then even it has it's own quirks. :confused: You have an example? How do Opera treat standards worse than Mozilla? Opera probably has the least vendor specific CSS features of any major browser, and is at least on feature par with Safari and Mozilla. As far as I know Opera are the closest to full CSS2.1 support (only visibility: collapse missing in 9.5), and up there with CSS3 with full selectors support and many other features. The next version of our Core engine supports all of ACID3 for example (including web fonts, HSLA/RGBA etc.). No, instead of developing new ways to write markup, they need to get into agreement (finally) of what the standards are truly going to be. I for one am tired of writing up code for different browser's and having to hack code around to make things work. What we need to be doing is pushing the vendor's into getting it right. James Jeffery wrote: Never really heard of ARIA until I came across it in a Web Development magazine (.net mag). I have just spent a few hours getting my head around it, and whilst I agree it looks useful for screen readers and such, isn't it less semantic? Applying attributes that would currently make your markup invalid is something which I am not happy about. Along with that, using to create a checkbox seems less semantic than using form elements. Is ARIA markup only supposed to be used with browsers who have JS enabled or sites that use alot of JS for dynamic content? What about browsers that don't support ARIA markup? I'm only dipping my feet in the water at the moment so I probably don't fully understand, but from what I have read so far it seems a bit wishy washy at the moment. Any replies appreciated. *** 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] ******* 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] ***
Re: [WSG] Re: ARIA
On 11 Aug 2008, at 20:30, Rob Crowther wrote: David Storey wrote: thing it adds is giving you more brownie points for validating, while not allowing WAI-ARIA to work if JavaScript is turned off. I would have thought that, if JavaScript was turned off, the ARIA stuff wouldn't be too useful. As its purpose is to communicate dynamic changes performed with JS to assistive technologies? If JS is turned off then there's no in page updates and regular WCAG applies? Does ARIA have benefits even to 'static' HTML apps? It can do. For example, authors often create controls using bits or mark up like spans and divs. While it is best to use the correct HTML element, ARIA can tell the screen reader what you mean the mark-u to be. Google uses divs instead of buttons quite often for example (probably for styling reasons). While that is a bit more contrived there are controls, such as trees or sliders where there are no correct html element to use. Mostly JavaScript would be used, but it is possible with just server side code if needed. Rob *** 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] ***
Re: [WSG] Re: ARIA
On 11 Aug 2008, at 17:26, Hassan Schroeder wrote: David Storey wrote: When will the W3C validator support ARIA? I've no idea for HTML, but I'm not sure it is 100% important. If the rest of your code is valid and the only thing that is invalid is the WAI-ARIA stuff then that would be good enough for me... You're missing the point -- I validate not for religious purity but to make sure I have a valid DOM (no overlapped/missing tags, typos in element names or attributes, etc.). Then your solutions are either to do as the W3C suggests and use the class attribute for WAI-ARIA role names, and add afterwards using JavaScript/DOM, or validate before adding the ARIA stuff, then add when you are sure the rest of the mark up is correct. Analyzing each validation to see if errors are "OK errors" or "real errors" is not acceptable. We want green bar here, always :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-621-3445 === http://webtuitive.com dream. code. *** 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] ***
Re: [WSG] Re: ARIA
On 11 Aug 2008, at 16:47, David Dorward wrote: On 11 Aug 2008, at 15:14, Hassan Schroeder wrote: David Dorward wrote: It doesn't really reject it, it just warns you that the combination doesn't make much sense. Sigh. Semantics. That was one suggested DOCTYPE that I found -- and no, I'm not sure at this point where -- but regardless, do you know the answer to the *original question*: When will the W3C validator support ARIA? As I said "Now". Or, if you believe it already does, what is the appropriate DOCTYPE to use? Umm. What does the spec say? http://www.w3.org/TR/wai-aria/ says: "http://www.w3.org/MarkUp/DTD/xhtml-aria-1.dtd "> http://www.w3.org/1999/xhtml"; xml:lang="en"> ... This is fine, but is XHML served as XML, so it wont work in IE, thus the real world (unfortunately) -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ *** 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] ***
Re: [WSG] Re: ARIA
On 11 Aug 2008, at 16:14, Hassan Schroeder wrote: David Dorward wrote: It doesn't really reject it, it just warns you that the combination doesn't make much sense. Sigh. Semantics. That was one suggested DOCTYPE that I found -- and no, I'm not sure at this point where -- but regardless, do you know the answer to the *original question*: When will the W3C validator support ARIA? I've no idea for HTML, but I'm not sure it is 100% important. If the rest of your code is valid and the only thing that is invalid is the WAI-ARIA stuff then that would be good enough for me as it is a W3C spec that is approved and implemented by all the major browser. It is not like you are adding something invalid that only one browser implements or will make browsers rely on error handling. For XHTML it is a different kettle of fish as it was designed to be extensible using name spaces. Of course, you can't use XHTML as IE doesn't support it, so even with the XHTML doctype, browsers will treat it as HTML if you use text/html. Or, if you believe it already does, what is the appropriate DOCTYPE to use? As http://esw.w3.org/topic/PF/ARIA/BestPractices/Introduction states: "...extensibility to XHTML, for ARIA, is achieved through namespaces (i.e.: aria:haspopup). HTML documents do not support namespaces, so the required accessibility role and state metadata cannot be included directly in these documents. In HTML 4, authors can define accessible role and accessible states as keywords in the class attribute, then use an ECMAScript library to parse the class keywords and copy them into the appropriate role and state namespaces after the document has been loaded. This enables provision of ARIA states and properties while circumventing the HTML validator by using the class attribute." This will allow it to validate, but seems to add a whole lot of extra work for what is really just fooling the validator into validating as the WAI-ARIA stuff will still be in the DOM at the end of the day. Only thing it adds is giving you more brownie points for validating, while not allowing WAI-ARIA to work if JavaScript is turned off. -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-621-3445 === http://webtuitive.com dream. code. *** 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] ***
Re: [WSG] Re: ARIA
On 10 Aug 2008, at 11:53, James Jeffery wrote: Progressive enhancement and accessibility. Hmmm. I am not sure about this, I thought accessibility was about providing access to websites from all angles, not progressivly enhancing access to users with more up to date technology or browsers. Would it not be better to include ARIA markup in HTML5 rather than trying to adapt it to the current version of HTML? Don't get me wrong, I love the idea of ARIA. In an ideal world yes, but HTML5 is years away, and not ready for authors to start using in the wild yet. HTML4 and XHTML1 are the here and now. WAI_ARIA was retrofitted from XHTML2 (I believe) to HTML so that it could be used right away. All major browser vendors support it now, once IE8 comes out. That means people with disabilities will start seeing the benefits now, instead of many years down the line. I'm not on the HTML5 group or follow it as closely as I'd like, but I don't see too many reasons why many of the roles used in WAI-ARIA wont be added as elements in HTML5, or at least WAI-ARIA becoming part of that spec. It just seems like another quick fix to plug the current problems. I can't imagine ARIA markup being used all that much anyway (I will use it, but I am talking about the majority of other developers). One of the reasons is because the majority of poor developers out there cannot be bothered to learn anything new and don't give a hoot about accessibility. The state of the web at the moment in terms of accessibility is poor anyway. This shouldn't be as big a problem as it seems on the surface, because library vendors have already, or are in the process of adding it to their libraries. Developers will get it for free when they use off the shelf components, such as provided by Dojo, YUI etc. I would guess the poor developers you speak of would rather take a pre-written slider (for example) than write their own from scratch. I was speaking with a top PHP developer not so long back. He works for a company and is on serious money, and even he little idea about accessibility on the web. I think before we start implementing new ideas we need to inform the the current and the up and coming developers about accessibility. Education is really important, but that applies to all web technologies, not just WAI-ARIA. This is one of the reasons why Opera commissioned the Web Standards Curriculum, and a recent article on WAI- ARIA. You can check out both on dev.opera.com. Its not my place to say what should and what shouldn't happen on the web, these are just my views. It kind of reminds me of microformats. A brilliant idea but underused by developers. I am just going to carry on learning, and hope that the ARIA reaches its goals and targets and doesn't get brushed under the carpet. I'm hopeful because of the early adoption by both browser and library vendors that it will be adopted. Even if it is just used by the likes of Google to make its map controls accessible then that will be a small win. Because of the way it was designed it is possible to retrofit previously inaccessible sites to make them more accessible. James On Sun, Aug 10, 2008 at 10:01 AM, Laura Carlson <[EMAIL PROTECTED]> wrote: What about browsers that don't support ARIA markup? Graceful degradation (if the page is well written). Or progressive enhancement. Some references: http://www.d.umn.edu/goto/javascript#access A good intro to WAI ARIA by Gez Lemon: http://dev.opera.com/articles/view/introduction-to-wai-aria/ Best Regards, Laura ___ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ *** 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] ******* 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] ***
Re: [WSG] Mobile graded browser support
As a slight update to this discussion, Opera has just had a timely release of our Mobile Browser Report [1]. A short digest: 9 out of the 10 top handsets in the US are Blackberry, with 4 out of 10 in the UK. The only other country that featured a Blackberry device was Germany with 2 out of 10. Globally, apart from the US and UK, Nokia dominates along with Sony Ericsson. Samsung is strong is South Africa. Motorola are conspicuous by their absence (they only feature once in the top ten model list for the top 10 countries where Opera Mini is the most popular). Palm is now also absent. They used to be strong in the UK and US, and possibly still are with business users (I see them a lot at conferences still), but the lack of a JVM by default hampers the install rate of Java based browsers. In June Opera Mini had 14.5 million unique users (Summer months are typically quiet due to summer holidays), and 3.2 billion web pages. The list of phones should give you a good idea of what kind of phones to test on and design for, as millions of users are represented by these models. Japan is a popular mobile market, but Opera doesn't supply Opera Mini there, so there is no data. We only distribute Opera Mobile (our biggest partner KDDI - second biggest operator in Japan - calls this PC Site Viewer) in Japan due to the proliferation of high end handsets and fast data rates. [1] http://www.opera.com/mobile_report/2008/06/ On 21 Jul 2008, at 16:53, Ted Drake wrote: 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] *** 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] ***
Re: [WSG] Mobile graded browser support
w.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] ******* 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] ***
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] ***
Re: [WSG] iphone should not be part of your url
present and the future! Locking ourselves in to one device is not a strategy for the future, even if iPhone shows up as the leading mobile device in usage stats today. Remember, there once was a time when MSIE was so dominant that as a web developer it made sense in many ways to develop MSIE only web sites! It also has a very specific style and so companies will try and cater to this (e.g. the facebook web app was designed to look like a native iPhone application). That I predict is a fad that will quickly go away. Site owners will soon see the benefits of designing for the brand of the website, rather than the brand of the device it is accessed from. Of course, now there is the App store and the ability to run third party applications, I'm sure a lot of these iPhone specific websites will disappear as the developers move to offering a built in solution. Hopefully you are right. Off topic: The fact that people will jubilantly welcome a solution that means they are getting locked in to a single vendor is also beyond my understanding... And I am not a Mac hater. I use Macs (as well as Windows and Linux) and listen with delight to my iPod. Lars Gunter *** 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] *** 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] ***
Re: [WSG] XHTML 1.1 & CSS3 - Is it worth using right now?
On 12 May 2008, at 22:42, Simon wrote: Hi, Does anyone use XHTML 1.1 and does it provide any benefits? I've read up on what the differences are but I was under the belief IE won't support it without a particular hack. Is there a reason why not many sites adopt this Doctype and is there any point using right now if your site is 1.0 Strict? Not really. There are only a couple of main differences between XHTML 1 and 1.1. The first is that it has been redefined in a modular fashion. As a web developer you get no benefit from this. The second difference is that there is a Ruby module (the only new functionality). Ruby is a way of including ruby text relating to the regular text. This is mostly used in Asian languages to explain how to pronounce words. It is only supported by IE, even though XHTML isn't supported by IE. Secondly, I see a lot of sites that speak about CSS3 and using parts of that now in the browsers that support it. I get along fine with CSS 2 but haven't really adopted or tried any of the newer more advanced CSS3 techniques. I haven't really had to. Is it also worth learning this now or can I expect IE to hold back this standard for a long time yet? Depends on what you want to do. Media Queries are useful for optimising form mobile for example. There are a lot of nice new CSS3 selectors, supported by Opera and Safari (and to some extent Firefox), but they are not supported by IE. text-shadow is something I use quite a bit as it degrades gracefully in browsers that don't support it (IE and Firefox both don't), thus is unless you use a text colour the same as the background colour. box-shadow and border-radius are other properties that fallback nicely when not supported. Web fonts look interesting, but it may be hampered by needing to use free fonts that are allowed to be freely distributed. Some CSS3 is already used quite often in websites, such as opacity (supported by all mainstream browsers except IE) Some CSS3 are standardisation's of IE only propertis, such as overflow-x and overflow-y, which have widespread support now. Thanks for your opinions Simon *** 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] ***
[WSG] Opera Dragonfly released
Hi, I hope this isn't too off topic, but I thought you'd be interested to know that Opera launched Opera Dragonfly today - our new developer tools. This release is an early alpha to show the direction we are moving with our developer tools. This initial version will include a JavaScript Debugger, a DOM Inspector, CSS Inspector, Error Console and a Command Line. An upcoming version will also support editing of CSS/DOM/JavaScript, a single window mode and XHR/HTTP Headers inspection. The first of these updates should come in alpha 2 in a few weeks. Opera Dragonfly is built using Web technologies (XML, CSS and JavaScript) and will auto-update when a new version is released. We hope these will come out at a fairly rapid pace to begin with. The application will run in a persistent cache, so that it is accessible when offline, and so that it doesn't have to communicate with the Opera server, except when it updates. Opera Dragonfly will support all browsers that include the Core-2.1 rendering engine (except Opera Mini). This currently includes Opera 9.5 beta 2 and the forthcoming Opera Mobile 9.5 release. A proxy exists that allows Opera Dragonfly on the desktop to communicate with Opera on supported mobiles and devices. This makes debugging on devices easier as you can use a regular keyboard, mouse and monitor. To start Opera Dragonfly in Opera 9.5 beta 2 you can select Tools > Advanced > Developer Tools. On Mac we've found a bug whereby OS X's video memory gets corrupted, causing a crash. To avoid this you should use the new build available at http://snapshot.opera.com/mac/o950s_4808.dmg , which works around this problem. We'd very much appreciate your feedback on Opera Dragonfly, to make sure it fits the needs of the developer community. If you find time to test and use Opera Dragonfly, feel free to contact me with your suggestions, feature requests and bug reports. We really hope that it helps you when debugging issues in Opera, even at this early stage. Thanks, David Storey Chief Web Opener | Product Manager Web Standards | Product Manager Opera Dragonfly [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] When can I start using E4X
On 15 Jan 2008, at 12:01, Keryx Web wrote: He all! I have been searching the net for rumors and facts about E4X implementations. This is what I've found: Mozilla (Spidermonkey and Rhino) support E4X today - and has been doing it for a while! Adobe does too. So does (already/soon?) MbedThis. At least they are 100% committed. Webkit: "The E4X standard adds some XML-related features to the JavaScript language. We should consider adding these to the JavaScriptCore engine." http://webkit.org/projects/javascript/index.html My interpretation: Positive attitude, but no commitment. Opera: I can not find an official quote, but rumours on the web says they are committed, as in "Only Mozilla and Opera have committed just to E4x" http://theopensourcery.com/cssbasics6b.htm "I know Opera have E4X in the works at some level" http://www.codingforums.com/showpost.php? s=a9dfc400dfd427203a99487bd4ea29d9&p=448007&postcount=10 I can't comment officially on support for ECMAScript 4, but we do have people that are involved in the ECMAScript meetings (such as at http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006), and we do strongly believe in implementing standards. We also have an article on Dev Opera from our lead javascript engineer on why he loves ECMAScript4 - http://dev.opera.com/articles/view/why-i-love- ecmascript-4-real-decimals/ . So you can take those as hints that we plan support sometime in the future. KHTML: No info available, AFAIK. If it goes into webkit, I presume a backport would be feasible. (Or perhaps the rumors about merging with Webkit are true...) iCab seems to be on board as well: http://www.snailshell.de/blog/archives/10-01-2005_10-31-2005.html Which in summary says that only MS are clearly unwilling to implement this feature. We may get it through ScreamingMonkey, though. My questions: 1. Are there any clear indications from the developers of these browser engines (or their internal ECMAScript engines) that I've missed? 2. Will E4X on MSIE in fact be facilitated through ScreamingMonkey? 3. When do you predict that we can really start using E4X and expect it to work for most visitors to our websites? Probably quite a while yet. even when browsers support it, it takes a log time for users to upgrade to the latest and greatest. many people I meet don't even know what a browser is, never mind why or how to upgrade it. if you want to use it for progressive enhancement, then you can use it sooner, but that depends if you have a client that doesn't mind the site not working as well in IE6 or 7 and probably IE8. Lars Gunther *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Opera files antitrust against MS: standards one part
I just one to make one point about this case clear (although I'm not involved in it in any way). The complaint is manly about getting Microsoft to follow accepted web standards more closely, and isn't about money at all. I believe we (Opera) have stated that we don't want to earn any money as a result of this complaint. Hopefully this is not one of the cases where just lawyers win. I'm hoping that IE8 comes out and surprises a lot of people with its level of standards support. That would be a win for everyone. David On 14 Dec 2007, at 00:05, James Ellis wrote: Hi I read this on the Opera feed this morning, I'm not sure how it will proceed but it mentions: "The complaint describes how Microsoft is abusing its dominant position by tying its browser, Internet Explorer, to the Windows operating system and by hindering interoperability by not following accepted Web standards" http://www.opera.com/pressreleases/en/2007/12/13/ I wonder what the flow on effects of this would be internationally rather than just in the EU ? Of course there is the opinion that only lawyers win out of arguments like this but it would defnitely be a more interesting playground if IE wasn't bundled and supported accepted standards better. Cheers James *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Web Standards Presentation
Opera may be working on educational material of our own, through our Developer relations and Dev.opera.com work. I'll take a look, but as a quick first suggestion, it may not be the best idea to use a flash menu in a standards site. I'm not sure if you've put much accessibility work into it, but it is a core part of the site and wont work on a number of devices where Adobe don't make flash available or there are not enough resources for it to run. David On 27 Nov 2007, at 19:18, Christian Snodgrass wrote: Hello, I am going to be giving a presentation on Web Standards to all relevant professors at my university to help them catch up and get up-to-date in what they are teaching the students. I am putting together various resources for them, including a website (which can be found at http://www.arwebdesign.net/webstandards), a slideshow presentation (or possibly several), and any other resources they might find useful. This will be on ongoing project, with plans for me to do a new presentation at least once a semester and for me to continually update the website with new information, resources, and to send out a newsletter to them answering any questions they have and what not. While this is being designed specifically for my university, it is open to anyone who finds the information helpful. Since this is the Web Standards group, I'd like to ask if some members would be willing to look over the information I have gathered and I am developing and would comment, critique, correct, etc. on everything I have presented. The website is in it's very early stages as I am still working on the actual content of the site before I worry about the website itself. I have uploaded the current plans for navigation and a skeletal outline of the information I plan on presenting to http://www.arwebdesign.net/ webstandards/files/outline.pdf (also available in .odt). If you could look over the topics I plan to cover and give any recommendations of any topics or sub-topics you think I missed, I'd be very grateful. This presentation is only an hour long, but all of the information will be available online, so even topics I don't get to cover they can view online. I will be updating the outline continually throughout the next several days, as well as the website, so check them out regularly if you are able to. Once again, thanks for your help, Christian Snodgrass -- Christian Snodgrass Azure Ronin Web Design http://www.arwebdesign.net/ <http://www.arwebdesign.net> Phone: 859.816.7955 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] opera doesn't play nice with Opacity
On 13 Nov 2007, at 14:52, Navjot Pawera wrote: On 13-Nov-07, at 1:26 PM, Tee G. Peng wrote: James, I have no idea whether Opera uses Qt4 or 3 but it may filter through in time to a new Opera release (try Opera 9.5 beta - it may have it already). I have 9.5 Alpha Beta. Do you know if Opera is quick to bug fix? If not, I don't want to bother to report the bug. :-) I just checked the thread and saw this discussion. It would a big help if you could file that bug (as you've already been playing around with it - you'd probably will be able to explain it better). You can be assured that we'll do our best to get this rectified in the newer builds as soon as possible (if it is a valid bug of- course - I haven't really been able to check the bug yet). Navjot, Can you bug it, then we can follow up on it as needed. It seems like an edge case as opacity works in most situations I've seen it used in, unless there is some part of the spec we follow, that others don't. Tee G. Peng In this sites case, if I'm looking at the correct area, the background behind the element is a plain chocolate brown colour. I'd recommend just using a solid colour of the same colour as you expect to get with opacity. It will look the same, as there is no background pattern showing through anyway, more compatible, and will be more efficient as opacity/alpha channels will always be more processor intensive. Opera doesn't support it yet, but RGBA might also be better as your text colours are not going to be effected. White text can often become a strange colour using opacity for example. if I use RGBA/HSLA in examples, I often use a RGB colour first (as a fallback) and apply a RGBA/HSLA colour after for those browsers that support it. Thanks a lot for the help guys ! Cheers ! -- Navjot Pawera Web Evangelist - Open the Web Opera Software ASA *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mobiles and standards
At least for the top mobile browsers such as Nokia S60, the Safari version for iPhone and Opera's mobile browsers, they can cope with full HTML and XHTML and CSS, so they can handle the regular desktop site. Some render the page in desktop mode, and some reformat the page to fit in one column. Opera mobile can do both. This solution can give quite good results. If you want to optimise the site then you can use handheld stylesheets and/or CSS Media Queries. Unfortunately it doesn't seem like Nokia or Apple will be supporting handheld, but they will most likely support Media Queries (they are included in the latest WebKit builds). Opera Mobile supports both and Opera Mini will fully support handheld stylesheets in Opera Mini 4 (and Media Queries I believe). Using media queries to give a different stylesheet to devices under a certain resolution will work well except in less modern mobile browsers that are still WAP based or have poor standards support. These should be marginalised as carriers and handset makers look for better browsers to include in their phones after seeing what full html browsers can do. Opera is certainly seeing this, with having deals in place with many major handset makers like SonyEriksson, Nokia, Palm, HTC, Samsung, Motorla, Toshiba etc and Carriers such as T-Mobile, Telefonica (number 1 in Spain), TMN (number 1 in Portugal) shipping Opera Mobile (smartphones) or Opera Mini (any phone with Java) and more announcements in the pipeline. The other browser makers with poor standards support will have to improve their products, especially if sites take advantage of the more interesting technologies such as Media Queries. The third option is to make a mobile specific site, which is often done in XHTML Basic or Mobile Profile (be careful here as a well formness error in XML will likely make the page not render at all). This is often the best option if you either have a very heavy regular site that will be difficult to navigate on mobile and take a lot of bandwidth and time to download (Kb often equals money for many mobile web users), or you want to give mobile specific content that fits the context of using a mobile. The down side to this approach is that you will have two sites to maintain instead of one, while with media queries or handheld style you only have one extra stylesheet, so this approach should only be taken if you need to and have the resources. This kind of site will work better on older style mobile browsers however. One of the biggest issues with mobile web design is actually the fonts. Many phones, especially feature phones are limited to one font in limited sizes and no italic fontface. This can make Opera Mini 3 look different one one phone than it does on another, so don't expect pixel perfect layouts. David On 31 May 2007, at 12:02, Nick Cowie wrote: Hi Katrina I have not done enough research on this, but: If I creating a site that I expected mobile browsers to visit (ie every site I create from now) I would use XHTML 1.0 transitional DTD, mime type of text/html and restrict my XHTML to the XHTML-MP subset and my CSS to the WCSS subset If I was building a mobile only site (and I have not done that yet), I would have to be convinced of the advantages of moving to a XHTML-MP dtd and associated mime type. In other words XHTML 1.0 transitional works with most browsers, computer or mobile based. I have done no research of redirecting mobile users to a different URL, .Apparently the WP-PDA plugin http://imthi.com/wp-pda does this and works with the major mobile browsers, so time to play with it. Nick -- Nick Cowie http://nickcowie.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** 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
This should not happen with Opera browsers (Opera Mini and Opera Mobile). We specifically ask Google and other search engines not to give us transcoded results when our users search using their search engines. If they do then it is a bug and we want to know about it so we can ask them to correct this behaviour. For styling the page handheld stylesheets should be used. For JavaScript issues I don't know of a way to specifically detect if it is a handheld, and browser sniffing is far from ideal on mobile due to many reasons. Tim do you have a specific example of what issues are being caused, then I can look into them? Also which browsers are you testing on. Some mobile browsers have very poor JavaScript support. Browsers such as Opera Mobile have full JavaScript support. Opera mini is slightly more restricted in that it uses a client server architecture, so there is no AJAX, but by developing using progressive enhancement it should work, depending on how complex the site is you are trying to develop. On 1 Mar 2007, at 12:30, Tim wrote: Barney, some mobile phone opimisation search engine versions for phones DO remove meta tags on the fly. My meta tag base href were taken out of pages by ask.com the mobile version http://m.ask.com/ This allowed them to run my site by relative URLs on their server with fake paypal links en all. They do remove meta tags Barney in at least some mobile search engines. Google mobile disables form, http://m.ask.com/ does not. Tim On 01/03/2007, at 9:42 PM, Barney Carroll wrote: Tim wrote: Will major search engines for phones take any notice of javascript? Google http://www.google.com/xhtml/ Ask http://m.ask.com/ Tim, why would this be a problem? Google isn't a handheld device, it's a search engine. It doesn't matter what /it/ thinks. And if you're afraid it messes with pages it links to, that isn't the case. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** The Editor Heretic Press http://www.hereticpress.com Email [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******* David Storey Chief Web Opener Opera Software Oslo, Norway W: http://my.opera.com/dstorey ✉ : [EMAIL PROTECTED] ✆ : +47 24 16 42 26 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
