Archive for the ‘HTML 5’ Category

Mozilla Launches Firefox Developer Edition

mozilla_1411034_616

Earlier this month, Mozilla teased an upcoming version of Firefox specifically for developers. It’s now released Firefox Developer Edition.

The browser replaces the Aurora channel in the Firefox Release process, and features will land in Developer Edition every six weeks, just like Aurora. This is after they have stabilized in Nightly builds.

Developer Edition gives developers access to tools and platform features at least twelve weeks before they reach the main Firefox release channel. It will also include experimental tools.

“For example, the Developer Edition includes the Firefox Tools Adapter, which enables you to connect the Firefox developer tools to other browsers such as Chrome on Android and Safari on iOS,” Mozilla says.

The browser uses a separate profile from other versions installed on your computer so you can run the alongside one another. Default preference values are tailored for web developers. Chrome and remote debugging are enabled by default, for example.

You can download and learn more about Firefox Developer Edition here.

read the article here..

By · Published on November 10, 2014



Make Your HTML Email 5½ Times More Mobile Friendly

by Josh Rubinstein.

 

Why should you care?

From the time we rise until the wee hours of the night our smart phones are never far from our opposable thumbs. Despite the proliferation of “umpteen” social networks, email still tops out as one of the most common tasks we perform while on the go or at our desks.

The Concept of “The One Web” represents a shift in thought towards “democratically” publishing online content to a range of devices. At Estately, whenever we talk to our customers, we hear that they read our Saved Search alert emails in the “fleeting moments” when a meeting hasn’t quite started or while scarfing down some fruity pebbles cereal in the morning. One of our users told us that in the morning the alarm goes off and, before he’s out of bed, he looks through new emails on his iPhone.

The statistics back this up: no matter what service your company provides, your HTML email needs to be optimized for mobile today – according to Campaign Monitor, the iPhone now accounts for almost 15% of their email subscribers. Heck world-wide Smart Phone activation is outpacing births by 3X!

One HTML template for them All

Part of the goal for the HTML Email template design was to only require the use of one template for both mobile, desktop and anything else the industry creates in the next 6 months for that matter! Approaching design and UX challenges with wearing the lens of Progressive Enhancement in mind makes the world a nicer place!

I didn’t want to depend on CSS3 media queries for content scaling. I wanted to provide as much support to various devices by using percentage widths and max-widths.

Like-wise when CSS3 is supported I figured the device would be responsive enough for advanced stying and design, as you will discover below with my work-in-progress for Retina display support in HTML email.

We all know that Microsoft Outlook 2010 and 2007 are crap for rendering HTML. WORD!
Exhibit A, Exhibit B There’s also a few other doosies out there too, checkout Campaign Monitor’s Guide to CSS Support in HTML Email Notice there’s a lot of those red “X’s”.

Tip #1: Design all “clicks” to be touch friendly!

Large “Touch Target Sizes” for images, links and buttons will ensure you are a humble champion. There is nothing more frustrating on a slow connection like having to wait for the wrong page to load! Touch Targe Sizes, Accessibility and Ergonomic Guidelines

 

Recommended Touch Size Areas, from 33px to 44px

 

Tip #2: Stunning images on iPhone Retina Display

First impressions are worth taking seriously even if they are a bit more on the subtle side. Will your subscribers stop receiving your emails if your logo is a bit choppy? Don’t compromise if the solution is within reach. I like this approach for supporting the higher resolution displays because all subscribers will see the same content. I aspire to the mantra of Progressive Enhancement. All users will see the ALT text and with images on a logo. If they happen to be using a high resolution display such as the iPhone Retina display they will see a super crisp version of the logo.

 

Support for the iPhone Retina Display

 

HTML

<span style="position: relative; display: block; height: 41px;"> <a href="#" class="logo-link" style="display: block; height: auto; color: #4C6A8B;font-weight: bold; text-decoration: none; text-align: left;"> <b></b> <img style="font-size: 20px; text-align: left; border: none; font-size: 14px; height: 41px; outline: none; text-decoration: none; font-weight: bold;" alt="text for image" height="41" width="200" src="#" /> </a> </span>

CSS

Note, you will have to update the image paths and dimensions to work with your content and design.

// Yahoo! Mail ignores any styles that use attribute selectors // this helps override it loading @media queries which it give // extreme precedence @media only screen and (-webkit-min-device-pixel-ratio : 1.5), only screen and (min-device-pixel-ratio : 1.5) { a[class = logo-link] b { background: url("http://logo.png") no-repeat 0 0; width: 200px; height: 41px; background-size: 100%; position: absolute; z-index: 10; display: block; } a.logo-link:after { content: "Estately"; position: absolute; top: 0; text-align: left; width: 200px; height: 41px; display: block; } span a[class=logo-link] img#estately { display: none; } }

Tip #3: Providing ALT text for background images

Simply add the CSS below to the media query outlined in Tip# 2. Here we are taking advantage of the CSS Pseudo Class :after and the CSS2 content property to add the ALT text for the high resolution imagery.

 

Progressive Enhancement: Alt text for high resolution images.

 

CSS

// Yahoo! Mail ignores any styles that use attribute selectors // this helps override it loading @media queries which it give // extreme precedence @media only screen and (-webkit-min-device-pixel-ratio : 1.5), only screen and (min-device-pixel-ratio : 1.5) { a.logo-link:after { content: "Alt text for Logo"; position: absolute; top: 0; text-align: left; width: 200px; height: 41px; display: block; } }

Tip #4: Prevent Webkit & Windows Mobile platforms from changing default font sizes

Mobile Safari has a default text size that’s greater than 100%, which can puff up your layout in ways you did not intend. There’s lots of advice out there that suggests by setting -webkit-text-size-adjust to none the problem is solved. There has been some good discussion around this topic and it’s worth reviewing so you don’t blindly implement the following suggestion. If you were to set the property to none desktop WebKit users would loose the capability to “zoom.”

 

Improve text sizing for mobile users while allowing desktop Webkit users to zoom the layout.

 

CSS

// Corrects font-size on mobile/handheld devices w/o preventing zooming // in WebKit browsers @media only screen and (min-device-width : 320px) and (max-device-width : 480px) { body { -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; } } @media only screen and (min-device-width: 768px) and (max-device-width: 1024px) { body { -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; } } @media only screen and (-webkit-min-device-pixel-ratio : 1.5), only screen and (min-device-pixel-ratio : 1.5) { body { -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; } }

Tip #5: Scaling Images, Responsive Design Approach

Email clients vary in their design and implementation so much. Some are based on antiquated rendering engines and others have umpteen layout options and overloaded “tool belts.” It’s anyones best guess just how much screen area your actual message will be given. I have choosen to use a combination of percentage widths with max-width settings to achieve a layout where images can scale up to 600 pixels wide and down to 350 pixels. It’s not perfect in all clients such as Outlook 2007 and 2010 but the content and utility of the layout are not compromised, while providing a optimal experience for the majority of email clients.

 

Responsive design for the desktop and handheld formats

 

HTML

<body style= "width:100% !important; max-width: 800px; background: #ffffff; margin: 0 auto; padding: 0; color: #4c4c4c; text-align: center;"> <table border= "0" cellpadding= "0" cellspacing= "0" align= "center" style= "width:100%; max-width:600px; background: #ffffff; font-family: Arial, Helvetica, Verdana;"> <tr> <td> <a href="#" style="width: 100%; max-width:600px;"> <img src="image.jpg" alt= 6 Photos border= "0" style= "border: none; font-weight: bold; height: auto; line-height: 100%; outline: none; text-decoration: none; text-transform: capitalize; -ms-interpolation-mode: bicubic; width:90%; text-align: center; background: #E6F1F8; font-family: Arial, Verdana; font-size: 16px;" /> </a> <td> <tr> <table> </body>

Tip #5.5: Make Internet Explorer Smooth

Internet Explorer’s default image scaling made your Pentium 266 work, but it today it just makes any scaled image look horrible. Make IE smoother and more sensual by setting image scaling for Internet Explorer to smooth: -ms-interpolation-mode: bicubic;

See CSS Tricks for image examples and further reading.

CSS

// If you use width or height tags to resize images in your markup, // IE will ensure they look incredibly awful unless you use this. -ms-interpolation-mode: bicubic; 

“You have mail” Demo

Hope the improvements and the code samples got you enthusiastic again about HTML Email. My goal is to help you communicate more effectively and provide the best experience possible for your design and subscribers. I certainly developed solutions for my design needs. You may find it necessary to adapt and explore tweaks and new solutions all together. If you come across any improvements or new solutions please let us know!

 

Demo

 

Guest Author Info

Josh works with the fine people of Estately, a comprehensive online real estate search for home buyers to shop and tour homes. Josh feeds upon the dynamic between design and development finding inspiration from both communities. When he’s not in front of the computer, you can find he and his wife working on their Seattle home.

this article originaly appeared here… webdesignerwall.com



W3C Invites Broad Review of HTML5

By SD Times Newswire

W3C today called for broad review of HTML5 and five related specifications that constitute the foundation of W3C’s Open Web Platform. At the heart of this platform, HTML5 offers powerful tools for creating Web-based applications that will run on any device. Due to the significant impact of this technology on industry and society, W3C is actively seeking feedback at this phase of the standards process.

“We’re seeing interest in HTML5 everywhere, and I am very excited that HTML5 has reached Last Call,” said Philippe Le Hégaret, the W3C manager responsible for HTML5, CSS, SVG, WOFF, and other user interaction technologies. “The HTML Working Group is W3C’s largest group with over 50 W3C Members and more than 200 invited experts. Reaching agreements in this large a community is a tremendous achievement.”

The W3C HTML Working Group invites broad review through 3 August, in particular on the priority open issues that are listed at the beginning of each document. The W3C HTML Working Group also invites contributions to the growing HTML test suite, an important instrument for achieving interoperability.

W3C also reconfirmed today that, as announced, these specifications are on track to become stable standards in 2014.

Broad Review to Help Resolve Outstanding Issues

By issuing a Last Call announcement, the HTML Working Group encourages people to comment on the extent to which they believe that technical requirements have been met and significant dependencies with groups inside and outside W3C have been satisfied. In September 2010, the HTML Working Group Chairs announced a plan and schedule to reach Last Call. Their plan included mechanisms to balance the community’s desire for timely completion with the need to give all issues due consideration. The HTML Working Group has resolved forty issues since October 2010, but a number of decisions—including several related to accessibility—remain to be addressed during this phase of the standards process.

“We now invite new voices to let us know whether these specifications address a broad set of needs,” said Tim Berners-Lee, W3C Director. “This process for resolving dependencies with other groups is a central part of our mission of ensuring the Web is well-designed, including being available to all. W3C staff will provide the HTML Working Group the support it needs to move forward, and to ensure that the specification meets W3C’s commitments in areas such as accessibility, internationalization, security, and privacy.

The HTML Working Group Chairs have published a timeline for Last Call through the next transition. More information can be found in a FAQ for the HTML5 Last Call.

Providing Feedback to the HTML Working Group

To provide feedback on any of the specifications published as Last Call Working Drafts, please see the instructions in the status section of each document:

• HTML5
• HTML+RDFa 1.1
• HTML Microdata
• HTML Canvas 2D Context
• Polyglot Markup: HTML-Compatible XHTML Documents
• HTML5: Techniques for providing useful text alternatives

The HTML Working Group published three additional documents today (not as Last Call drafts):

• HTML: The Markup Language Reference
• HTML5 diffs from HTML4
• HTML to Platform Accessibility APIs Implementation Guide



HTML 5 compliance: the next step

by Bruce Lawson and Stig Halvorsen

Ragnarök — viking browser with HTML5 parser!

Making its debut in a Labs build this week is Ragnarök, our implementation of the HTML5 Parsing algorithm. We’d love you to try to break this and give us feedback, so please grab a copy to install on your machine from one of the download links below.

The coolest HTML5 demo you’ll see this week

The Web is littered with <canvas> games, HTML5 video players, drag-and-drop whizz-bangs and other demos of HTML5 and “HTML5”. But here’s a really cool demo, probably the coolest you’ll see this week. Are you ready? Here goes:

<b><i>Yo!</b></i>

I can tell you’re impressed, so let’s dig deeper to see exactly why it is so cool. The elements are incorrectly nested: the innermost element – in this case, the <i> – should be the first one closed. What does this do to the DOM in different browsers?

We can check this out using Opera Dragonfly and its equivalents, or Ian Hickson’s DOM viewer. Internet Explorer 9 and Safari 5 result in this innerHTML:

<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>

<B><I>Yo!</I></B><I></I>
</BODY></html>

while Opera, Firefox and Chrome produce this:

<!DOCTYPE HTML>

<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B>
</BODY></html>

All the browsers have sorted out the mis-nesting, but inconsistently: note that IE and Safari have an additional empty <i> element that Opera, Firefox and Chrome don’t have. Which is correct? In an HTML4 world, both are. The HTML4 spec describes what to do with good markup, but not what to do with bad markup – and we know that 95% of the Web doesn’t validate. Therefore, browsers have traditionally been left to their own devices and forced to guess what to do with bad markup, as error-handling was never defined for HTML4.

Our simple markup above already produces very different DOMs, so imagine what would result from more real world examples of tag soup with dozens or hundreds of elements. Writing JavaScript that has to operate across browsers with such inconsistencies is a major cause of hair loss and weeping amongst web developers.

Luckily, there is now a solution to this.

The HTML5 parsing algorithm

The HTML5 specification defines a set of parsing rules for all markup, whether valid or invalid. Once all browsers have HTML5 parsers, the same markup will produce the same DOM across all conforming browsers. There are two main effects of this:

  • JavaScripters will sport cheerful grins and bouffant hair
  • Consumers can expect fewer interoperability problems when using their favourite site between browsers

So validation is a thing of the past, right?

Absolutely not. It’s still a vital QA tool, and just because the HTML5 parser will produce an interoperable DOM, it doesn’t mean it’s the DOM you actually want!

Opera’s implementation

Our old HTML parser has basically been the same since Opera began 15 years ago. It’s been continually patched to keep up with changing standards and countless different ways people came up with to not follow the specifications. After all the changes here and there, the code really started to look like a over-decorated christmas tree, and adding more stuff without knocking over the tree was getting increasingly hard.

With the decision to rewrite the entire parser came the opportunity to clean up the design significantly.

We can now proudly say that the new Ragnarök parser has a 99.9% pass-rate on an extensive test suite based on the html5lib tests for the parser part of the HTML 5 specification. The missing last 0.1% is going to be fixed before Ragnarök’s golden release. The test suite will also be publicly released once completed so that you can verify it yourself and compare Opera to the other browsers out there.

Ragnarök also scores 11 out of 11 (plus two bonus points) on the somewhat non-comprehensive (and therefore rather misleading) html5test.com. (The two bonus points are for parsing embedded SVG and MathML in HTML5.)

Memory consumption

The main reason we kept our old parser for so long was its efficient memory usage when handling bad markup. Instead of duplicating nodes like the HTML5 specification states, our parser had a intricate system of pointers that indicated which nodes should have been duplicated. This saved it from allocating memory to actually duplicating the element data, but also made the code that traversed the data structure more complex. Now we have switched to copying the nodes, it uses slightly more memory. Before the final release we will minimize that side effect — Opera has always been about memory efficiency, and working on smaller devices too.

Performance

It’s not obvious now, because this technical preview isn’t optimized for speed like the golden releases will be, but another advantage of the rewrite has been an increase in parser performance. Since the time taken parsing the markup of a page is relatively small compared to loading and rendering, this will not affect benchmarks dramatically, but all performance improvements are for the better, right?

Get it while it’s hot!

We have made some builds contain the new parser so that you can test it out, right now, and earn the right to brag to your friends that “Hah, I’ve been running that for quite some time now” when the final product is out in the stores in a short while.

Disclaimer: The builds are only meant as a technical preview of the new parser, and have not gone through the usual thorough testing our golden releases get, so they might be more unstable. The email client is not working properly so do not use it. The builds are not optimized for speed so don’t expect any useful results from performance benchmarks yet. Better stats will be available when the final version is out.



Articles

Categories

Connect

Web Hosting Specials

Partners