Talks

Custom Properties – das sind CSS-Variablen, nicht wahr? Ja, sowas in der Art. Und nein, sie sind mehr als das.

Der Vortrag behandelt, was Custom Properties mit Variablen gemeinsam haben, wie wir sie aus CSS-Präprozessoren wie Sass kennen, und wie sie darüber hinausgehen. Wir werden sehen, wie sich Custom Properties ins CSS-Universum einfügen, mit Betonung auf dem C: the cascade.

Wir werden sehen, wie Custom Properties dabei helfen, DRY Code (don’t repeat yourself) zu schreiben. Wir werden Beispiele sehen, was man mit Custom Properties machen kann, was mit Variablen in Sass nicht geht.

Wir werden Jahrtausende zurück in der Zeit reisen und Quadratwurzeln wie die alten Babylonier berechnen – nur dass wir es in CSS tun.

Warum? Weil wir’s können?

Nicht nur das, ich werde einen Anwendungsfall vorstellen, wo man tatsächlich Wurzeln beim Layouten ziehen muss.

On the journey through the realm of HTML element we learn what new elements come with HTML5, and why it is important to the users that developers use them appropriately. There is cure for divitis.

Auf der Reise durch die Welt der HTML-Elemente erfahren wir, welche neuen Elemente HTML5 mit sich bringt und warum es für die Nutzer wichtig ist, dass Entwickler das jeweils richtige Element verwenden. Divitis ist heilbar.

Unter „semantischem Markup“ verstehen viele, die jeweils passenden HTML-Elemente einzusetzen. Diese beschreiben aber die Struktur, nicht den Inhalt einer Webseite.

Damit „verstehen“ Maschinen (bspw. Suchmaschinen) noch nicht, worum es auf der Seite geht. Dem kann man mit microformats, microdata, RDFa, Schema.org nachhelfen. Davon profitieren nicht nur Suchmaschinen; es werden auch andere Anwendungen gezeigt, die den Nutzern zugute kommen.

Achtung: Der Vortrag kann Spuren von klingonischen Flüchen enthalten.

Progressive enhancement introduced visually with OpenType font features: basic at first, then ligatures, alternate glyph variants, swashes, …

But what is that—progressive enhancement? It “isn’t a technology. It’s more like a way of thinking,” says Jeremy Keith.

The key to thinking this way is: accepting that websites/web applications do not need to look/behave the same in every browser. Make the core functionality available using the simplest technology, then enhance from there—secure in the knowledge that even if a certain feature is not supported in some browsers or on some devices, that’s okay: the fallback is in place and works everywhere.

As an example we’ve implemented a tic-tac-toe browser game: the core functionality in plain HTML using interactive form elements. It’s surely not fun to use yet, but it works (which also means: it’s keyboard-accessible). And as Jeremy Keith used to say, enhancement does not mean it’s just an enhancement. We’ve enhanced the look with CSS and the feel with JavaScript. The final result still has accessibility baked in (i.e. not taken away), while providing a pleasant user experience.

Accessibility (sometimes abbreviated as a11y) means that content should be available to everyone and that functionality could be operated by everyone. This session aims to raise awareness of this topic, as Ian Devlin says, “The 11 in a11y stands for the number of times you have to tell developers that accessibility is important.” Add “and designers and product managers.”

To bear accessibility in mind does not mean to design for just a small minority (eg. blind users). Everyone can have visual, motor, hearing, or cognitive impairments—be it temporary, permanent, or situational. Everyone benefits from accessible web pages/applications.

In this session, we’ve discussed the Web Content Accessibility Guidelines (WCAG), tools like color contrast checkers, and how to build an accessible form with HTML by just following some basic rules.

Because it’s your job! Even if your stakeholders are not yet convinced that accessibility is important, follow Léonie Watson’s advice: “Just go ahead and do it anyway!” Because as Tim Berners-Lee said, “This is for everyone!”

Responsive web design—Ethan Marcotte coined the term in his article on A List Apart in 2010. Yet the idea dates back to 2000: ‘A Dao of Web Design’, wherein John Allsopp calls designers to let go of control they know in the print medium, to design for the flexibility of the Web, to “accept the ebb and flow of things.”

This became more relevant now that the Web is not accessed only on desktop computers, but on a growing variety of devices. Web sites not only do not need to look exactly the same in every browser, they must not look the same in every browser on every device.

We cannot build a responsive web site based on Photoshop mockups—“you damn liar”, as Josh Brewer sang(!) at beyond tellerrand 2013. Mockups can only show particular views of a web page, not those in between.

We cannot build a responsive web site in a waterfall process—we need a responsive workflow. A workflow that does not separate design from development. A workflow that allows for iteration cycles.

Developers tend to think that with Scrum or Kanban, they are doing agile development. But on a larger view, they are still stuck in a wireframes–visual design–development waterfall process. You are not agile unless developers, designers, project managers and other stakeholders sit on the same table and work together, not sequently.

To implement a responsive workflow in our company, we need to rewire some people’s brains. We need a responsive mindset. But how do we get there?

To many, “semantic mark-up” means using appropriate HTML elements, not just divs (which should be a matter of course). But there’s more to it…

This talk provides an insight into Semantic Web technologies and how they can be used with HTML: microformats, microdata, RDFa, Schema.org. We’ll cover how applications can benefit from it and its impact on user experience.

What do Klingons have to do with it? You’ll find out…

While purists propagate to not mix content structure (HTML), presentation (CSS) and behavior (JavaScript) layers for the reason of maintainability, concepts like OOCSS aim at the same goal, but from a different angle: reusable CSS code, at the expense of bloated, presentational mark-up, violating the separation of concerns. Can’t we have both, clean mark-up and reusable CSS? The benefits of both approaches without the drawbacks?

Yes, we can. This talk shows how to take the OO concept out of the HTML and put it where it belongs to: into the style sheet. Not directly into the CSS though, but into an intermediate layer provided by a CSS preprocessor like Sass.

Like Ogers and onions, concepts have layers. Unlike Ogers and onions, they don’t always stink, but eventually lead to the best of both worlds.

From bicolores (Polska!) over crosses to stars and stripes – using flags as leitmotif we’ll build patterns with a single HTML element and CSS gradients. As much as about the geometrical patterns it’s about the patterns in the code. And we’ll calculate square roots like the ancient Babylonians – in Sass. A short trip into geometry. Bring your rulers and compasses!

Sass + mathematics. Many web developers nowadays use CSS preprocessors, and do simple calculations like ($a + $b) * $c in them. But we can do more. Much more: sin, cos, tan, … and calculate square roots like the ancient Babylonians. A short trip into geometry. Bring your rulers and compasses!

This talk covers how CSS preprocessors can help with what every web devoloper hates: supporting legacy IE, and with what every web devoloper should hate: OOCSS. While some still love it, I’ll discuss its downsides and how we could do better to achieve its goals.

The talk covers best practices and pitfalls when dealing with languages that create large compound words (like German), languages with special capitalization rules (again, like German), or languages written in right-to-left scripts. This includes things like box sizes, box shadows and corners, image replacement etc. It also covers benefits that new CSS 3 properties and values offer in terms of internationalization, a discussion wheather the :lang pseudo-class selector meets all needs or if there’s more to wish for, and how to implement style sheets for various languages and scripts (all rules in a single file or spread over multiple files?). The talk will be of rather practical than theoretical nature.

I’ll address two common i18n problems that users of current mainstream browsers face. Users should get content from multilingual Web sites automatically in a language they understand, hence they need a way to tell their preferences. Some browsers give users this option, but others don’t. I’ll demonstrate live if and how languages can be set in various browsers and discuss the usability issue that browser vendors have to deal with: the trade-off between functionality and a simple user interface. Users should also be able to enter email addresses with international domain names into forms. That might not be possible in modern browsers that already support HTML5’s new email input type. I’ll show how to validate email addresses not being too restrictive and eventually raise the question: Does the HTML5 specification have to be changed to reflect the users’ needs?