Opera News

<chrismills> q+
<chrismills> q?
<vladko13> Not yet
<chrismills> just checking to see if I could use questions ;-)
<pedralm> go!
<chrismills> so, I first wanted to talk about the terminology a bit
<chrismills> as people get hung up on this
<chrismills> slides 6-8 give you some definitions
<magic> +
<chrismills> I basically want to say that it doesn't matter whether you term this stuff responsive or adaptive
<chrismills> As long as you do cool stuff that makes you users happy on mobile phone, tablet, etc.
<chrismills> I have seen religious wars about which term to use when, but it is a waste of oxygen
<chrismills> magic ?
<pedralm> it does bring different meanings if taken litereally
<pedralm> literally
<chrismills> I know. But usually it doesn't really matter
<pedralm> indeed
<magic> everythink ok
<chrismills> next, let's go on to slide 10
<chrismills> three options for creating tailored displays for different devices
<chrismills> I'll go through them form worst to best (this is my opinion, of course, but others share it too)
<chrismills> slide 11
<chrismills> creating a completely separate mobile site is an option
<chrismills> but it is usually a bad one
<pedralm> could be a point 4 there: create separate app
* LarsKL has changed the topic to: Agenda: http://pastebin.com/XwzZDRY2 :: Use http://pastebin.com/ for pasting long texts
<chrismills> yes, you can draw your data out of the same DB
<chrismills> pedralm cool - we'll talk about that after these 3
<chrismills> remind me
<pedralm>
<chrismills> but it is generally a pain to have to create multiple front ends for different devices
<chrismills> it means maintaining multiple codebases, which is a lot more work
<chrismills> and generally it relies on browser sniffing
<pedralm> yet some might say it is more adaptive
<pedralm> but please continue
<chrismills> to serve the correct front end to the correct device
<chrismills> and browser sniffing is often error prone
<chrismills> and a bit of a mess
<pedralm> as an Opera user, I totally relate
<pedralm> pun intended
<tango_> it's the reason why opera is 9.80, lol
<chrismills> ;-)
<chrismills> yup, exactly
<chrismills> for those of you who don't know
<chrismills> the reason Opera versions above 9.x have version 9.8 in the user agent string
<pedralm> Opera will do "device sniffing" now for the Agent
<chrismills> is because there is so much crappy browsing sniffing code out there that erroneously detects Opera 10+ as Opera 1
<chrismills> that we changed it to 9.8 to stop a load of sites breaking
<klaude> haha
<chrismills> There are situations in which it is better to create a separate site
<tango_> of course now all browsers have versions > 10, so hopefully the stupid browser sniffing code is fixing
<pedralm> IE just got there
<pedralm> so...
<chrismills> If you are the poor sod of a web developer who has inherited baby sitting duties for a huge enterprise legacy site
<chrismills> it is often better to create a separate mobile site
<pedralm> "poor sod" is so british
<chrismills> the cost of bolting on responsiveness to such a site is often a lot higher than just building the site from scratch
* LarsKL wonders when Chrome will go >100
<chrismills> pedralm verily, old chap
<chrismills> LarsKL not until next year ;-)
<tango_> LarsKL: by the end of the year, at this rate
<makoto> hahaha
<chrismills> Jakob nielsen reckons that a separate mobile site is always the best way to go
<pedralm> what year did he say that
<chrismills> but then again, his site looks like this: http://www.useit.com/
<pedralm> 2010?
<chrismills> he said it last year, I think
<tm> hahhaaa
<aleksander> Whenever JN talks about the web I just think, probably best to do the opposite. I love DOET and his general books, but he failed at the web a long time ago
<pedralm> before the advent of the ipad and the proliferation of high speed mobile, I'd second that
<aleksander> Personal oppinion!
<chrismills> aleksander: ;-)
<chrismills> So, any questions about this?
<chrismills> tick tick tick...
<pedralm> go
<chrismills> ok ;-)
<chrismills> Second option is to do nothing
<pedralm> "bloke" is also very british
<chrismills> except use web standards and best practices
<chrismills> because so many sites are built non-responsively
<chrismills> mobile browsers have mechanisms to improve rendering of those sites
<chrismills> when you load a non-responsive site in a mobile browser, it tends to render it at an assumed width of about 980px
<chrismills> then shrink the result down to fit the screen
<chrismills> Rather than rendering the site at the mobile's real viewport width
<chrismills> cos at that width, a lot of sites would look really crap ;-)
<chrismills> but of course, the is not good enough for a lot of people, and why should it be?
<chrismills> slide 13
<chrismills> unlucky for some
<chrismills> adapting a single front end
<chrismills> is often the best way to go
<pedralm> could you speak about the "adaptation" of the site owners regarding ad placement when building responsive/adaptive sites?
<pedralm> because ad-payers might care what will be done then
<chrismills> we'll go on to responsive technologies in a little while
<pedralm> that'd be more business than technical, though
<chrismills> pedralm - do you want to say a couple of words about what you mean by separate apps?
<chrismills> I am happy to talk abut responsive ads after that
<pedralm> well there are studies that compare what is the way to go for mobile businesses
<pedralm> or business that have highest user count in mobile platforms
<chrismills> ah ha
<pedralm> and it shows that users are more likely to return to apps than to sites
<chrismills> ah, i see
<chrismills> well, it depends on the kinds of thing you are doing with your app
<pedralm> sites bring more revenue, but apps bring more users
<chrismills> it is perfectly possible to build an app with web technologies, and just have the mobile app as one layout of the adaptive site
<chrismills> ok, you might want to serve it slightly differently
<pedralm> lately there was a lot of hate towards HTML5 from Zuckerberg
<pedralm> regarding FB app
<chrismills> have it as a installed app rather than we page
<chrismills> web*
<chrismills> but that is possible
<pedralm> indeed
<chrismills> it is a shame Opera widgets didn't catch on more, as they are ideal for that kind of use
<pedralm> yes, that is right
<GODJonez> random note: I stopped using Facebook app on Android and am using the full website (not mobile site) with the phone browser
<QuHno> which widgets? SCNR
<pedralm> but paradoxally (is this a word), apps are more responsive than the responsive web
<chrismills> I think you've got to be careful, as a lot of HTML5 features do take a lot of bandwidth, which is bad for a lot of phones
<pedralm> I'm sure where we're going also relates to that
<klaude> chrismills: could you give an example of such HTML5 features?
<pedralm> not only form factor, but also features need adaptation
<chrismills> the mobile web apps thing is also why a lot of developers get confused and starting thinking WEbKit IS the mobile web, and locking out other browsers
<chrismills> but I'm not gonna get into that rant to day ;-)
<chrismills> today*
<chrismills> klaude: things like canvas/webGL and HTML5 video
<pedralm> and they spoke against flash, pffff
<chrismills> can start to run really slowly on mobile devices
<QuHno> If I use "flash" otr HTML5 video is almost the same when it comes to bandwidth.
<chrismills> so you've gotta be careful what kind of stuff you offer mobile users
<QuHno> and canvas is evil in kind of accessibility if you don't provide a load of extraneous content to make it accessible for those who can not run it for various reasons.
<chrismills> And one vital tip - if you do offer a specialised mobile layout/separate site, make sure you offer a link to the full desktop version
<QuHno> s/kind/terms/
<chrismills> so users can choose if they want the desktop version
<chrismills> Anyway, a little bit about responsive ads
<pedralm> yes, thank you
<pedralm> i'm not pro ads, but they do feed the web
<chrismills> This is a very big deal - pedralm is right, that RWD is getting hostility from ad buyers
<chrismills> If a guy has paid for a 733 x 200 add, he wants a 733 x 200 add all the time!
<chrismills> you can see the problem here
<pedralm> precisely
<chrismills> With the advent of RWD, we need a slightly different selling model for web ads
<chrismills> and I'm not sure if we have a solution in place yet
<chrismills> mark boulton wrote about this a while ago
<chrismills> and I have some examples in my book about it (http://www.amazon.co.uk/Practical-CSS3-Develop-Design/dp/0321823729 > please buy!)
<chrismills> http://www.markboulton.co.uk/journal/responsive-advertising
<QuHno> % of viewport? % of visible content above the fold?
<chrismills> here's mark's article. Have a read when you get the chance
<pedralm> (thank you)
<chrismills> you'd need to sell ads as minimum percentage, imo
<chrismills> because you often can't guarantee an exact percentage
<chrismills> especially when dealing with liquid layouts
<pedralm> ad cluttering in small formats might turn the site un-re-visitable
<chrismills> too true
<chrismills> one moment - I'm just trying to find an example for you
<pedralm> sure
<chrismills> I created a responsive banner ad as part of my book examples ;-)
<chrismills> because I know how much web designers love banner ads ;-)
<pedralm> they should as much as they love the site itself
<chrismills> http://people.opera.com/cmills/css3poster/poster3.html
<klaude> 90% of as, 3% of menu, 2% for marigns and 5% of content
<chrismills> might not work in firefox as I'm missing an .htaccess file
<chrismills> well, the video portion might not load
<pedralm> nobody's using firefox here
<pedralm> i readjusted the window size to cut out the video. it worked
<chrismills> this uses real banner ad sizes, taken form the IAB (internet advertising bureau)
<chrismills> from*
<chrismills> So it is doable, but we need some kind of different business model
<pedralm> this is an ad? it's terrible
<chrismills> it's awesome if you like heavy metal ;-)
<pedralm> the ad, not the band!
<chrismills> ANYHOW, let;s move on, as we are running out of time
<pedralm> sure, sorry
<pedralm> tks for the article
<pedralm> continue, please
<chrismills> so, slide 15 of my slide deck
<chrismills> I'll just run through these quickly
<chrismills> liquid layouts are one of the staple tools of RWD
<chrismills> setting containers as percentages so they get smaller as the window width decreases
<chrismills> but of course, liquid layouts can start to look terrible at lour widths
<chrismills> lower*
<chrismills> So enter media queries
<chrismills> slide 21
<chrismills> woo hoo ;-)
<pedralm> feil0ng: no, it "stopped responding"
<chrismills> Is anyone here not familiar with the basic syntax?
<pedralm> don't you read Apple's genius manuals?
<feil0ng> pedralm: pardon
<chrismills> @media screen and (max-width: 480px) { }
<Coyotee> slide 23
<chrismills> inside these blocks, you can inset CSS rules that are only parsed when the media query returns true
<chrismills> in this case, when the media type is screen, and the screen width is 480px or less
<pedralm> speed dial extensions have something similar i think
<chrismills> yup, that's right
<chrismills> that idea is based off media queries
<pedralm> cool
<chrismills> so you might have a two column layout on a wide screen
<chrismills> but then inside a media, have rules to turn that into a one column layout
<pedralm> tough luck to the ad-column
<chrismills> http://www.slideshare.net/chrisdavidmills/adapt-media-queries-and-viewport
<chrismills> all the basics are in there
<chrismills> oops, wrong URL
<Coyotee> i like rules
<Coyotee> rules rule
<pedralm> and ruling rules rule
<chrismills> http://dev.opera.com/articles/view/love-your-devices-adaptive-web-design-with-media-queries-viewport-and-more/
<chrismills> here it is
<chrismills> So for example: http://people.opera.com/cmills/mediaquery/
<chrismills> check this out, and don't mind the psychedelic styling. This is the kind of "design" i like ;-)
<QuHno> "monochrome" backfires on some Kindles so might other on other devices where the vendors report false values.
<chrismills> at a lower width, we have this single column thing going on
<pedralm> you've got issues with chameleons
<pedralm> and the lizard folk
<chrismills> QuHno: I've never used monochrome ;-)
<QuHno> neither me, but it would
<chrismills> pedralm: well yeah. Everyone's got their fetishes ;-)
<chrismills> slide 25 now
<chrismills> you can do AND and OR, etc. in media queries
<chrismills> slide 25 shows AND - adding extra conditions that need to be passed before the media query code will execute
<chrismills> slide 26 shows OR
<pedralm> are media queries reloaded on device rotation?
<chrismills> to do OR, you separate the different queries with commas
<chrismills> pedralm: no
<chrismills> but they do kick in when rotating a device make one of them pass that didn't before
<pedralm> ah, well, that answers my question
<chrismills> they like event handlers really
<chrismills> they sit there waiting for conditions to change so they are true, if they are no already true
<chrismills> not*
<chrismills> and then the CSS is applied
<pedralm> great
<chrismills> slide 27-28 - NOT and ONLY
<chrismills> so you can also say "apply this media query to anything but situation where that media query is true
<chrismills> or you say say ONLY apply it to that media query
<chrismills> Moving on...
<chrismills> Slide 30
<wheder> whats the difference between "only screen" and just "screen"?
<chrismills> wheder: I really am not sure ;-)
<chrismills> I've never used ONLY
<chrismills> but it is there
<wheder> ok :-) go on
<klaude> uhm
<pedralm> good for when the ipod nano has a browser
<pedralm> *get a
<chrismills> ;-)
<chrismills> I'd be interested in a good answer to that question.
<pedralm> some slides back you said that "everything is a screen"
<chrismills> All tutorials I've ever seen just kind of gloss over the "ONLY" thing
<chrismills> not everything - but mobile, tv and screen are really all screen
<Remco> wheder: "User agents must process media queries starting with only as if the only keyword was not present." <= used to hide media queries from older browsers it seems
<chrismills> just with different sizes and resolutions
<klaude> chrismills: maybe print?
<wheder> Remco: thanks
<pedralm> that would be a no-screen
<Remco> (that's from the spec btw)
<chrismills> which is why media types were fail-tastic
<chrismills> Remco thanks!
<Remco> Np
<chrismills> So, Slide 30 - breakpoints
<chrismills> a breakpoint is the width, or whatever other media feature value you are using in a media query that the styling will change at
<chrismills> as we shall see later, there are other things you can use inside a media query, such as resolution
<chrismills> but we'll leave those till later
<chrismills> There are two ways to tackle breakpoints - content or device breakpoints
<chrismills> content breakpoint - use a media query to change staying at the point where the layout actually breaks, e.g. when you h1 starts to wrap untidily, or your main content column starts to look really lame
<chrismills> device breakpoint - change layouts for specific device sizes, e.g. iPhone, ioPad, etc.
<chrismills> iPad*
<chrismills> I tend to always use the first one, as I really don't care about iPads and other specific iDevices
<chrismills> but I can see why you might want to care about the second one
<chrismills> as often you'll have a client that says yeah, I want a specific web app for the iPhone and iPad
<pedralm> i am a no-carer for the tablet for factor
<pedralm> form
<chrismills> especially in the US and Western Europe
<pedralm> web app or web site?
<pedralm> or a web app which is nothing but a web site in an app?
<chrismills> But really it is better to just care about where the content actually breaks
<chrismills> pedralm: I don't see that it matters in this discussion
<pedralm> do you have an example for that?
<chrismills> pedralm: what, for device breakpoints in action?
<pedralm> yes
<chrismills> I can't find one right now
<chrismills> sorry
<pedralm> that's alright
<chrismills> I thought Andy Clarke's web site would be a good example, but he's gone and changed it!
<chrismills> Of course, there is another approach - a hybrid approach
<chrismills> you could have a specific set of media queries say for iPad and iPhone sizes, but then above and below those, use the content breakpoint methodology as appropriate
<chrismills> often you can ale your iPhone and iPad media queries so they will work for larger and smaller sizes anyway
<pedralm> I would've thought media queries to be feasible in all scenarios
<chrismills> yeah, exactly
<chrismills> But there are a lot of religious arguments about device breakpoints
<pedralm> even now where you have 2 iphone sizes and 2 ipad sizes
<chrismills> Zeldman seems to be very in favour of them
<Remco> All scenarios means writing a lot of media queries
<chrismills> I know
<chrismills> it is almost as bad as browser sniffing ;-)
<Remco> Better to pick a few and use something like flexbox to adapt
<pedralm> "targeted" = bad
<chrismills> ;-)
<Remco> o:)
<chrismills> yup, agreed
<chrismills> Really running out of time now, so let's move on
<chrismills> on slide 32 you can see the different media queries available
<chrismills> I have only ever used width, height, device-width, device-height, orientation, resolution, and device-aspect-ratio
<pedralm> when I read orientation I think of "why" if the rest can kick in for effect
<chrismills> there is also a proprietary one called device-pixel-ratio
<pedralm> "proprietary" is also evil
<chrismills> but that basically does the same thing as resolution
<chrismills> as is non standard. Browsers are standardising on resolution
<chrismills> Which takes the unit dppx = dots per pixel
<chrismills> Yup, pixel are actually a relative unit ;-)
<chrismills> pixels*
<chrismills> depending on screen resolution
<pedralm> reminds me of printers
<chrismills> aye
<chrismills> but yes, pedralm is right - orientation is pretty pointless in most situations
<chrismills> you can just use width instead
<chrismills> which is a lot more flexible
<chrismills> so for example, on a 1024 x 768 tablet
<pedralm> yes, one less concern by not using an extra class
<chrismills> you could apply media queries using orientation portrait and landscape
<chrismills> but why not just use width 1024 and width 768 ?
<pedralm> that reads landscape
<chrismills> aye
<pedralm> (768 should read height)
<chrismills> aspect ratio is also a bit pointless for the same reasons
<chrismills> anyhow, moving on
<chrismills> slide 34 - we talked about this earlier
<chrismills> mobile devices render things at a higher viewport width, and then shrink it down to fit in the browser window
<chrismills> this is a pain, as edia queries for those screen sizes will not kick in
<chrismills> media*
<pedralm> that's a device issue, not site issue
<chrismills> to make mobile browsers have themselves, we can use viewport
<chrismills> yeah, but pretty much all smartphone browsers do this
<chrismills> so you need to use viewport to take control
<chrismills> see slide 37
<chrismills> this is the viewport meta tag, which goes in the head of your HTML
<chrismills> this suggests to the browser what viewport width the site should render at
<pedralm> so Apple invented it to deal with their own device problem?
<chrismills> and other things such as how much zoom the user should be able to apply
<chrismills> pretty much ;-)
<pedralm> lame
<chrismills> but then everyone else followed suit
<chrismills> as other browser and devices exhibited the same problem
<chrismills> browsers*
<pedralm> i'm glad the solution was a workaround
<pedralm> and now it's a feature
<chrismills> width=device-width just means "render the site using a viewport width equivalent to the physical width of the device"
<chrismills> pedralm: well, its nice to be able to control the viewport like this
<pedralm> i'm sure _now_ it is
<chrismills> If nothing like this existed, and all sites just rendered at the width of the physical device, users would probably be worse off
<chrismills> Slide 39
<zurchpet> do only mobile browser evaluate and follow those meta tags or do desktop browsers do that too?
<chrismills> this is just mobile browsers
<chrismills> desktop browser ignore them
<QuHno> Safari on retina displays on mac books doesn't do it?
<chrismills> it's basically browsers that have a fixed full screen browser window
<chrismills> anyway, slide 39 shows that you can also set a number of pixels to render at, rather than device-width
<chrismills> useful for when you have a fixed column of content
<chrismills> and on narrower windows you want to have it fill up the full screen
<chrismills> the other viewport options are shown on page 41
<chrismills> you'll not use many of these except width
<chrismills> the ones that control zooming are evil, imo, as zoom is an important a11y feature
<chrismills> user-scalable=no is a terrible thing to do to your users - turns of zoom altogether!
<chrismills> One question that a lot of people have asked is - why the hell is this an HMTL feature, rather than a CSS feature
<chrismills> HTML*
<chrismills> well, yes - it is much more of a CSS type thing really
<LarsKL> chrismills: with android webkit browser the zoom factor is different with user-scalable=no set or not. any idea why?
<chrismills> so some people at opera created the CSS device adaptation spec - which is viewport, but redefined in CSS
<chrismills> see slide 42
<pedralm> had to be Opera
<chrismills> LarsKL - that is weird
<chrismills> It really shouldn't be
<pedralm> maybe it sets it to a default value
<pedralm> for readability
<chrismills> you've just got user-scalable=no set, nothing else inside the viewport?
<LarsKL> or was it chrome?
<LarsKL> had a major issue working around that
<chrismills> well, if it's Chrome, then I don't care ;-)
<zurchpet> chrismills: is Device Adaptation part of CSS3?
<zurchpet> or just prorietary yet?
<chrismills> zurchpet: yes, it's a module inside CSS3
<chrismills> it's an official working draft
<zurchpet> nice
<chrismills> oh, wait
<chrismills> http://dev.w3.org/csswg/css-device-adapt/
<chrismills> It's an editor's draft
<chrismills> So not quite there yet
<chrismills> But close
<zurchpet> IC
<chrismills> moving on to slide 46 now
<LarsKL> Chrome for Android completly ignores user-scalable=no btw
<chrismills> responsiveness of replaced elements
<chrismills> LarsKL - ah, interesting.
<chrismills> that's probably a good thing
<chrismills> the major issue with RWD is responsiveness of images and video
<chrismills> because stuff like text and SVG are small in file size and infinitely scalable (in theory)
* tango_ disagrees 8-D
<tango_> but I understand what you mean
<chrismills> whereas images and video are large
<chrismills> and not infinitely scalable - they start to look horrible really quickly
<chrismills> if you go to slide 47, you'll see the code for making an image or video stay inside it's container
<chrismills> great when you've got an image or video inside a liquid column
<chrismills> slide 46 shows what the problem is if you don't set this
<chrismills> One problem with this is that old versions of IE don't support max-width, at least not reliably
<chrismills> so you'll have to fallback to width: 100% for them instead
<chrismills> which can be dangerous
<chrismills> don't set that on all your images ;-)
<pedralm> ideally the server would be responsive too and just return "adapted" images
<chrismills> that is one way around it, yes
<chrismills> and probably the best one we have right now for response <img>s
<chrismills> which is annoying as it is really a client side problem
<chrismills> of course, here I am talking about file sizes, not just image sizes on the screen
<chrismills> you don't want to serve mobile devices a massive image that they don't need, as they are likely to be on a small screen
<chrismills> and low bandwidth
<pedralm> very true
<chrismills> slide 50 -
<chrismills> for css background images you can use "mobile first"
<chrismills> which means having the default layout as the mobile layout, and then having rules for wider and wider layouts in the media queries
<chrismills> rather than the other way around, which is having the desktop layout as the defat, and then going narrower and narrower
<chrismills> this is how we all started doing it
<chrismills> mobile first is great, because you can serve small images for the mobile layout by default
<chrismills> and then only have the larger images loaded by wider screen browsers that need them
<chrismills> If you did it the conventional way round
<pedralm> but they are downloaded nonetheless?
<chrismills> all browsers would load both sets of images
<chrismills> no, they're not
<pedralm> ok
<chrismills> I tested this while I was writing my book ;-)
<pedralm> as long as it's true for Opera
<pedralm> though Turbo already helps there
<chrismills> the only problem with mobile first is that older browsers like IE 6-8 don't support media queries
<chrismills> and it is not much good serving those browsers the mobile layout
<chrismills> regardless of how much you hate them ;-)
<pedralm> but if we're working in the breakpoint limit
<chrismills> so in this situation, you can polyfill to give those browsers media query support
<pedralm> won't the rotation cause a re-download?
<chrismills> yes, if the new CSs that is applied contains new background image declarations
<pedralm> is the memory flushed or further rotations are secured?
<pedralm> well that is browser dependant
<chrismills> a good polyfill for making older versions of IE support media queries is respond.js - look it up on github
<chrismills> pedralm: not sure
<chrismills> Anyhow guys
<wheder> pedralm: i guess it will depend on headers like Expire ...
<chrismills> We have gone up to 15:30 UK time, half an hour over when I said I'd go on to
<chrismills> and I've not covered anywhere near as much as I wanted to ;-)
<zurchpet> hehe
<chrismills> it takes a lot longer to explain stuff in IRC ;-)
<chrismills> I am happy to stick around for a bit longer to answer some questions from the masses ;-)
<pedralm> (speaking of IRC, put a word up to pump it in next Opera releases)
<chrismills> what would you most like me to cover?
<chrismills> pedralm: I am so annoying that IRC got removed form MAc Opera
<chrismills> annoyed*
<aleksander> chrismills: we'll make this chat available on Choose Opera, perhaps you could follow up a bit in the comments?
<chrismills> ok
<chrismills> Also, give them link to my presentations on the subject
<Ramunas> any plans to do this more often?
<chrismills> http://www.slideshare.net/chrisdavidmills/adapt-media-queries-and-viewport
<chrismills> http://www.slideshare.net/chrisdavidmills/adapt-and-respond-keeping-responsive-into-the-future
<pedralm> I am seeing here points about processing power drained from gradients and shadows and such
<pedralm> you have numbers on this?
<chrismills> not exact numbers, no, but I can find out ;-)
<pedralm> it's curious
<chrismills> Ramunas: if it is useful to people, then yes
<chrismills> Was this useful?
<QuHno> too short
<chrismills> I think in future we probably need to drill down into smaller more niche topics
<zurchpet> chrismills: yes, useful, and too short
<Remco> I'd say the speed was a bit slow
<pedralm> short short
<pedralm> but time is always short when the people are good
<chrismills> Rather than trying to cover the whole of responsive design in one session ;-)
<zurchpet> yes
<Remco> Perhaps the best way would be to have a twitch.tv/own3d.tv channel and talk
<pedralm> sorry if I tackled too much
<Remco> And then have IRC for questions etc.
<chrismills> So I will definitely do this again
<chrismills> But I will work on doing it a different way
<chrismills> IRC is a bit slow for the communication
<pedralm> maybe we should have like in "real" presentations a time for Q&A
<zurchpet> chrismills: be sure to invite
<pedralm> between ever so slides
<chrismills> so some kind of TV or voice channel for you to listen to would be great
<Remco> TV would be best, so you can have the slides up
<pedralm> please dont suggest Hangouts!
<chrismills> I'll also ask Anna/Aleksander to work out some way of allowing you to send in topic suggestions.
<pedralm> G+ doesnt work in my opera at work
<chrismills> We did try it as an optionit sucked major donkey balls ;-)
<chrismills> (that's a technical term...)
<pedralm> that's a disgusting technical term
<chrismills> I'm sorry ;-)
<chrismills> But it was so apt
<pedralm>
<pedralm> i'm glad IRC was considered
<pedralm> and eventually opted
<chrismills> I love IRC
<chrismills> but it's just a bit slow
<pedralm> the single reason i still use IRC is because Opera has it
<chrismills> for this kind of thing
<pedralm> even though it's a very basic one
<chrismills> Other things I was hoping to talk about today, but didn't
<pedralm> put another word up for IRC and Mail extensions
<chrismills> Flexbox - read this - http://dev.opera.com/articles/view/flexbox-basics. We'll cover it some other time
<aleksander> chrismills: yes, we'll find a way
<pedralm> dot in url
<chrismills> Animations - http://dev.opera.com/articles/view/css3-animations/
<aleksander> That's it folks! Thanks to chrismills for hosting and everyone else for showing up!
<chrismills> we'll cover that another time as well