Write Better CSS With ‘Knyle Style Sheets’

CSS is complicated.

Understanding how CSS works is the first hurdle, but even after you understand the box model and other complexities you still won’t necessarily understand how to organize your CSS code. It seems like with most projects nothing turns to spaghetti code quite as fast as the CSS files.

Kyle Neath, Director of Design at GitHub, wants to make working with stylesheets a bit easier and he believes that the way to do that is for teams to create better documentation. That should be no surprise given GitHub’s obsession with documentation, but Neath has gone a step further than just telling you you should document your styles, he’s actually created a way to do it — Knyle Style Sheets.

The idea is to write documentation within your styles that can then be process into what Neath calls “a living styleguide.” It works a bit like Docstring processors for Python or Neath’s inspiration, TomDoc. Here’s how Neath describes his stylesheets:

Inspired by TomDoc, KSS attempts to provide a methodology for writing maintainable, documented CSS within a team. Specifically, KSS is a documentation specification and styleguide format. It is not a preprocessor, CSS framework, naming convention, or specificity guideline. This means it works great with ideas like OOCSS, SMACSS, SASS, and LESS.

If you’re curious, head over to GitHub and look over the KSS documentation.

Rails fans can also check out developer Garrett Bjerkhoel’s KSS Rails which provides a Rails 3 engine you can add to your existing application to automatically parse any CSS files found in app/assets/stylesheets.

It won’t solve all the hassles of working with large and complex stylesheets, but documentation can help tame some of the problems with CSS by ensuring that everyone is on the same page. Never underestimate the power of good documentation.

Read more: http://www.webmonkey.com/2011/12/write-better-css-with-knyle-style-sheets/

Is Apple Using Patents to Hurt Open Standards?

Opera developer Haavard Moen has accused Apple of repeatedly using patents to undermine the development of web standards and block their finalization.

World Wide Web Consortium (W3C), the industry group that governs and oversees the development of web standards, requires that every specification it approves be implementable on a royalty-free basis, barring extraordinary circumstances that justify an exception to this rule. The specifications can contain patented technology, as long as royalty-free patent licenses are available.

Members of W3C—a group that includes representatives from Apple, Microsoft, Google, Mozilla, and Opera—are required to disclose any patents that they hold that are relevant to each specification. Depending on how far the specification is through the standardization process, they have between 60 and 150 days to make this disclosure.

If royalty-free licensing is available, the specification can proceed as normal. Participation in the development of a particular specification obliges W3C members to offer royalty-free licensing for technology used in that specification. Nonparticipants can also voluntarily offer a royalty free license, but they are not obliged to.

If, however, there is no commitment to offer royalty-free licensing for the patents in question, a Patent Advisory Group (PAG) is formed. The PAG will then assess whether the patent is truly applicable to the specification, and if so, how best to address the issue. The PAG might then seek prior art to invalidate the patent, or it might recommend that the specification be modified, to work around the patent. It might even advise abandonment of the specification. Only in exceptional circumstances will it decide that the specification should stand, in spite of the lack of royalty freedom.

Without an appropriate patent grant, browser vendors—whether open source or proprietary—cannot implement the specification without opening themselves up to a lawsuit. Such specifications would be, at best, an extremely risky proposition for anyone seeking to develop a browser, and none of the major browser vendors would even consider implementing a specification with known unlicensed patents.

Haavard identifies three separate occasions, twice in 2009, and again in 2011, where Apple has disclosed patents and not offered royalty-free licensing. In the first 2009 patent claim, Apple said that it had a patent covering W3C’s “widget” specification. A PAG was formed, and determined that Apple’s patent was not relevant. In the second 2009 claim, Apple claimed to have two patents covering W3C’s widget security specification. A PAG was again formed. It decided that one patent was not relevant, and the other didn’t apply. With both 2009 claims, Apple waited until the last minute to disclose its patents.

Touch Events

This time, Cupertino is claiming to have three patents, and an application for a fourth, that cover some of W3C’s touch event specification. This time the disclosure was made with about a month left to go. Again, the lack of royalty-free licensing means that a PAG is likely to be formed.

This in turn will delay the development of the specification and cost W3C members further time and money. The PAG process is not quick; the widget security PAG did not deliver its verdict until October of this year.

Haavard’s conclusion is that there is a pattern of behavior here; that Apple is trying to disrupt the standards process with its patent claims. He references the touch specification in particular—this is plainly an area where Apple has lots of expertise and interest in the technology, but the company opted out of working on the specification. If Apple had worked on the specification, it would have had to disclose sooner and offer licensing, and Haavard believes that avoiding this commitment is why Apple refused to work on the specification.

Apple’s is acting within its rights. W3C obliges members to disclose patent claims, and Apple is duly disclosing them. However, it’s easy to be sympathetic to Haavard’s argument. The two prior PAGs that resulted from Apple’s refusal to offer royalty-free patent licenses delayed and inconvenienced W3C, but ultimately on both occasions the groups decided that Apple’s patent claims were irrelevant. If Apple was hoping to keep some technology to itself, it did not succeed.

Moreover, W3C doesn’t require patent-holders to give up their competitive advantage. It’s acceptable to W3C for the royalty-free patent licenses to only cover implementations of the W3C specifications; if Apple wants to permit the royalty-free use of its touch patents in HTML5 browsers, but nowhere else, this would be an option. Such terms would allow browsers to implement the standard but still keep the technology off-limits to, for example, Android. But Apple did not offer such terms before, and so it seems unlikely that it will offer such terms this time.

Further, the only likely result of this is that Apple’s patents simply get worked around. W3C’s aversion to royalties means that it’s unlikely that it would accept any non-free license (should Apple even offer one), and the importance of touch input to phones and tablets means that W3C is unlikely to abandon the specification altogether. There’s no win possible for Apple—just wasted time and money for those seeking to make the web a more effective, more open platform.

Indeed, the result might even constitute a loss for Apple; the prior art that PAGs can uncover could jeopardize the patents themselves. The PAG subjects the patents to a certain amount of scrutiny—scrutiny that could be avoided through provision of a suitable license.

Apple has thus far not responded to our request for comment.

Apple’s work on WebKit and with W3C has undoubtedly helped the web community. But actions such as this show the company’s approach to standards and intellectual property is, at best, inconsistent, and and worst downright unhelpful: if open standards and Apple’s IP interests conflict, it’s the IP interests that win out. This may be good for Apple, but it’s bad for the open web.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Read more: http://www.webmonkey.com/2011/12/is-apple-using-patents-to-hurt-open-standards/

Getting Started With Twitter’s Embedded Tweets Feature

Somewhat lost amidst the news of Twitter’s revamped interface is a slightly more interesting tidbit for web developers: Twitter posts can now be embedded in other pages.

The new Embedded Tweet feature works just like a YouTube movie, offering a short HTML snippet that you can copy and paste into any third-party website. Unfortunately using the Embed Tweet feature from Twitter is somewhat awkward since it’s buried in the new interface. First you need to click on a tweet, then click “details” and then you’ll see the embed option.

The real benefit of the embed feature lies with third party platforms like Twitter’s two launch partners WordPress and Posterous. Users of both services can now simply paste a link to a tweet and it will automatically be converted to an embedded tweet, no cut and paste necessary. For example, just drop this code in your WordPress.com blog and it will automatically be converted to an embedded tweet:

[tweet https://twitter.com/twitterapi/status/133640144317198338]

If you’d like to implement something similar on your own site Twitter now has an OEmbed endpoint you can query to convert Twitter links to embedded tweets. Those not familiar with OEmbed can check out our OEmbed tutorial, but, in a nutshell, OEmbed is a standard format where you send a URL and the host site then sends back the necessary embed code.

There are three steps to Twitter’s OEmbed process:

1. Obtain an URL to or ID number of the Tweet you want to render.
2. Make a request to the GET statuses/oembed endpoint, passing the Tweet URL or ID as a query parameter.
3. Render the html property of the response, as well as a <script> element pointing to //platform.twitter.com/widgets.js, if you want the embed to be interactive.

If you choose to render the tweet using Twitter’s widgets.js, the raw HTML will be converted into an interactive tweet. The fancy embedded tweet script uses Web Intents to allow users to reply, retweet, or follow the user directly from the embedded tweet. See the Twitter developer site for more details on Twitter’s widgets.js and how to use OEmbed to embedded tweets to your website.

Read more: http://www.webmonkey.com/2011/12/getting-started-with-twitters-embedded-tweets-feature/

Forget New Twitter. Check Out Old Facebook

The tech press is abuzz, debating the merits and failures of the new (new new?) Twitter web and mobile designs.

If you’re like most, you aren’t even seeing Twitter’s new website just yet, so if you’d like to contemplate something a bit more fun on a Friday morning, consider what Twitter might have looked like had it been around in 1997.

You might remember 1997, the heady early days of web design — 1-pixel spacer images, animated gifs, tables with gray borders and a magical new idea called “cascading stylesheets.”

How would Twitter have looked in that world? We’ll never know, but thanks to a new art project dubbed “Once Upon” you can see what Facebook, YouTube and Google+ might have looked like had they been around in 1997. Once Upon was created by artists Olia Lialina and Dragan Espenschied, who describe the project as “three important contemporary web sites recreated with the technology and spirit of late 1997, according to our memories.”

That’s right, Facebook, YouTube and Google+ redesigned in the spirit and look of 1997. As an added bonus the demo site has been set up to limit bandwidth at a 1997-esque 8 kB/s so it loads just as painfully slow as it would have on dialup.

Naturally all three sites are “best viewed with Netscape Navigator 4.03 and a screen resolution of 1024×768 pixels, running under Windows 95″ (that resolution actually seems a bit large for 1997, but that’s okay). If you can’t find a Windows 95 machine in the closet fear not, the demo site will work in any web browser that supports frames.

[via Today and Tomorrow]

Read more: http://www.webmonkey.com/2011/12/forget-new-twitter-check-out-old-facebook/