Re: [WSG] advice on background images?

2010-11-26 Thread David Storey
 
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?

2010-11-10 Thread David Storey
 
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 thierry.koble...@gmail.com 
 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 !DOCTYPE, etc?
 
 I'd go with !DOCTYPE html 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

2010-10-03 Thread David Storey


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

2010-09-05 Thread David Storey


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

2010-08-23 Thread David Storey


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

2010-08-19 Thread David Storey


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 section and article elements then you  
can use just h1 everywhere:


section
 h1Monday/h1
 article
   h1First post/h1
   p...
 /article
 article
   h1Second post/h1
   p...
 /article
/section
section
 h1Tuesday/h1
 article
   h1First 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 h1 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, h 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] Getting my feet wet in HTML5

2010-08-19 Thread David Storey


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 h1 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] Yes or No? HTML5 FOR WEB DESIGNERS

2010-08-18 Thread David Storey


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 !doctype html 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 caption 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

2010-08-18 Thread David Storey


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 hgroup . I did find sources which approve of  
a p being used inside the hgroup. 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 weblis...@gmail.com 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 !doctype html 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 caption 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 / SVG Interest Group

Opera Software ASA

Re: [WSG] Yes or No? HTML5 FOR WEB DESIGNERS

2010-08-17 Thread David Storey


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 ::

2010-08-06 Thread David Storey


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] @media ordering in stylesheet

2010-08-05 Thread David Storey


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
***



Re: [WSG] :: opera mini 5.1 ::

2010-08-05 Thread David Storey


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?

aside
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...
/aside

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] :: opera mini 5.1 ::

2010-08-05 Thread David Storey


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 32 / E-Mail/XMPP: dsto...@opera.com / Twitter:  
dstorey

Re: [WSG] :: opera mini 5.1 ::

2010-08-05 Thread David Storey


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+% usage (based from many stats of the  
sites I did)


Depends which market you

[WSG] Opera Dragonfly survey

2010-06-01 Thread David Storey

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

2009-08-05 Thread David Storey


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

2009-01-20 Thread David Storey
 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, olafbuddenha...@gmx.net 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 IMG 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?

2009-01-17 Thread David Storey
 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

2008-10-23 Thread David Storey


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:
  param name=wmode value=opaque /


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?

2008-10-02 Thread David Storey
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

2008-09-27 Thread David Storey
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: wsg@webstandardsgroup.org
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...

2008-09-07 Thread David Storey


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...

2008-09-06 Thread David Storey


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: wsg@webstandardsgroup.org
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...

2008-09-03 Thread David Storey


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] Google chrome... Coming very soon...

2008-09-03 Thread David Storey


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...

2008-09-03 Thread David Storey


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] Code for Firefox, hack for IE

2008-09-01 Thread David Storey
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] Re: ARIA

2008-08-12 Thread David Storey


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] ARIA

2008-08-12 Thread David Storey


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  
span 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

2008-08-11 Thread David Storey


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:

  ?xml version=1.0?
  !DOCTYPE html PUBLIC -//W3C//DTD XHTML+ARIA 1.0//EN
http://www.w3.org/MarkUp/DTD/xhtml-aria-1.dtd 


  html xmlns=http://www.w3.org/1999/xhtml;
xml:lang=en
  ...
  /html


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

2008-08-11 Thread David Storey


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

2008-08-10 Thread David Storey


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

2008-07-22 Thread David Storey
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] iphone should not be part of your url

2008-07-21 Thread David Storey


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] Mobile graded browser support

2008-07-21 Thread David Storey


***
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

2008-07-20 Thread David Storey
, 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?

2008-05-12 Thread David Storey


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

2008-05-06 Thread David Storey

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] Opera files antitrust against MS: standards one part

2007-12-14 Thread David Storey
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

2007-11-27 Thread David Storey
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

2007-11-13 Thread David Storey


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

2007-06-04 Thread David Storey
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

2007-03-01 Thread David Storey
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]
***