Day 1: HTML Special
|08:15||Doors open||breakfast, coffee & registration|
|16:00||Peter van der Zee|
|17:40||Party||drinks & discussions|
Day 2: CSS Day
|08:30||Doors open||breakfast, coffee & registration|
|09:00||Harry Roberts||CSS for Engineers and Devs|
|09:50||Léonie Watson||CSS and Accessibility|
|11:10||Vasilis van Gemert||Mediaqueryless Responsiveness|
|12:00||Mark Robbins||CSS and Email|
|13:50||Amelia Bellamy-Royds||CSS and SVG|
|14:40||Chris Lilley||CSS4 Color|
|16:50||Una Kravets||Blend Modes|
|17:40||Party||drinks & discussions|
HTML Special, Thursday June 16th
A healthy serving of mixed HTML salad, with a side order of tag soup.
Your MC: Ruben Bos
Ruben Bos registered his first dot.com when he was 12 years old, and he has been obsessed with the web ever since. Former Creative Director at Mangrove, he recently made the big leap from agency work to teaching students at the Rotterdam University of Applied Sciences. With his own practice he keeps advising companies how to create the best digital UX. Clients he worked for range from start-ups to international organizations like the ICRC. Ruben regularly writes about UX design, web & app development and client work. In 2007 he published a book about webdesign aimed at clients of digital agencies. He has been a speaker at events like Appsterdam, Fronteers and SXSW interactive.
<input>, I <3 you but you're bringing me down
Browsers have had an
<input> element since the dawn of time, and yet any time you talk to web developers about it, everyone complains about it. It's unpredictable. It's grumpy. It's got reaaaaally strong opinions about style, and it doesn't want to listen to yours. I'm going to tell you a story about how
<input> grew up to be the moody adult it is, and why it's maybe time we stood up to it.
Monica is an emojineer at Google. She works on Chrome, web components and Polymer, and has probably at least once broken the Internet for you. She is unreasonably excited about emoji, and will likely eat all of your Oreos, if you have any.
<a> — Vague but exciting
The world exploded into a whirling network of kinships, where everything pointed to everything else, everything explained everything else…
Enquire within upon everything.
Jeremy Keith lives in Brighton, England where he makes websites with the splendid design agency Clearleft. You may know him from such books as DOM Scripting, Bulletproof Ajax, and HTML5 For Web Designers: Return Of The Standards. He’s the curator of the Responsive Day Out conference, and he organised the world’s first Science Hack Day. He also made the website Huffduffer to allow people to make podcasts of found sounds—it’s like Instapaper for audio files. Jeremy spends most of his time goofing off on the internet, documenting his time-wasting on adactio.com, where he has been writing for over ten years.
Do you remember
<layer>? If you do, you also remember Netscape 4, and probably not fondly. And if you remember Netscape 4 you also remember most of web history, as I do.
What is browsers' game? Why all the incompatibilities? And what about browser detects vs feature detects? We all know the second is superior to the first, but sometimes it just doesn't work.
In this session PPK is going to give a broad, historical overview of where we were, where we are, where we're going to, and why.
Peter-Paul Koch is a mobile platform strategist, browser researcher, consultant, and trainer in Amsterdam, the Netherlands. He specialises in the mobile web, and especially mobile browser research. On the Web he’s universally known as ppk. He won international renown with his browser compatibility research, founded Fronteers, the Dutch association of front-end professionals, and advises mobile and desktop browser vendors on their implementation of Web standards. Meanwhile he concentrates on the mobile web, and then especially on the aspects he feels web developers are ignoring, such as the UC browser and Xiaomi and Micromax devices. His personal collection consists of about 50 mobile phones, and he uses about half of them in his daily testing. Occasionally one of them emits a soft, melancholy beep, but he has no idea which one and studiously ignores it.
HTML is special. Unlike many other languages the browser won’t show an error message when you make a mistake. Sure, that makes it easy to write bad code, but it also allows HTML to be both backwards and future compatible. It allowed the HTML5 specification to extend the existing form field types. It allowed the RICG to create the
<picture> element. And it forms the basis of Web Components because it makes custom elements possible. And most importantly, it allows the
<noscript> tag, which by definition does absolutely nothing. This talk will explain the concepts behind graceful degradation, progressive enhancement and feature detection, and focus on how to solve practical problems with these concepts.
Niels is a self-professed browser geek. He has been hooked on browsers ever since somebody showed him the original Nexus browser on a NeXT Cube back in the dark ages of the internet. Niels is the creator of HTML5test.com and runs one of the largest Open Device Labs in the world. He loves procrastinating, collecting weird devices with even stranger browsers, procrastinating, researching obscure browsers and writing bug reports. For his day job he creates web applications for Salonhub.
<picture> elements can all contain
<source> elements. Should be straight-forward, you think? This little element may have more to tell than you think. What is the history? What were the design mistakes for
<video> that we didn't want to repeat for
<picture>? What is the processing model for
<picture>? Why can't you use the media attribute for
<video><source>? Why do double downloads happen? Why do people use conditional comments in their
<picture>s? Why doesn't
<source> with picturefill work on Android 2.3? Why is parsing the
srcset attribute so complex and not just splitting on commas? Just how much can you do with this element? What are the future plans? Why are there so many questions? (Disclaimer: I might not have enough time to cover all of this!)
Simon does quality assurance and Web standards work for Opera since 2007, and is editor of the HTML standard, WebVTT, CSSOM, Quirks Mode... He helped drive the specification for the
picture element in the RICG. He writes and reviews cross-browser test cases in web-platform-tests. His main goal is interoperability; specs and tests are vehicles to that end. He hangs out in #whatwg and tweets at @zcorpan.
Lea is currently busy doing research in Human-Computer Interaction at MIT CSAIL. She has previously written an advanced CSS book for O’Reilly (CSS Secrets) and worked as a Developer Advocate at W3C. She has a long-standing passion for open web standards, and is one of the few Invited Experts in the CSS Working Group. Lea has also started several popular open source projects and web applications, such as Prism, Dabblet and -prefix-free and maintains a technical blog at lea.verou.me. Despite her academic pursuits in Computer Science, Lea is one of the few misfits who love code and design equally.
Parsing HTML in order to load a full Web page is a complex process. On the one hand the browser needs to discover external resources as soon as possible. On the other hand, those same resources can in some cases block the browser's HTML parser, as they may change the eventual result. Over the years browsers have developed mechanisms to cope with that, to make sure resources are discovered even if the parser is blocked.
At the same time, the link element is used to signify a relation between the current page and other resources. It allows us to tell the browser that a certain page should be styled using a certain resource, has an RSS feed alternative, is likely to be followed by another page and much more.
In this talk we'll discuss the connection between these two seemingly separate subjects, and talk about a number of new link relations that enable us to improve the browser's resource discovery process, and get us faster loading Web pages.
Yoav Weiss does not get discouraged easily and is not afraid of code. He is a Web performance and browser internals specialist, especially interested in the intersection between Responsive Web Design and Web performance. He has implemented the various responsive images features in Blink and WebKit as part of the Responsive Images Community Group, and is currently working at Akamai, focused on making the Web platform faster. You can follow his rants on Twitter or take a peek at his latest prototypes on Github. When he's not writing code, he's probably slapping his bass, mowing the lawn in the French country-side or playing board games with the kids.
Hate it or love it, the iframe is one of the most dynamic elements in the current html spec. All the popular websites will contain a few of them as they are used by the advertisement industry. But that's not its only purpose. Iframes have a wide variety of use cases and implementations. From form targets to sandboxes to websites-in-a-website to seamless pseudo-element to parallel processing to unblocked preloading to clickjacking. In my talk we'll dive deeper into what it's like to be an iframe. We'll look at what the spec has to say about them and how they are used in the wild. We'll try to figure out where the tag came from, where it is now, and what makes it so unique.
Peter van der Zee
CSS Day, Friday June 17th
The fourth iteration of our stylish main course.
Your MC: Stephen Hay
Californian by birth and Dutchman by choice, Stephen is a designer, consultant and author of Responsive Design Workflow (New Riders, 2013) and contributing author to Smashing Book #3. He is a frequent speaker at industry events and has written for A List Apart and other industry publications, including his popular-but-sparingly-updated blog The Haystack. While spending an increasing amount of time leading workshops, writing, and speaking, Stephen still spends the majority of his time working with clients large and small through his consultancy, Zero Interface.
CSS and SVG — The Dynamic Duo!
When deciding how to integrate graphical effects in your web design, it's easy to see CSS and SVG as competing options. But these two tools are better together. Static SVG images created by graphics software rarely use CSS, but a little CSS code can transform those SVG files into dynamic, interactive, and responsive graphics.
This session will introduce many of the ways CSS can be used to enhance SVG. It will start by outlining how CSS for SVG is similar and different from CSS for HTML, with some practical tips to avoid common difficulties. Then we will start having some fun:
- applying CSS animations and transitions to SVG properties, what works now and what should be possible soon;
- using CSS inheritance and re-usable SVG icons to create variations on a theme, with additional potential from CSS variables;
- designing CSS media queries for SVG to consider how they interact with SVG view-box scaling in responsive designs;
- defining filters, masks, and clip-paths in SVG code to apply as CSS effects to HTML.
It will be a rapid overview of the (many) possibilities, not a detailed tutorial. The discussion should be accessible to SVG beginners — assuming you know a thing or two about CSS! However, it will not be a general introduction to SVG, instead focusing on how you can adapt and enhance existing SVG code.
Amelia Bellamy-Royds is a Renaissance girl, whose education and career have moved sideways from bioinformatics to government science policy to journalism to data visualization to web graphics. In web development circles, she is mostly known for her work with SVG. She is an Invited Expert on the W3C's SVG and ARIA working groups, and has co-authored multiple books on SVG from O’Reilly Media. One day, she hopes to put her web graphics skills to work making journalistic data visualizations to promote science-based decisions in government policy. For now, she's focused on improving graphical communication on the web for everyone.
Media queries gave us the power to create responsive layouts that work on all kinds of screens: from small to huge. Without media queries the web would be much less flexible. But media queries are hard work. We have to decide when a breakpoint occurs, we have to decide how it looks at that breakpoint, and we have to write the code to make it so. Wouldn’t it be nice if we could simply tell the content to behave? To behave in a matter that makes sense, according to a set of rules, a system, we come up with. In other words: instead of crafting every possible layout by hand, wouldn’t it be better if we go home early and let the computer do the work for us?
It turns out that CSS gives us quite some tools to create super flexible, responsive layouts that don’t use media queries. Some are old, like floats and CSS columns. Some are newer, like flexbox and viewport relative units. And others existed for ages, we simply didn’t know they did yet.
Vasilis van Gemert
Vasilis van Gemert is a lecturer at the Amsterdam University of Applied Sciences, where he teaches the next generation of digital product designers how to design things with the web as a material. Before he became a lecturer he worked as a principal front-end developer for large and small clients in The Netherlands. Today he only creates websites for himself. This not only means that he can use any new feature he wants, it also means he is able to investigate things that might not seem very interesting. Most of the time this turns out to be true.
Practical Blend Modes
With the availability of SVG and CSS filters and blend modes, our browsers have become very powerful image rendering engines. From creating faux surrealist infrared effects to 3-d images, the artistic possibilities are endless. But what about some practical use cases for filters and blend modes? How can we use them in our every day user interfaces to improve performance and aid in design? This talk will cover just that, and show some practical examples of using filters and blend modes.
Una is a front-end developer on the Cloud Platform team within IBM Design in Austin, TX. She writes technical articles around the web and on her website una.im, is a Sass community organizer, and cohosts the Toolsday podcast. Una frequently contributes to the open source community, being a core member of the Open Design Foundation and creator of CSSgram.
The evolution of CSS4 Color
New in CSS4 Color: ICC profiles! CIE Lab! Rendering Intents! OK by new I mean the stuff that used to be in SVG2. Which used to be in SVG Print. Which used to be in (well you get the idea). Why has color management taken so long to get going on the Web? Isn't it kind of esoteric and specialized - what does it do for you, in practical terms? What, in fact, is color anyway - isn't it kind of subjective?
After attending this talk you will understand that color is a measurable, reproducible sensation; standardized since 1931! You will get white point adaptation (you already know this, you maybe just don't know the term). You will understand Lab color space, be comfortable with gamut volume plots, and be able to laugh at snake-oil claims about color gamut coverage in advertising. You will be really looking forward to seeing CSS4 Color implemented in all the browsers (and the HTML/CSS to PDF converters). And just maybe, you will be kinda pissed we had to wait this long to get what print media has taken for granted for decades, now.
If you go out and buy a wide-gamut, calibrated monitor after this, I disclaim all responsibility :)
Chris Lilley is a Technical Director at the World Wide Web Consortium (W3C). Considered “the father of SVG”, he also co-authored PNG, was co-editor of CSS2, chaired the group that developed @font-face, and co-developed WOFF. For three years he was a member of the W3C Technical Architecture Group. Co-editor of CSS3 Color and CSS4 Color, Chris is still trying to get Color Management on the Web, sigh. Currently working on CSS levels 3/4/5 (no, really), Web Audio, and WOFF2.
CSS for Software Engineers for CSS Developers
Depending on where you draw your measurements from, the first programming languages for use on ‘modern’ electric computers were designed in the ’40s and ’50s. CSS, on the other hand, is a mere adolescent—born in 1996, it’s just 18 years old. This means that software engineers have had over four decades’ head start on us: we should be listening to a lot more of what they have to say.
In this talk, we’ll take a look at some very traditional computer science and software engineering paradigms and how we can steal, bend, borrow, and reimplement them when writing our CSS. Writing CSS like software engineers so that we can become better CSS developers.
With a client list including Google, the United Nations, and Unilever, Harry is an award-winning Consultant Front-end Architect who helps organisations and teams across the globe to plan, build, and maintain product-scale UIs. He writes on the subjects of CSS architecture, performance, and scalability at csswizardry.com; develops and maintains inuitcss; authored CSS Guidelines; and Tweets at @csswizardry.
Modern CSS and interactive email
Email has often been overlooked as simplistic, outdated and limited but with modern webkit based email clients accounting for over 60% of opens the possibilities have really opened up. The new age of email is a fully interactive experience based in modern CSS (with a solid fallback for Outlook).
Some of the things we've been seeing in recent emails include;
- Tabbed layouts
- Image galleries
- Multiple pages
- Price calculations
- Analytics on interactions
- Live content
- 3D CSS
We'll look over the code behind these whilst covering;
- A brief overview of current CSS support in email clients
- Detecting interaction with CSS
- Basic interactions - The Checkbox Hack
- Advanced interactions - Introduction to Punched Card Coding
On CSS accessibility and drinking tea
When the web was new, design and structure were all mixed up together. Eventually we realised this was very messy, so we invented CSS and separated design from HTML. Everyone felt much better after this, and went and had a cup of tea.
But while everyone was drinking tea (and not really paying attention), the line between design and structure began to get messy again. Things like the before/after pseudo-selectors made it possible for CSS to directly change content, and features like FlexBox push the concept of separation to breaking point. Conversely, CSS is being used as a development tool for visualising semantic information like role and state, when added to an interface using ARIA.
In this talk Léonie will look at the changing relationship between design and structure, and what it means for accessibility mechanics in the browser. She will share CSS code examples and design patterns for solving common accessibility problems, so everyone can go and have another nice cup of tea.
Léonie Watson began using the internet in 1993, turned it into a web design career in 1997, and (despite losing her eyesight along the way) has been enjoying herself thoroughly ever since. She is a Senior Accessibility Engineer with The Paciello Group (TPG) and owner of LJWatson Consulting. Amongst other things she is co-chair of the W3C Web Platform Working Group, and a member of the ARIA and SVG working groups. In her spare time Léonie blogs on tink.uk, writes for Smashing magazine, SitePoint.com and Net magazine. She also loves cooking, dancing and drinking tequila (although not necessarily in that order).
Braces to boxes, making sense of layout
CSS, it almost feels like magic at times; doesn't it? Well, in order to remove some of that magic let's take a look at the engine and how it handles converting your CSS into the layout of your site.
Greg Whitworth is on the Layout team of Microsoft Edge and an avid advocate of enriching the web platform to empower web developers. He is a member of the W3C CSS Working Group, the CSS Houdini Task Force. He really enjoys trying to go after interop between web browsers in hopes of making the amazing experiences that web developers create, just work for their users. Prior to working with Microsoft, he was a full time web developer for over a decade working on small/medium sites and web applications.