Comparing Opera Mini and Chrome Compression

Depending on how much you spend staying up on web browsers, you've probably heard the cry of Opera did it first more than once (though the low-hanging fruit, browser tabs, wasn't technically Opera first). When Google announced that Chrome would offer a data compression mode, you may have figured you'd hear it again owing to Opera Mini.

In 2004, Opera developed Mini as a browser backed by proxies to help reduce data use and speed up the overall experience. In 2006 Opera Mini went worldwide. Sadly, StatCounter doesn't break Opera Mini out from regular Opera Mobile, so it's hard to get a sense of Mini's market share. Opera's own numbers, however, report 241 million Mini users worldwide in November of 2013, with an annual increase of 21%.

Chrome for mobile devices has been climbing in use, partly because Android devices have started to move away from the default Android browser (though this doesn't affect all the Android 2.x devices and many of the 4.x devices that will be out there for a while). By adding support for data compression, Chrome is that much more appealing to users who have bandwidth caps, poor connections, or any other factor that limits how well they can see fat pages. Interestingly, some of the data compression comes from converting all the images to WebP (ol' Gil has finally found a way to make that format work). Chrome also automatically puts you into Safe Browsing mode as part of its compression process.

So I fired up both browsers, chose a list of web pages/sites that I haven't surfed using either of them, dropped into 3G and started my compressed surfing. These are the results:

Chrome requested 18.70Mb of data and compressed it to 4.83Mb, for a compression rate of 74%.

Mini requested 12.9Mb of data and compressed it to 3.7Mb, for a compression rate of 72%.

This test was by no means rigorous or scientific. While Chrome compressed just a bit better overall, I felt like the experience was slower than on Mini. Chrome was also served much more data, perhaps owing to browser detection scripts offering more "features" to Chrome, or Mini's rendering engine just ignoring some of the elements it didn't know.

For those who have decided that Google is the great new evil, you may want to consider that Google proxies are between you and the web for every request when using Chrome's compression. For Mini users the same is true of Opera's servers, but far fewer people seem to be concerned about demonizing Opera Software. How much stock you put into Google's Safe Browsing technology behaving as some sort of censor is up to you and your own paranoia. I don't much care either way, but some folks might. As someone who's used Opera Mini for years when I travel outside the U.S., I'm very comfortable with it and doubt I'll switch — it's easier for me to just fire up Mini than it is to navigate Chrome's menus to enable compression.

By the way, the pages I used for my test:

• http://www.todaysiphone.com/2014/01/apples-iwatch-much-imagined-latest-rumors-anything-go/
• http://www.fluevog.com/code/?w[]=gender:men&perpage=-1
• http://www.orlandosentinel.com/news/local/trayvon-martin/os-metrowest-shooting-stand-your-ground-20140117,0,885944,full.story
• http://www.barrelny.com/blog/text-align-justify-and-rwd/
• http://scatterfeed.wordpress.com/2014/01/18/natures-squeegee-the-nictitating-membrane/
• http://gallery.bridgesmathart.org/exhibitions/2014-joint-mathematics-meetings/blbodner
• http://www.novayagazeta.ru/photos/61844.html
• http://pluto.jhuapl.edu/gallery/sciencePhotos/image.php?page=2&gallery_id=2&image_id=63
• http://blogs.channel4.com/factcheck/factcheck-immigrants-pay/16332

Net Neutrality News

If you're spitting-mad about the W3C's perceived position on DRM, we would all be better served if you re-pointed that anger at what is happening to net neutrality.

If you aren't familiar with the net neutrality concept, here's a snippet from Wikipedia:

Net neutrality (also network neutrality or Internet neutrality) is the principle that Internet service providers and governments should treat all data on the Internet equally, not discriminating or charging differentially by user, content, site, platform, application, type of attached equipment, and modes of communication.

Think of it this way: If Time Warner wants to prioritize its own movie-on-demand services for home cable internet subscribers, it could make traffic slower for users of Netflix, or for video gamers, or for families looking up cancer information on WebMD. Think if Verizon signs a deal with Sony to prioritize for Sony devices or movies for its FiOS customers.

Yesterday the U.S. Court of Appeals for the District of Columbia effectively ruled that the Federal Communications Commission (FCC) doesn't have the authority to make internet service providers (ISPs) treat all internet traffic equally. You can read the full decision in this unfortunate PDF at the United States Court of Appeals, District of Columbia Circuit web site.

I think this is bad.

There are lots of bits of news popping up to cover this, most of them explaining why this is bad and linking to resources. I'll link some below, but as soon as I publish this post it will be out of date as more articles, blog posts, and general rants are bound to come. So you should keep your ear to the ground.

Remember, it's just a matter of time before that thing you like to do on the Internet is throttled down to painfully slow in favor of that other thing you don't like on the Internet.

1. Court Strikes Down FCC Open Internet Order at Free Press.
2. The Fight to Save Net Neutrality also at Free Press and links to some resources and history.
3. Court strikes down FCC’s net neutrality rules, agency may appeal at Gigaom.
4. What you need to know about the court decision that just struck down net neutrality also at Gigaom.
5. Verizon Victory on Net-Neutrality Rules Seen as Loss for Netflix at Bloomberg Technology.
6. Court Tosses Rules of Road for Internet at The Wall Street Journal.
7. Feds Can't Enforce Net Neutrality: What This Means For You at NPR.
8. FCC guide to The Open Internet.
9. Does This Ruling Mean The End of the Internet? Maybe. at The Daily Beast.

Almost exactly two years ago, the Internet managed to coalesce around a goal of defeating SOPA (I wrote about it not just once, but again and again), and it worked. Now we're in the same boat and people need to speak up.

Update (1:42pm)

This graphic does a good job of capturing what might happen once net neutrality is swept away.

Found this on the Twitters in @CypherTheDane's tweet.

Update: January 29, 2014

I have my own opinion on the value of online petitions, but it still doesn't hurt to try. This one has gotten a lot of traffic from the go-to web pundits: Tell the FCC to protect the open internet.

W3C EME is not DRM (nor other fear-mongering TLAs)

Plenty has been written about the W3C and DRM. Sadly, most of it has been written in the form of attacks against the W3C, with very few laying out the facts.

Note: I am a participant in the W3C HTML Working Group (as an invited expert). Encrypted Media Extensions (EME) are part of the scope of the HTML Working Group. You can decide if my opinion is tainted, but I owe nothing to the W3C to warrant arguing either way. I also don't speak for the W3C.

In Doctorow's latest post on Boing Boing, Requirements for DRM in HTML5 are a secret, he cherry-picks an email from the W3C's Restricted Media Community Group where someone wants to dive into DRM requirements but is rebuffed simply because the W3C isn't making DRM, just the APIs to access content protected by DRM (via the EME spec):

[…] what we are trying to do with EME is provide a clean API to integrate these solutions with the HTML Media Element.

And that's the crux of what the W3C is doing with DRM — developing a standard API so browsers can access content that will be locked down with or without their participation anyway.

The more W3C-savvy among you may recognize that W3C community groups don't publish specifications, they provide a way for the general public to weigh in on topics and generate wider discussion. As stated on the Restricted Media Community Group page, [T]his group will not publish specifications. In fact, if you are reading this and care about it, you should join. You may note that the people attacking the W3C haven't.

If you still aren't sure what the Encrypted Media Extensions (EME) spec has to do with DRM, then just read the abstract:

This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.

This is why Tim Berners-Lee declared it as in scope for the W3C. DRM exists and has existed for a long time. DRM requires plug-ins or third-party applications right now. By creating an API that all DRM systems use, playback in the browser will be possible (via Content Decryption Modules), thus helping to support an open web (just use your browser) instead of continued silos (Hulu app, Netflix app, Silverlight plug-in, etc).

Tim Berners-Lee provided further context in response to community outcry. Those who are bashing the W3C for DRM should read it, or perhaps just these salient points:

[I]f content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box. Those are key arguments for the decision that this topic is in scope.

This clearly doesn't jive with the false headline Doctorow used in October, W3C green-lights adding DRM to the Web's standards, says it's OK for your browser to say "I can't let you do that, Dave".

It also doesn't suggest the kind of future that Doctorow outlines in his personal post, We are Huxleying ourselves into the full Orwell, where he says I’m not kidding about any of this. I can’t sleep anymore. I think it may be game over. Of all the things to lose sleep over, this really shouldn't rank. I'm not kidding.

Cory Doctorow is fear-mongering. At this point I believe he is mis-representing the facts to further his agenda of stopping all forms of DRM, as there is more than enough evidence to suggest the opposite of what he claims (though he never links it, so perhaps he's terrible at Google?). This may be because he genuinely doesn't understand what EME is intended to address, or it may be to drive ad revenue on Boing Boing by hitting a volatile topic, but I'd like to think it's the former.

People far smarter than I, and closer to the issues, have written about this. If you find my arguments lacking then you should read these before deciding the W3C is evil.

1. DRM in HTML5 is a victory for the open Web, not a defeat, at Ars Technica, May 10, 2013.
2. Dear EFF: please don't pick the wrong fight, by Chris Adams, October 4, 2013.
3. The Bridge of Khazad-DRM, by Brendan Eich (Mozilla CTO), October 22, 2013.
4. (Austening ourselves to the full Brontë) Please Bring Me More Of That Yummy DRM Discussion, by Robin Berjon, January 10, 2014.

If you want to comment, I do not moderate but I don't allow anonymous posts (strictly spam issues). If you want to post without linking to a social media account, contact me on Twitter and I'll temporarily remove the restriction.

My rant that got me started...

W3C is speccing an API to be used to access DRM content so browsers can use it. Once again, Doctorow misunderstands: http://t.co/hN04AtB5O4

— Adrian Roselli (@aardrian) January 14, 2014

Update: January 15, 2014

Well, here's a nugget that suggests this conversation is unlikely to be calm:

work on W3C EME? take heart, you'll be "raped for millenia by Satan" for that http://t.co/XaZNsVEcps

— patrick h. lauke (@patrick_h_lauke) January 15, 2014

Update: January 21, 2014

HTML5 Rocks published an article on the 16th titled EME WTF? An introduction to Encrypted Media Extensions. For those interested in seeing some code examples, take a look.

Update: February 14, 2014

Some of the members of the W3C TAG are hammering out a document about EME. They outline the goals here:

Over the web's 25 years there have been several technologies and architectures which have had the effect of restricting access for some people to portions of the web. This document explores how these work and the effect they had on the web, with the ultimate goal of aiming to inform the debate about the inclusion of Encrypted Media Extensions (EME) in HTML.

In it they cite authentication and the object element as current examples of restricted content on the web.

The HTML Star Is Ignored (and Shouldn't Be)

On Friday Jeff Croft posted a piece titled Web Standards Killed the HTML Star where he makes the argument that just knowing HTML and CSS is no longer enough to get a job. He states that the web standards movement has effectively rendered the need for specialized knowledge of browser quirks meaningless, something he feels an HTML/CSS author used to bring to the table. In short, he maintains that the HTML/CSS dev needs to develop new skills.

And So I Ramble Through a Response

It's a compelling argument. With the advent of frameworks and pre-built templates, most web developers don't necessarily feel the need to write HTML or CSS anymore. With WYSIWYG editors built into CMSes, word processors that output to HTML, and all manner of other output-for-web features in traditional software, non-web developers never even need to see HTML if they don't want to.

Jeff's post is addressing standards from the perspective of what skills get you hired. Sadly, it's hiring practices that continue to perpetuate the lack of standards and a need for truly talented HTML/CSS coders. There are plenty of reasons why we still need skilled HTML/CSS coders.

Hip Technologies

Too many developer job requirements do in fact treat HTML/CSS as a given. It is assumed you have those skills if you apply for a software developer or graphic designer job, so prospects list HTML and CSS alongside MS Word and Excel on resumes. Instead, job listings look for the hip language or tool du jour (ActionScript Node, Dreamweaver Twitter Bootstrap, etc.).

In the last decade, many cool technologies have come and gone. Few people are asking for Flash features on their sites, for example. HTML and CSS, however, are still there. They are the bedrock on which all these new tools are built. Staying abreast of everything going on in HTML is perhaps the best way to understand and evaluate the latest JavaScript library or CSS pre-processor. Except that skill-set has been commoditized.

Bad Advice

There are many tech outlets on the web, and they all want to get eyeballs to feed the ad banners paying their salaries. As such, some of the advice on how to properly code HTML and CSS is dubious at best. It doesn't help that some of the people reviewing these resources are also not HTML/CSS experts and so cannot identify when advice is outright wrong.

Let's not forget that the HTML specification is a fluid thing. HTML 5 is not final, HTML 5.1 is coming on its heels, and browser support is still a thing we have to consider. As such, you can't really casually know HTML or CSS

Bandwidth

Remember the adage that everyone is surfing without JavaScript until the JS file is downloaded and processed. This is particularly important over slow or bad connections. It's what drives the "offline first" trend.

Perhaps you are smarter than generating nothing but a body and letting the JS fill in the HTML. If so, then knowing proper HTML is even more important, as that is what the browser will be displaying until your script is parsed.

Starting Assumptions and Pre-Built Platforms

A few weeks back I attended a local WordPress meet-up targeted at developers. As I shared my own development practices someone asked what framework I use for responsive design. I explained I use none. The reaction was bafflement. The idea of starting a responsive site with nothing but a blank Notepad window was completely foreign. The same discussion happened regarding my preferred CSS reset (none) or CSS pre-processor (also none).

Now we live in a time when many developers don't know the fundamental HTML and CSS behind their own pages. They are aware there are resets and frameworks, that they need to muddle through some markup or styles to customize it, that a module or add-on will unlock more features. They all have their choice of shiny hammer, so every problem is just a nail. They are limited by their tools.

These tools are often wrong. Their application of HTML and CSS is against best practices, a barrier to accessibility, or generally inconsistent. These tools were developed by people who also take HTML and CSS for granted, and it shows. When web developers use these tools and themselves don't know HTML or CSS, they simply carry bad habits forward, encoding it across the web.

Accessibility

Let's not forget accessibility in general. The short-sighted may roll their eyes, but only because they forget that they, too, will continue to age and will benefit from accessibility features.

It's my experience that just trying to get developers who "know HTML" to create a simple heading structure on a page is a painful process, but fold ARIA into the mix and you've blown someone's buffer. Even if we keep it simple, I challenge you to find someone who can adequately explain the difference between article and section, let alone what the accessibility implications are.

There tutorials and frameworks dedicated to styling a button to look like a link, or a link to look like a button. These make it into frameworks, software products, and even best practice guides. The specialists without HTML or CSS knowledge are making the web harder to use for those with disabilities.

My Advice

Jeff's advice is to diversify. That is quite good advice. Ideally the more you know about assorted technologies the more quickly you can pivot when they are replaced.

My advice is a bit different. Learn the fundamentals. Learn HTML and CSS and how to best apply it. If it interests you enough to specialize, then be prepared to make your case when looking for a job.

Be the person who validates what everyone else on your team is building so they can stick with their preferred language and you can make sure it renders clean, valid HTML. Be the person who reviews frameworks and tools and can best guide decisions and what needs to be done to fix these third-party codebases.

Another Take

Rewind to Jeffrey Zeldmans' article, To Hell With Bad Browsers, from February 2001. That article pretty much kicked off the web standards push, the core of the standards movement. A few days after that post, I wrote a quasi-response piece, To Hell With Bad Editors, where I took web developers and WYSIWYG editors to task.

As you can see from my rant above and my position thirteen (13!) years ago, I still don't think the web standards movement has achieved its goals. In that regard, I think Jeff Croft's piece already starts from a false assumption.

Others' Thoughts

Others have stated their opinions in the comments of the original piece, and yet others in their own posts:

• It’s 2014. Is Web Design Dead? by Jeffrey Zeldman, January 6, 2014.
• It’s 2014. Web Design Isn’t Dead by Andrew Clarke, January 6, 2014.

Related

• Christian Heilmann is starting a series on some of fundamental features of the web, the things we are often supplanting in our desire to play with the new hotness. His first post reviews the humble hyperlink: Endangered species of the Web: the Link
• Remember in 2010 when the web was declared dead? Or again in 2011? Or perhaps again in 2012? Yeah, it's not dying. Those skills are still important.

The Truth about “The Truth About Multiple H1 Tags”

I'm a bit behind on my reading. There is always some new wiz article on web technologies and it's hard to keep up. Since any chummer can write one, sometimes you have to approach them with caution even if they've survived the meat grinder of public review for as long as a week.

Yesterday I stumbled across The Truth About Multiple H1 Tags in the HTML5 Era at Tuts+ and wasn't sure I was going to get much out of it. Its promises were loft:

With the advent of HTML5 the answer to this question has significantly changed in both SEO and technical regards. It's now not only possible to have multiple <h1> level headings per webpage that will make sense to search engines, but in most cases it's actually the recommended course.

The pre-HTML5 <h1>

The article starts by painting a picture of how the <h1> element has been used in the pre-HTML5 world. It suggests that developers have made web pages where the location of the <h1> changes from page to page. From the header area on one page, to the article title on another, only to have the header area replaced with a <p>.

I take issue with this based on my own experience. Having built web sites since 1994, having worked with dozens of content management platforms, having peaked under the hood of thousands of sites, this just doesn't match my experience. The author, however, makes no effort to back up this assertion, which seems odd given how easy it is to pull data from WebDevData.org.

While it seems like a moot point, it indicated to me that the rest of the post was going to built on shaky ground. Which it is.

The Vaunted Mythical Document Outline

The core thesis of the post is built around the document outline (simply evidenced by the headline Why Headings Matter: Document Outlines).

The problem is that the document outline doesn't really exist. It's not real. In the words of Steve Faulkner, one of the W3C editors of the HTML5 specification,

The HTML5 Document Outline is a dangerous fiction

In that same post, Faulkner also explains:

If you as a developer want to provide a meaningful document structure, use the <h1>–<h6> elements to express document structure. DO NOT rely upon the HTML5 document outline. By all means use the HTML5 section elements, but do not rely upon them to convey a meaningful structure. If at some point in the future the HTML5 document outline ceases to be a fiction, you will be covered as the use of h1-h6 is backwards compatible.

In fact, the HTML5 specification itself clarifies this in only a few words:

Sections may contain headings of any rank, and authors are strongly encouraged to use headings of the appropriate rank for the section’s nesting level.

Let's forget about what the HTML5 specification says. After all, just because the specification says to not use <center> doesn't mean it's not supported, so maybe we should look to the browsers instead?

@alastc @aardrian +1 Misses the point of HTML headings & ignores the fact the document outline algorithm isn't supported in any UA...

— Léonie Watson (@LeonieWatson) December 23, 2013

The browsers don't support the document outline.

So much of assistive technology (such as screen readers, for example), relies on the browser parsing the page that moving to an all-h1 structure can actually reduce the usability of pages for some users. According to the 2012 WebAIM screen reader user survey, ~82% of users rely on the headings to navigate a page. Creating a flat page structure, via an h1 everywhere approach, can be a huge problem.

This isn't new information, either. Finding articles from two years ago stating as much is pretty easy.

To simplify a best-practices approach, Faulkner even restated it on Twitter this morning (after he saw my Twitter rant last night):

@aardrian @heydonworks point is IF the algorithm is used then no diff between h1 and h6 as depend on nesting level, if not then ONLY...

— Steve Faulkner (@stevefaulkner) December 23, 2013

@aardrian @heydonworks ... using the appropriate heading level for the nesting level gives you a document outline = backwards compatibility

— Steve Faulkner (@stevefaulkner) December 23, 2013

SEO, or the Magical Unsupported Acronym

The introduction to the article also promised a boon to your SEO efforts if you used this HTML5 all-h1 approach.

I challenge you to find any explanation of how this helps SEO, justification, links to evidence, quotes from Google/Bing/Yahoo, etc.

In fact, when asked in the comments how this all relates to SEO, the author essentially backs away from the original assertion and instead discusses schema.org syntaxes and the need for relevant content.

Conclusions

Don't trust articles that don't present you with evidence (or links to evidence). Don't buy into SEO claims that are never justified. Build your heading structure for backward compatibility.

Update: January 5, 2014

This conversation has led to a discussion on the W3C HTML Working Group mailing list to revisit heading advice in the HTML5 specification.

Update: January 25, 2014

The Mozilla Developer Network has updated its article Sections and Outlines of an HTML5 Document with the following statement:

Note: The HTML5 outline algorithm as described below is not implemented in user agents, as a consequence, users who make use of heading semantics are exposed to the HTML 4 document structure. The description of problems solved by HTML5 is theoretical only.

Update: February 24, 2014

A post over at Treehouse, How to Use The HTML5 Sectioning Elements, discusses sectioning elements while avoiding referencing the document outline. At least until the comments. I dived in to try to correct, but it's clear bad advice is still circulating and probably will for quite some time.

Update: APril 17, 2014

As Steve Faulkner reminds us on Twitter, we should not rely on the HTML document outline algorithm. Now it's been codified in the (draft) spec:

There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.

“Tracking Printed Pages (or How to Validate Assumptions)” at Web Standards Sherpa

Today my second article at Web Standards Sherpa has been posted, Tracking Printed Pages (or How to Validate Assumptions). I fit a lot in there, but the gist is that I show you how to track when and what pages from a site are printed so you can make a better decision about where to invest your effort.

I also draw a comparison to the time we all spend on building carousels for sites, but may not be tracking. After all, if no one uses the carousel and people do print pages from your site, you might just want to change where you are spending your development time.

The article also has the nifty ReadSpeaker feature which means that the page can read the article aloud to you in a voice that is entirely unlike mine (at least it's a male voice by default).

What guides your project decisions? Data or assumptions? Adrian discusses the importance of tracking site features, like print styles, to inform how and where you invest effort. Read it…

Web Development Advent Calendars for 2013

Ganesha may or may not be stealing chocolate from the advent calendar.

For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.

I may have missed some, so please pass them along if you know of any. For those I know are not returning, I have listed them at the end.

1. 24 Ways

24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.

2. Perl Advent Calendar

Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.

3. 24 Jours de Web

24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).

4. UXmas

UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.

5. Webkrauts

Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.

6. 12 Devs of Xmas

12 Devs of Xmas will also start the day after Christmas and go for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read. The site is silent on its return, but this tweet suggests it's gotten writers and has a plan.

7. Freelancember

Freelancember 2013 is targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. It has last year's calendar there as well, and so far (as of December 1) I cannot tell the calendar will just be a repeat of last year.

8. Mozilla Developer Network Holidays calendar

Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). It doesn't link to previous years, but you can just hack the URL.

9. SysAdvent

SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008 (and yet I missed it in last year's collection), so there is plenty of good material there if you're too impatient to wait for each day to be revealed.

10. Performance Calendar

Performance Calendar hails this as the speed geek's favorite time of the year, ostensibly because of the tips it has been offering each December since 2009. It isn't just server optimizations you'll find here, so don't shy away because you're not a system admin.

11. Web Accessibility Advent Calendar 2013

Web Accessibility Advent Calendar 2013 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.

12. Creative Bloq Advent Giveaway

Creative Bloq Advent Giveaway posts aren't collected in one place, so you'll have to find them on the site yourself (I linked the first one). Creative Bloq is the parent of .net Magazine, but you can expect most of its freebies will be targeted toward designers. Also, not all the gifts will be free, some will be discounts.

13. 24 Pull Requests

24 Pull Requests is less an advent calendar than it is an effort to mobilize developers. The goal is to get developers to send a pull request every day in December (up to Christmas), thereby supporting your favorite open source projects. There are even Coderwall badges for those who collect those sorts of things. This entry via Creative Bloq.

Not Returning

A handful of calendars aren't returning this year (so far), but in most cases content from previous years is still available. These include Font Deck's Adfont Calendar (which also skipped 2012), the Fronteers advent calendar (in Dutch, and also skipped 2012), Web Advent (it's taking a year off), HTML & CSS Advent (this is the 2012 calendar), She Said It (no access to old calendar), 12 Days of Podcasts (or at least there is no indication on its site or Twitter).

Not Web Related

ScienceGeek Advent Calendar Extravaganza is not web-related at all, and frankly it isn't promoted nor is it tagged (although I linked to “special” since that tag had the first day and nothing else). It is, however, probably going to be neat stuff given the first day is a giant image of the Christmas Tree Cluster.