Thanks to the great work by Max Vujovic, Michelangelo de Simone and others on the Adobe Web Platform team, all blend modes for CSS fragment shaders have landed in the latest versions of Chrome Canary (with the CSS Shaders flag turned on) and Safari WebKit Nightly builds. Max has a blog post up on his personal site with more details and pointers to the samples in codepen, be sure to check both out.

A couple of months ago we had a blog post about adding blending in Canvas. At the time, the feature was only in the nightly builds of Firefox and Webkit. We’re excited to see that version 20 of Firefox now has this feature enabled by default.

Here‘s a CodePen that shows blending in action:

Open it in the latest version of Firefox and use the dropdown to experiment with the different blending modes. If you open it in an older version of Firefox or another browser, you will not see any blending but the animation should still work.

Stay tuned to have canvas blending  in Chrome as well.

Let us know what you think of this new feature or if you have a cool demo that shows it off!

Fidus who?

Remember the SourceFabric team from a while ago? Well, not only their BookJS project is coming along nicely, but it’s also been picked up by other projects. The latest of them is Fidus Writer.

In a nutshell, Fidus Writer is Google Docs meets LaTeX (for mortals). It takes the nice ideas of LaTeX – like focusing on the content rather than the layout – and dresses them in 2013 web clothes designed for academics. This means you’ll also get support for bibliography and citations (in a little under a gazillion formats), changes tracking, collaborative editing and commenting.

Here’s a video to whet your appetite

I can haz Regions?

So how does Fidus Writer use CSS Regions since there’s no fancy magazine layout to be seen in its rather minimalist interface?

Well, the easy way to tell is to try using it in a regions-challenged browser. In this case, the content is rendered as a single, long flow, with the footnotes (if any) at the very bottom. However, in a regions-enabled browser, the content is nicely paginated and footnotes flow where you’d expected them to in an editor like Word or LaTeX. This gives a closer to WYSIWYG experience, especially for documents meant to be printed.

The regions-enabled version places content and footnotes in different named flows and then does just a little bit of JS magic to compute and position the necessary regions.

So, is this for you?

If you’re interested in CSS Regions or have a friend in academia who’s not fond of editing TeX in vi , keep your eyes on this project; rumor has it more goodies are in store for the 1.0 version.

Most of us have used filters in applications like Photoshop to transform images in any number of amazing ways. And unless you’re doing strictly print work, there’s a good chance most of those images found their way online. Filters are such an integral part of the process of bringing visual content to the web that we decided they should actually be standard web technology in the form of CSS Custom Filters.

CSS Custom Filters allow you to apply filters to not just images, but any HTML element in real time, right in the browser. Built-in filters allow you to achieve standard visual effects like blur, grayscale, drop shadows, and sepia while custom CSS Filters allow you to do just about anything you can imagine.

To help designers and developers get a feel for what CSS Filters are, we built an application called CSS FilterLab. And to help introduce CSS FilterLab to the world, we created this short video:

To start experimenting with custom filters, the first thing you need to do is enable CSS Shaders in Chrome:

1. Go to chrome://flags in your location bar.
2. Search for “Enable CSS Shaders.”
3. Click the “Enable” link.
4. Relaunch your browser.

Now all that’s left to do is head over to CSS FilterLab and have some fun.

It’s very cool to see contributions from Adobe’s Web Platform team land in the release version of Chrome (CSS Regions and CSS Exclusions are both available behind the generic “Enable experimental WebKit features” runtime flag), but I have to say, there’s something extra cool about them showing up in the Chrome Beta for Android. Now that well over 20% of web traffic is coming from mobile devices, it’s increasingly important for mobile browsers to stay on the cutting edge of standards.

In the video below, I demo a couple of CSS Regions and Exclusions demos done by my team (specifically Dmitry Baranovskiy and Razvan Caliman). You can find links to the demos and the source code below the video.

If you want to check these demos out for yourself, be sure to enable experimental WebKit features in Chrome (Video: All About Chrome Flags), and have a look:

• Chrome Beta for Android.
• Recipe demo (GitHub repo).
• Road Trip demo (GitHub repo).

By allowing text to automatically flow from one box to another, CSS Regions bring the power and flexibility of complex layout to the web. This makes it easier to build pages with layout similar to traditional newspapers and magazines, but it goes beyond that.

A recent code contest with CSS Regions on CodePen showed us how creative folks can twist and turn this technology to explore new reading experiences. A big “Thank you!” goes out to all those who worked on the demos.

However, regions can do more than just flow text across boxes.

Another use case

Regions work by disconnecting the visual rendering of elements from their order in the DOM. This gives a hint to a potential new use case – building adaptive UI for web applications. I do emphasize on the adaptive term because this accounts for the user and device context.

If you’re building a truly desktop and mobile-friendly web application you want to carefully consider both adjusting to screen size as well as the context in which the web app is being used. For mobile, this usually means repositioning of layout and controls across the screen. However, there are limitations in what you can adjust because of the DOM order of elements.

Here’s one idea to explore:

Moving UI controls with Regions

With CSS Regions, elements can be collected into named flows, and then be visually rendered in other places in the layout, without touching their DOM order. It’s useful to think of regions as applying a visual transformation to elements, moving them from one box to another.

By adding media queries to the mix, you can move links, buttons and controls to optimize the UI for a specific context.

A common design pattern seen in mobile apps is to group non-essential controls under a menu that slides in from the side.

Using CSS Regions, it’s easy to collect elements from the page and visually nest them under a menu that can be toggled on and off.

@media screen and (max-width: 30rem) {
  #account, #language, footer a{
    /* collect elements into the 'controls' named flow */
    flow-into: controls
  }

  #menu{
    /* render elements from the 'controls' named flow into #menu */
    flow-from: controls
  }
}

This code states that, for narrow viewports of 30rem or less, some of the UI controls will be taken from their normal desktop layout position, moved to a named flow called ‘controls’ and then rendered in another element identified by the ‘menu’ ID. Arbitrarily positioned elements can be pulled in together regardless of the DOM order. Notice the controls from the bottom of the page move in the side menu, together with the controls from the top of the page.

Demo

See an example of the idea in this adaptive UI demo. Resize the browser window and notice how the highlighted elements are moved under a slide-out menu when the viewport gets too narrow.

Make sure to use a browser that supports CSS Regions and that you have enabled any necessary experimental flags.

Chris Coyier from CSS Tricks has explored a similar idea with CSS Regions which he dubbed content folding. In a nutshell, it allows nesting content such as images, embedded media or ads in between paragraphs of an article when the viewport is narrow.

Content folding example on CSS-Tricks.com

Alternatively, this content can be positioned in a sidebar when there is enough horizontal space in the viewport.

More options for adaptive layouts

These examples show that CSS Regions can go far beyond flowing text between boxes. They are building blocks for doing highly adaptive layout on the web. For web developers and designers, this means breaking free from the limitations imposed by element DOM order and opening up a lot more creative approaches for adaptive and responsive designs.

This week we have a whole slew of news items that circulated around. Check them out and feel free to comment on any of them here!

• Blink – A new rendering engine for the Chromium project forked from WebKit
  
• Opera adopts Blink – confirms it will follow Google and ditch WebKit for Blink, as part of its commitment to Chromium
• Servo Project – Samsung teams up with Mozilla to build browser engine for multicore machines
• asm.js – Firefox Nightly now has accelerated support for asm.js
• asm.js UT3 – playable demo of Unreal Tournament 3 running in Firefox Nightly being shown at GDC03
• Emscripten – Why developers may find this C ++ transpiler to HTML5 interesting
• LLJS to asm.js –  It’s now possible to compile LLJS to asm.js
• Parallel JS – Mozilla has now added high-level concurrency support to Firefox Nightly
• Dart2js – Why dart2js produces faster JavaScript code from Dart
• HTML5 Ray Tracer – Real-time RT engine for JavaScript (using CoffeeScript)
• IE 11 WebGL - How to enable WebGL in Internet Explorer 11
• Brackets Update - Type-Aware JavaScript Code Intelligence!

A while back I wrote about Generating Boxes in CSS where I suggested extending pseudo-element syntax in CSS to create presentational boxes. I proposed a new mechanism for adding an arbitrary number of ::before and ::after pseudo-elements to extend what we have now. This was intended as a first step towards more box generation in CSS – for wrapper elements, grouping, etc.

The main idea has been to separate content from its presentation. Say you want to vertically center an element. Flexible box layout gives you a very simple way to do this, but you need a wrapper around the element to turn on display:flex. That wrapper isn’t really part of the content, so it would be great not to have to litter your code with <div class="flex-wrapper"></div> elements. If there were a ::wrapper pseudo-element, you could keep the presentational code away from your content markup.

But what if you wanted to wrap two or more sibling elements in the same wrapper? Then you’d have to define how pseudo-elements could either wrap each sibling individually or group them together. You quickly get to the point of re-creating HTML structure in CSS syntax, and CSS was never meant to represent structure. I’ve now come to think that presentational boxes may be better defined in HTML Templates that are part of the Shadow DOM proposal. No new pseudo-elements are required, and you can still keep the presentational boxes out of your content markup.

As a result of this change of thinking, I have reworked all of the examples in CSS Regions to use Custom Elements and HTML Templates to define the boxes used to create CSS Regions.  The elements used to create region boxes can move from content markup to an HTML Template. Your content markup remains clean, and you have all the structural facilities of HTML to arrange your region boxes. This is all building on the ideas first expressed by Razvan Caliman in a blog post last year.

Here’s a simple example. In the content markup below, there is an article with an image element and a few paragraphs. If either Custom Elements or CSS Regions are not available, the image is displayed between the first and second paragraph. But if both features are available, then the top of the image will be placed four-fifths of the way down the viewport height. The article text will flow above and below the image, filling the space above the image with whatever text fits instead of breaking at a particular paragraph boundary.

<element name="two-regions" extends="body">
  <template>
    <style>
    article > p {
      flow-into: article-flow;
    }
    #region-1, #region-2 {
      flow-from: article-flow;
    }
    #region-1 {
      max-height: 80vh;
    }
    </style>
    <div id="region-1"></div>
    <content></content>
    <div id="region-2"></div>
  </template>
</element>

<body is="two-regions">
  <article>
    <p>...
    <img>
    <p>...
    <p>...
  </article>
</body>

The above (aside from some shadow boundary tweaks) is equivalent to the below. Either version works to flow content through two regions, but the HTML template version lets you separate the presentational markup from your content markup.

<style>
  article > p {
    flow-into: article-flow;
  }
  #region-1, #region-2 {
    flow-from: article-flow;
  }
  #region-1 {
    max-height: 80vh;
  }
</style>

<body>
  <div id="region-1"></div>
  <article>
    <p>...
    <img>
    <p>...
    <p>...
  </article>
  <div id="region-2"></div>
</body>

The difference between the example above laid out with or without CSS Regions is a bit subtle. Here’s a picture of what it might look like without CSS Regions in two different screen sizes. The image doesn’t appear in the smaller screen until you scroll:

But with the 80vh region, you ensure that at least part of the image is visible before scrolling on any screen. The font size can change or the window can be resized, but the image will stick in place and the text will flow around it.

The declarative use of Custom Elements here and in the specification examples is still a bit cutting-edge. Currently browsers require a bit of JavaScript to get it all going. I expect that by the time this all works natively in the browsers I will need to update my HTML Template examples. I’m following what’s currently defined in the excellent Shadow DOM Explainer by the eternal optimist Dimitri Glazkov. If you want to dig deeper there is series of posts on html5rocks called Shadow DOM 101, Shadow DOM 201: CSS and Styling and Shadow DOM 301: Advanced Concepts & DOM APIs that provide more detail.

Accessibility is very important for us at Adobe. We are involved in different boards and committees to make the web more awesome but also more accessible. Yesterday we announced to work on a new specification called CSS Localization. The idea was to get rid of the language barrier on web technologies starting with CSS. Web browsers would be required to support national languages like French, English or even intergalactic languages like Klingon. Web authors would not need to learn the (mainly) English keywords and use their native language instead.

However, this morning we decided to discontinue this approach. The requirement to web browsers would most likely cause a major interoperability issue. Most web pages would be broken once browsers “must not require other languages for properties and keywords than defined by the language of the content creator”. This would not only damage the web as a whole, but harm the accessibility for the content consumer dramatically. We thank everyone supporting this approach and all the comments we got.

To make it abundantly clear: It was an April Fool’s Joke!

Background

The Adobe Web Platform team is quite multilingual – we have native speakers of Catalan, Chinese, Dutch, English, French, German, Hungarian, Italian, Japanese, Romanian, Russian and Tamil included in the team. So we find it particularly taxing for everyone to have to code entirely in English. We have a new proposal for the CSS Working Group that is a small step towards addressing this annoyance.

Proposal

CSS Localization allows you to code in CSS in your native language. A new @⚐ rule (needing no localization itself) sets the language used for selectors, declarations, and values so that you never have to refer to an body element or a border property by their English names again.

Here’s an example of the new @⚐ rule with some localized CSS:

@⚐ français;

corps {
  fond: rouge;
  bord: solide noir 1px;
  taille-de-la-police: énorme;
}

Hopefully, the rest of the web platform stack will follow suit with localization strategies of their own. We are looking forward to advancing this new idea through the standards process. Please take a look at our unofficial draft specification!