Skip navigation
Help

web technologies

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

By Dominique Hazaël-Massieux: People used to stare at me and laugh, back in 2005 when W3C launched its Mobile Web Initiative to advocate the importance of the web to the mobile world. Now I am the one smiling much of the time, as I did most recently during the 2013 edition of the Mobile World Congress (MWC) in Barcelona, one of the largest events to focus on mobile devices and networks.

This year W3C had a huge HTML5 logo splashed across its booth to emphasize the impact of the Open Web Platform across industries and devices. But the real adoption story was told by the HTML5 logos prominent at many, many other booths. The web has gained real visibility on mobile, and we should all be smiling because we are all getting closer to a platform for reaching more people on more devices at lower cost.

MWC 2013 also confirmed that HTML5 has broken out of the browser. We are seeing more and more HTML5-based development platforms, such as PhoneGap, Windows 8, Blackberry, and Tizen. Mozilla’s big announcement at MWC 2013 centered on FirefoxOS, Mozilla’s mobile operating system entirely based on web technologies. W3C and Intel partnered to create a T-shirt that says “I See HTML5 Everywhere.” And indeed, I do.

The challenge of mobile

Not only has the web a big role to play on mobile, mobile has also a key role to play for the web. As more and more of our connected interactions start or end on mobile devices, we must ensure that the web platform adapts to our mobile lives. I believe this is critical for the future of the web.

For many years W3C has designed technology to make the experience of web users on mobile ever more rich, adapted, and integrated. For example, CSS media queries provide the basis for responsive web design. There is already a lot for mobile, and a lot more is coming. To help people follow all the activity, every quarter I publish an overview of web technologies that are most relevant to mobile.

These technologies are the tools designers can rely on to build the user experience they need. But technologies are only a small piece of the puzzle when it comes to making the web user experience work on mobile devices. The number of A List Apart articles about mobile development provides a clear sign that this challenge is driving creativity in the design community. Responsive web design, mobile first, future friendly, and just-in-time interactions are some of the trends that have resonated with me over the years. The creativity is fantastic, but we still want our lives to be easier. Where web technologies do not yet provide the hooks you need to practice your craft, please let us know. Feel free to write me directly: dom@w3.org.

Closing the gap

Another challenge that we, the web community, face on mobile is the amazing energy devoted to native development.

The web has displaced a lot of the native software development on traditional computers; on mobile, the reverse trend has happened. Content that users had enjoyed on the web for years started to migrate to native applications: newspapers, social networking, media sharing, government services, to name a few. And to add insult to injury, a number of these content providers are pushing their users away from their website toward their native application, with obtrusive banners or pop-ups.

It is unclear where the world is going on mobile: some statistics and reports show a strong push toward moving back to the web (e.g., the recent Kendo UI survey), while others argue the opposite. What is clear to me, though, is that we cannot afford to let mobile become a native-entrenched ecosystem.

What has made the web unique and popular in so many hearts is not the technology (some great, some terrible) nor even the ubiquity (since interoperability can reduce it). I believe the much more fundamental importance of the web comes from its structural openness: anyone can publish the content they see fit and anyone can participate in defining the future of the web as a platform.

Native ecosystems on mobile have historically been very closed ecosystems, under the control of single commercial entities. A world where the majority of our information and infrastructure would be trapped inside these ecosystems is not something we should accept lightly. Mind you, I appreciate the innovations spawned by these platforms, but we need to encourage the cycle where innovations become standards, and those standards prime the platform for the next innovations.

Of course the best way to shift the balance to the web is to make the web the best platform for mobile. Achieving this will require ideas and energy from many people, and web developers and designers play a critical role in shaping the next generation of web user experiences. I am leading a focused effort in W3C to assess what we can and should do to make the web more competitive on mobile, and welcome feedback and ideas on what the missing pieces in the puzzle are.

Beyond mobile

I believe a key part in making the web the “king of mobile” is to realize that mobile devices are a means to an end. In our connected world—computers, phones, tablets, TVs, cars, glasses, watches, refrigerators, lightbulbs, sensors and more to come—mobile phones will most likely remain the hub for while. The only platform that can realistically be made available on all these devices is the web.

We have a unique opportunity to make the Open Web Platform a success. I realize getting it right will not be trivial. Building user experiences that scale from mobile (or watches!) to TV is complex. Building user experiences that adapt to these very different type of interactions will be hard. Matching the needs from users in a growing diversity of contexts will make us cringe. Creating user experiences that abolish the devices barrier (as I explored some months ago) is guaranteed to create more than a few headaches.

But there is unprecedented momentum to create an open platform for the planet. And that has me smiling a lot.

0
Your rating: None

Vexing Viewports

“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.

This agreement has never been more important.

That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.

You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768x1024 pixels), even though the Mini's screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.

Two iPads, one too small.

But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.

The trouble with pixels

Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.

The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.

Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.

Two devices, each with a two-inch-wide display. The one on the right, at 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.

This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352x416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.

The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.

Enter viewports

Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.

In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.

The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.

Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”

Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.

Mini problems

The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.

And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.

Solving for content size

One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.

Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.

When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.

On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.

Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.

This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.

Three seven-inch tablets. Note the difference in rendering.

So why did Apple do this?

To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.

In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024x768-pixel layouts precisely targeted at these devices.

Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024x768 viewport suddenly looked unexpectedly wretched on the new device.

The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).

A way forward

The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.

Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.

Let’s move into the future—together.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

HTML5 Logo

Today, the Worldwide Web Consortium (W3C) is announcing that it’s completed its three-year quest to finalize the HTML5 specification. As the W3C says in its press release, "HTML5 is the cornerstone of the Open Web Platform," the cross-platform programming environment usually referred to by the umbrella term "web standards." HTML5 and related technologies like JavaScript and CSS provide a way to write rich web applications designed to run on any device that follows the specifications, and many companies are hitching their futures to the platform’s success. But despite the fact that the specification is now feature complete, meaning nothing more will be added to it, there is still a lot of work that needs to be done before HTML5...

Continue reading…

0
Your rating: None

Enlarge / Infogr.am's splash page lets you choose between creating a new design, or accessing previously stored works.

Let's say you want to compare the airspeed velocity of various unladen swallows. You could put that data into a spreadsheet, or present it using a graph. Chances are you'll pick the latter.

The question is, how do you create a graph that not only looks nice, but presents said data in a coherent, easy to understand way? You could go the traditional route, and make something basic in Microsoft Office or your productivity suite of choice. Or, if you have a bit more skill, you could opt for the flexibility of Adobe Illustrator instead. But perhaps you have neither software nor skill, and just want to make a simple graph or chart.

Infogr.am takes the same approach that Tumblr took to blogging, by turning the otherwise daunting task of creating great infographics into a process that's dead-simple. You bring the raw data to Infogr.am, and the site's online tool can help you turn that data into a nice looking chart or full-blown infographic in minutes.  It's really that simple—assuming you have a Facebook or Twitter account required to login—though, at times, to a fault.

Read more | Comments

0
Your rating: None



Mozilla has teamed up with Web design studio Little Workshop to develop a Web-based multiplayer adventure game called BrowserQuest. The game is built with standards-based Web technologies and is designed to be played within a Web browser.

With the technical capabilities offered by the latest standards, Web developers no longer have to rely on plugins to create interactive multimedia experiences and application-like user interfaces. As we reported earlier this month, modern standards are making the Web an increasingly viable platform for game development.

BrowserQuest, which is built with JavaScript and HTML5, is a compelling demonstration of how existing standards can be used to create browser games. It uses the HTML5 Canvas element to render a tile-based 2D world, HTML5 audio APIs to support sound effects, WebSockets to facilitate communication with the backend server, and localStorage to save the player's progress.

The game's remote backend, which enables the real-time multiplayer gameplay, was coded in JavaScript and runs on top of Node.js. The load is balanced across multiple Node.js instances on three separate severs. At the time this story was written, the backend was successfully handling over 1,900 simultaneous players. The status of the BrowserQuest backend can be monitored through the game's real-time dashboard interface.

The developers focused on using widely-supported standards so that the game would work well across a wide range of desktop and mobile browsers. It works just as well on a tablet device, for example, as it does on a desktop computer.

The future looks even brighter, as there are a number of pending Web standards that will greatly enhance support for building games on the Web in the future. Features like 3D graphics and support for game controller peripherals, for example, could eventually take the browser beyond the realm of casual gaming. You can refer to Mozilla's wiki to see an overview of the work that the organization is doing to improve browser-based gaming. For more details about BrowserQuest, see the Mozilla Hacks blog or check out the backend server code on GitHub.

Read the comments on this post

0
Your rating: None

Pimpin’ ain’t easy; neither is self-critique. If you are passionate about what you create, it is impossible to completely disassociate yourself from your work in order to objectively evaluate and then improve it. But the ability to achieve “artistic distance”—that is, to attain a place that allows you to contemplate your design on its own merits—will enable you to improve your own work immeasurably and, ultimately, to cast off the immature shackles of ego. Learn to let your work shine by letting go of it. Acquire the knack of achieving artistic distance.

0
Your rating: None

  

As a Japanese person living in Europe, I’m sometimes asked: “Japanese is a difficult language, isn’t it?” Those asking are often surprised when my answer is a simple: “No, actually, it’s not.”

While it is true (at least to many Westerners) that Japanese is an exotic language, when compared to learning other European languages, it may seem harder because it has has no relation to their own language. But from my own experiences of learning English and German (and also from seeing some European friends learning Japanese), I can say with confidence that learning spoken Japanese is, in fact, not so difficult. The grammar is in many ways simpler than most European languages. Take for example the fact that we don’t have cases, grammatical genders, nor articles. However, reading and writing in Japanese is… well, not so simple.

While discussing typography we most often focus on English language problems, which is only natural considering that the majority of design material is written in English. However, a lot can be gleamed by looking at how other languages are used as part of communication and design — it helps to lend context and a different point of view.

Japanese Scripts

Modern Japanese is written in a mixture of three basic scripts: Kanji — which are Chinese ideographic symbols — as well as Hiragana and Katakana — two phonetic alphabets (syllables). There are a few thousand Kanji characters, while Hiragana and Katakana have 46 each. Although there is a basic rule for when to use which script, there are many exceptions, and what’s worse is that words written in Kanji have often multiple pronunciations, depending on the context or conjunction. This is hard enough for native speaker to get right every time, so I almost feel sorry for those non-natives who are learning to read and write Japanese.

Kanji, Hiragana and Katakana Japanese scripts
From top to bottom: Kanji is mainly used for the lexical elements: nouns, verb stems, adjective stems, and so forth; Hiragana has rounded letter shapes, which are mainly used for the grammatical elements of sentences such as particles, auxiliary verbs, and suffixes of nouns; Katakana has an angular letter shape, which is most often used for foreign words and also for the purpose of emphasis.

Some say that the “tragedy” started when Japan decided to “import” the Chinese writing system, inscribing it into their own language in the 3rd century.

Since Japanese is as different from Chinese as it is to any other language, simply using the Chinese writing system was not sufficient, and a more appropriate way of writing Japanese was sought out. Some Chinese characters began to be used not for their meaning, but purely for their phonetic value. So by the 9th century, Hiragana and Katakana scripts were derived from simplified Chinese characters that were used to write Japanese phonetically.

The story doesn’t end there. As if using three scripts isn’t enough, we write in both horizontal and vertical orientation.

Horizontal? Vertical? The Unique Case Of Japanese Typography

“Vertical or horizontal?” — when setting a piece of text in Japanese, this is a question that Japanese designers constantly need to ask themselves. Being able to use both vertical and horizontal writing orientations is something so normal for us native Japanese speakers that most of us won’t even stop to wonder why this is possible, or even when and how it was first introduced.

The identical piece of text set vertically (right) and horizontally (left).
The identical piece of text set vertically (right) and horizontally (left). When it is set vertically it’s read from top to bottom, as the lines go from right to left; when it is set horizontally, it is read from left to right, like in European languages.

In general, these two writing orientations have a clear usage: vertical for something “Japanese”, “traditional”, “novels and other humanistic writings”; horizontal for “contemporary”, “business documents”, “scientific & foreign language related writings” and so on. When a main text is set horizontally, the binding is on the left-hand side, and pages progress to the right, like books in Latin scripts. Traditional books in vertical setting are the other way around, with the binding at the right hand side, and pages progressing to the left. So when you handle a Japanese book, don’t confuse the front with the back!

A typical page layout of a Japanese paperback novel
A typical page layout of a Japanese paperback novel using a vertical setting. Ogai Mori (1913), “Abe Ichizoku”, Shincyo-bunko.

traditional calligraphy is always done vertically
With its organic flow, characters are often connected and have different heights and widths
Needless to say, traditional calligraphy is always done vertically. With their organic flow, characters are often connected and have different heights and widths — which makes it impossible to disconnect and align them horizontally. Calligraphy by Keiko Shimoda, 2011 (tsukushidesign.com)


Horizontal setting is preferred for scientific texts, mathematical texts and language related books, where words and phrases in foreign scripts and signs are often included, as they are more easily incorporated horizontally. The example (above) is a Japanese-English dictionary. (Pocket Comprehensive English-Japanese / Japanese-English Dictionary, 2000, Obunsha)

Where the efficient use of space is important — namely newspapers and magazines — both orientations are often combined. Although it may appear a bit chaotic, or even random to foreign eyes, these two directions are usually used in a systematic way as a means to indicate different text elements on a page. For instance, a main text is often set in a vertical setting, but headings and captions may be set in a horizontal setting.

A typical newspaper layout
A typical newspaper layout — the main text is vertical but headings, diagrams, tables, and captions are placed horizontally.

The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text
The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text (blue). © The Nikkei (May 8th, 2009)

In a way, it’s comparable to “typographic variants” which are found in Latin typography — in Latin script text one may use bold, italic, or a different font to differentiate things such as pull quotes from the main text, whereas in Japanese we can do this by using a different orientation. Publications which accommodate non-linear or complex text (as opposed to linear text, such as novels) seem to benefit in particular from having these two orientations, which allow the layout to be highly flexible, and also to create strong visual impact.

The extreme cases of “space-efficiency-oriented typography” are informational-heavy pieces of text, such as diagrams and signage — also exploiting the two directional orientations. The Tokyo Metro map (Fig 10) is a good example of this — as you can see, both orientations are used accordingly, so that everything fits best within the limited space.

Tokyo Metro Map.
Tokyo Metro map

Tokyo Metro map with more typography in differing directions.
Tokyo Metro route map. The large type on the top is the station name which is placed horizontally. The name of the metroline may be horizontal, but the name of the stops are placed vertically.

It’s true that in many cases they look quite chaotic and sometimes even aesthetically questionable to eyes that are used to “orderly” design. But it’s easy to appreciate the visual impact and energy they create — they remind you that effective, appealing informational design does not always have to look “neat and tidy”.

Letters from my friends
Letters from my friends: when it comes to handwriting, orientation is up to a personal preference or simply one’s “mood”. But when you are writing a more official letter, or writing to somebody who is much older than you, it’s probably safer to opt for vertical orientation.

What’s Happening On Screen-Based Media?

Since the introduction of horizontal writing in the Japanese language, print-based media and signage have been employing both of these writing orientations effectively, and in ways that complement one another. But what’s been happening to screen-based media? With a few exceptions — such as word-processing machines made exclusively for the Japanese text output, or subtitles for film and TV screens, which tend to use either depending on the background image — horizontal orientation has been the dominant choice.

The prime example of this is the Web: horizontal orientation has been used almost exclusively. For the past 15 years, I have hardly come across a website that uses vertical setting. Mobile phone screens also use a horizontal orientation. I believe this may be due to the relations of hardware, operating systems and user interfaces that have become the norm, all of which have been designed to work with horizontal writing. It feels somewhat awkward to see vertical writing while all the other elements on the screen, such as the menu bar and UI elements, are horizontal.

Needless to say, the technical limitations (the support of a vertical setting by browsers is a fairly recent introduction) have largely contributed to this too. Perhaps underestimated, maybe the biggest factor for not using vertical setting for screen-based media could well be the mental association with horizontal orientation being used for something “modern” and “contemporary”.

The Nihon Keizai Newspaper website.
The Nihon Keizai Newspaper website. Although the printed newspaper employs a vertical setting for the body texts, the web-version uses a horizontal setting.

A Japanese Tea Ceremony website
So far, even with content as Japanese as a tea ceremony, a website will use a horizontal setting. (Accessed Jan. 20th, 2012)

Will Vertical Writing Orientation Die Out?

Will vertical writing orientation die out from screen-based media? Or can it make a comeback, when the technological environment allows us to use vertical settings more easily? Many e-book apps on smart phones and tablets have already started using vertical settings. With its intuitive way of navigating the screen along with the lack of external input devices (and apps being able to have more flexible/responsive layout), vertical writing seems to be incorporated much more comfortably.

I’ve spent some time reading these e-books — and pleasantly surprised at how easy they are to read. Apart from the fact that you need to scroll the screen horizontally, it’s just as comfortable as reading “normal” or horizontally set text. In fact, it’s even better for some types of publications like novels, or Manga. Our association towards this type of content when compared to the vertical setting is pretty strong mdash; it would somehow feel “wrong” to see them set horizontally.

Amazon’s Kindle has yet to support the Japanese language, but apparently they’re on their way to doing so. If they seriously want to attract Japanese readers, it would be unthinkable for them not to support vertical setting.

Soseki Natsume's “Sanshiro”
Soseki Natsume’s “Sanshiro” (1908) e-book on iPhone.

Kotobuki Shiriagari's
Kotobuki Shiriagari’s “OSHIGOTO” (2010) e-book on iPhone.

The situation also seems to be slowly changing on the Web — some interesting attempts have been made in order to familiarize ourselves with Web pages that have vertical setting. One such example is Taketori, which works just like Google translate — you can type in the URL of a Web page you wish to see in vertical setting, and Taketori does it for you. There’s also a piece of software called Kagetaka, which can switch any Web text into a vertical orientation.

Personally, I’m not too sure how well vertical setting will be supported by the users of normal Web pages, unless the way we navigate Web pages is re-developed, or a new type of browser with more innovative UI appears. Even though I complained earlier about the difficulty of the Japanese writing system, I do appreciate its diversity and flexibility, while making use of its three scripts and two orientations allows us to express subtle nuances of content — and we have been benefiting from that for decades.

I thought it would be a shame if we lose these methods of textual articulation in an age of screen-based media. But what has been happening for the last couple of years on touch-screen mobile devices (as well as the Web) can reassure us that both writing orientations may happily co-exist and collaborate on screen in the future, just as they have done off-screen for the last hundred years.

Feel free to share your thoughts in the comments section below.

(jvb) (il)

© Shoko Mugikura for Smashing Magazine, 2012.

0
Your rating: None

Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all. This distinction is not nitpicking. It’s important because it encourages certain vendors to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread. In our eagerness to use the new bling, we often forget how many people fought in the past decade to enable us to write code without forks and hacks and expect it to work interoperably. Lea Verou explains why single-vendor solutions are not the same as standards and not healthy for your professional practice or the future of the web.

0
Your rating: None