- Opera Mini: A 10-year journey of internet on a phone – “Our vision is still the same: get the web into the hands of everyone, regardless of their device.”
- Blink’s srcset selection logic just changed “due to complaints of quality issues related to the geometric-mean based resource selection.”
- On HTML belts and ARIA braces – The Default Implicit ARIA semantics they didn’t want you to know about. By Steve Faulkner.
- HTTP2 in 5 Minutes, Ben Maraney – 5 min YouTube video
- HTTP/2 is much faster than SPDY thanks to dependency-based prioritization
- Blowing up LocalStorage (or what happens when you exceed quota)
- W3C Technical Architecture Group review now part of Blink Intent-to-Ship guidelines says Alex Russell, TAG member and sinister mastermind at Google Chrome
- Talking of TAG, Statements about TAG Nominees for 2015 Special Election – Oiled torsos gleaming, their swords sharpened, daggers drawn & loincloths secure, the @w3ctag gladiators salute you.
- A/A Testing: How I increased conversions 300% by doing absolutely nothing – “Many of their businesses would be better off if they didn’t run any A/B tests at all … Meanwhile, a 300% increase on a conversion rate of 0% is still 0%. Ship the damn product”
- Infinite conference call – unmute your speakers, and enjoy.
Today the Web Payments Interest Group published the first draft of Web Payments Use Cases 1.0. As we progress toward an architecture for payments well-integrated into to the Open Web Platform, I am thinking about a visual identity for Web Payments. Here is a draft idea:
I hacked up the SVG by hand so it will surely need refinement in the next revision. While I like the idea of extending the HTML5 logo just a little bit to mean “Web Payments,” there are some issues. One is that the Web of course is more than HTML5. Also, a Web Payments architecture will be global and accommodate all currencies (not just the US dollar implied by the logo).
I hope with this post we will start the conversation about a visual identity for future W3C standards for Web Payments. I look forward to your comments!
I often get asked what resources I’d recommend for someone totally new to making websites. There are surprisingly few tutorials out there aimed at the complete beginner. There’s Jon Duckett’s excellent—and beautiful—book. There’s the Codebar curriculum (which I keep meaning to edit and update; it’s all on Github).
Now there’s a new resource by Damian Wielgosik called How to Code in HTML5 and CSS3. Personally, I would drop the “5” and the “3”, but that’s a minor quibble; this is a great book. It manages to introduce concepts in a logical, understandable way.
And it’s free.
HTML5 Doctor — On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about)
The question of whether HTML elements need the addition of ARIA
role attibutes to expose their semantics, is one that surfaces on a regular basis. The answer is maybe for a subset of elements, but increasingly no.
ARIA roles add nothing to default semantics of most elements
In some cases the semantics of a HTML element can be expressed by an ARIA role, state or property. This is fiendishly known as the element’s ‘Default Implicit ARIA semantics‘
None of the elements defined in HTML4 need ARIA roles added to expose their default semantics. Adding an ARIA role is extra work for no gain and could lead to pain for you or somebody else. The new features defined in HTML5 , where implemented, now have their default semantics exposed by most browsers.
The HTML5 Specification includes this note:
In the majority of cases setting an ARIA
aria-*attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.
Some examples of redundant ARIA
Adding default implicit roles to interactive elements listed in the HTML5 Recommendation is a waste of time:
Adding ARIA state or property attributes in addition to their native HTML counterparts is a waste of time:
<input type=”text” required
Adding ARIA roles and states or properties to long-implemented structural elements is a waste of time:
role=”heading” aria-level=”1″>heading text</h1>
What about the newish HTML5 structural elements?
HTML5 defined a new set of structural and sectioning elements with default implicit semantics that match ARIA roles (for some, only under certain conditions):
- article maps to role=article
- aside maps to role=complementary
- footer maps to role=contentinfo (if not within an article or section element)
- header maps to role=banner (if not within an article or section element)
- main maps to role=main
- nav maps to role=navigation
- section maps to role=region
What this means is that, where implemented, the browser will expose the default implicit semantics of the element so you don’t have to.
main element is the newest kid on the block, it no longer needs a role added as its accessibility semantics were implemented at the same time as the other aspects of it’s implementation in browsers (except in IE).
The default implicit semantics implementation story
For the the structural elements newly minted in HTML5, the story is overall a good one. We are at a stage where all modern browsers (that support accessibility) implement the default semantics (except IE and though late to the party, they are finally implementing).
In general, if it’s defined in the HTML5 Recommendation the feature does not need ARIA role, state and property attributes. So don’t do it, it’s just another point of code complexity and potential failure for no gain.
For the newish structural elements
Given the more robust support for structural element semantics (sans the outline algorithm aspect, but that’s another orthogonal story) I consider web developers should think about dropping the legacy HTML belt and ARIA braces approach. To that end HTML 5.1 is moving towards making all use of default implicit semantics as a SHOULD NOT normative requirement:
Default Implicit ARIA semantics – SHOULD NOT be used
This does not mean you can’t continue to, but is meant as a discouragement (think deprecation rather than obsolescence). So in the near future, if you check your HTML using a conformance checker, a warning will be flagged where it finds ARIA roles matching the default implict semantics of HTML elements.
For features defined in HTML 5.1, but not yet interoperably implemented
In some cases there are features absent from HTML5, but re-appear in HTML 5.1 (they were removed from HTML5 due to lack of implementations); details and summary or dialog elements are examples. For these elements it’s both fine and useful to add default semantics via ARIA as appropriate when using polyfils.
On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about) originally appeared on HTML5 Doctor on April 14, 2015.
That TV and video is moving to the web is not new — a recent report by Nielsen showed that the number of American households subscribing to an internet video streaming service is already 40%. However there are still areas where these services may not meet user expectations, for example when compared to the instant availability of broadcast TV or the full-featured extras in DVD releases. Equally, broadcasters are increasingly integrating the web into their services but these experiences often need to be more seamless to encourage broad adoption. There are also new ways to enjoy content that the web has the potential to realize, such as multiple simultaneous camera views or customizable synchronization with other online and data services.
There are several groups within W3C working to make this a reality and the entry point for this activity is the Web and TV Interest Group. It’s here where use cases and requirements are established and gaps in standards are identified. Most recently, the needs of video delivery on the web today include:
- Multi-screen content delivery
- Stream synchronization
- TV function and channel control
- Mixed media sources and content overlays
- Stream recognition and identification
- Server-side content rendering (e.g. for low-powered STBs)
- Improvements to existing features (e.g. adaptive streaming, timed text)
The incubator-style role of the Web and TV Interest Group has led to the creation and support of various groups that are aiming to address these issues and currently there are some exciting developments to be aware of and ideally participate in.
A young Task Force within the Web and TV Interest Group that has attracted a lot of attention, it has a broad focus of looking at all phases of the video life cycle: Capture → Edit → Package → Distribute → Find → Watch. The ultimate goal is to identify essential elements in digital video’s life cycle and features that would be appropriate for recommendation for standardization in the appropriate SDOs, not just W3C. To achieve this, the Task Force is currently gathering use cases and all members of the Web and TV Interest Group are welcome to join in the discussion. See the Task Force page for more.
Thanks to the contributions of a growing number of participants, an API to control TV-like content and features is taking shape with the hope of eventually producing a new standard for media devices, set-top-boxes and of course televisions. We’ve used existing TV APIs for reference but there’s still lots of work to do on the draft specification for it to one day become a standard. See the group page for more and to join.
The newest TV-related group looking at how to accurately synchronize media streams across the web. This could be friends on a train wanting to watch the same movie on their separate devices, laughing at the same time. Another use case is watching a sports event on a large screen and having a separate single player or athlete view on your phone or tablet. Some interesting demos have been presented to the group but it’s still early days and a great opportunity to influence its direction and deliverables. See the group page for more and to join.
This group is developing a specification defining how user agents should expose in-band tracks as HTML5 media element video, audio and text tracks. In other words, web applications would be able to access information (e.g. metadata, captions, translations, etc.) within media stream containers through the media element. The draft specification that the group is working on currently covers the following media stream container types:
- MPEG-2 Transport Stream (MPEG-2 TS) (video/mp2t)
- ISO Base Media File Format (ISOBMFF aka MP4) (*/mp4)
- WebM (*/webm)
- OGG (*/ogg)
- DASH (application/dash+xml)
Other formats could be considered in the future, such as RTP streams. . See the group page for more and to join.
Second Screen Presentation Community Group & Working Group
The Web and TV Interest Group also closely follows this work which is a good example of the evolution of an idea to a standard — it started as a proposal brought to W3C with a Community Group created for easy collaboration. A draft specification for displaying web content on secondary screens was edited and improved by a variety of stakeholders to the point where it formed the basis of a new Working Group. At this point it’s officially on the standards track and further stabilization should see it implemented and brought to a big screen new you. Meanwhile, the Community Group remains open to foster discussion and ideas for future features. See the Community Group page and the Working Group page for more.
These are just some of the recent developments and as you can see, now is a prime time for those wanting to influence and guide new standards that will affect video on the web worldwide.
In the past three weeks, we merged 170 pull requests.
Try it out! At the most recent meeting, we discussed making this the default UI for
If your favorite website looks wrong in Servo, you can help us figure out why! Glenn wrote up a detailed guide on getting started working on Servo’s layout code, with some useful tips for minimizing test cases. We are also working on automatic minimization via “abstract reftests”.
- We landed a Rust upgrade
- Glenn implemented a subset of the mozbrowser APIs and used these to make servo-shell work. This required a ton of iframe fixes.
- Patrick implemented CSS transitions
- Keegan pushed a rebased, remixed version of Clark’s zero-copy html5ever patch. With this PR, html5ever can locate tags and attributes in an input stream at 80 MB/s while keeping whole-process memory consumption to a few MB.
- Nicholas added support for fine-grained memory reporting, along with a tree-like prettified output
- Chris Paris landed
innerHTMLgetter and setter implementations that use html5ever.
- Mátyás added stroke and
arc()support to canvas, along with many other APIs
- Diego implemented the
drawImageAPI for canvas
- Matt McCoy added support for HTTP compression
- Yodalee implemented
- Sebastian implemented
- Zack added a shim for
- Ms2ger implemented a safer replacement for
- Manishearth added support for simple userscripts
- Jack fixed a memory leak in the flowtree
- hsavala made console.log messages appear in remote Firefox consoles
- Tetsuharu added support for unrestricted floating point WebIDL values
- Thiago implemented partial support for interacting with worker globals via remote devtools
- Brandon DeRosier
- Chris Double
- Connor Jennings
- Daniel Le
- Edward Cho
- Eric Hegnes
- Falco Hirschenberger
- Kyle Cesare
- Martin Schröder
- Md. Enzam Hossain
- Mikko Vanhatalo
- Ryan Leavengood
- Sebastian N. Fernandez
- Tim Cuthbertson
A visualization of parallel layout on servo-shell + /r/rust:
The colored boxes indicate which CPU core performed layout for each document node. The box
around the active tab spinner is askew, because the spinner is a still image styled with
We had meetings on March
16th and March
30th. We discussed
servo-shell, getting the PR queue under control, and restricting non-standard
<iframe mozbrowser>. We also talked about the status of Servo on
Android; there are now “nightly” APK builds but they don’t work
We’ve had a lot of discussions recently about the project’s goals and plans for Q2. After months of landing new features at an incredible rate, Q2 is going to focus more on details: performance improvements, fixing compatibility bugs, and paying down technical debt. We’d like to find websites / create demos that showcase Servo’s advantages in a way that’s relevant to users.
We’re also going to work on security. This means finding and fixing issues, but also documenting what we don’t fix yet. Josh is going to upgrade our ancient version of SpiderMonkey, which is important for security and for the future of Servo in general.
Here’s your Easter reading list. It’s more nourishing than chocolate eggs, and more toe-tapping than any Stravinsky spring-related ballet score.
- The Guardian has 560 million page views a month. So obviously, they implement responsive images. (yes, my favourite newspaper for the last 30 years..)
- Responsive Images 101, Part 5: Sizes – from Jason Grigsby’s excellent series of articles.
sizeswas the hardest part of the new RIMTs for me to understand.
- Beyond Media Queries — It’s Time to Get Elemental – the “wot?” and “why?” of Element Queries, the new @respimg frontier.
- Microsoft’s “Project Spartan” to support <img srcset> – so that’s all the responsive images shebang in Opera, Chrome, Firefox (from May). So far Spartan supports only the x descriptor, similar to Safari/iOS.
- Partnering with Adobe on new contributions to our web platform – Microsoft accepting commits to Spartan from a 3rd party. It’s not open source, but it could be the opening of Checkpoint Charlie.
- Blink to implement Pointer Events joining Firefox and IE. Wonder who’s missing?
- Blink: Shipping new CSS parser – Coming soon in Opera and Chrome. “On most stylesheets, the new parser performed 15-25% faster.”
- Flash’s slide into irrelevance – “The Flash plugin and the technology platform are dead, but the ideas and ambition of replacing the Web haven’t disappeared.” by Mike Davies.
- This API is so Fetching! – “The Fetch specification, which defines the API, nails down the semantics of a user agent fetching a resource.”
- Opera for Android 29 beta replaces off-road mode with a new Turbo mode, offering full HTML5 shiz & new compression
- TAG teleconference: CSS Regions Draft Feedback Can we do “CSS Regions” with “Houdini” (extensible CSS primitives) rather than new magic? ask your chums at W3C TAG
- The State of Video Codecs 2015 – “H.264 still accounts for most video encoding today, but HEVC/H.265 and VP9 are beginning to make noise. What will 2015 bring?”
- Designing For The Elderly: Ways Older People Use Digital Technology Differently
- Interaction Media Features and their potential (for incorrect assumptions) – a good Media Queries rant by the Kaiser of Cuddles, Patrick Lauke.
- CSS WG “[mediaqueries] Use-case for “viewing context” – interesting conversation r/e TV vs tablet. Also, bonus words of wisdom from Patrick Lauke.
- A Baseline for Front-End [JS] Developers: 2015 by Rebecca Murphy
- Gartner Says Worldwide Market for Refurbished Smartphones to Reach 120 Million Units by 2017
- +1 from the W3C TAG your friends at W3C TAG give Mr B. Obama a big thumbs-up for his plans to implement https on US government websites. It’s nice to see the most powerful people in the world agreeing with each other.
- When a SIM Card Goes From $2,000 to $1.50 – report on Myanmar (Burma)
- The $50 device that symbolizes a shift in North Korea – interesting Reuters report on the “notel”, a small portable media player used to watch DVDs or content stored on USB sticks that can be easily smuggled into the country and passed hand to hand, owned by up to half of urban North Koreans.
- China’s Man-on-the-Side Attack on GitHub – “Based on reports we’ve received, we believe the intent of this attack is to convince us to remove a specific class of content”.
- #WearTheRose tweet activated light up rose – Ruth John, who made me a crocheted mankini, makes a crocheted arduino-powered rose that lights up when someone tweets about rugby football.
- web in the woods: 2 days camping in Kent woods & a web conference. “5 main speakers, 5 lightning talks and fish ‘n’ chips” – 50 places only, and a pretty website (hover over the ‘book your tickets’ button)
TL;DR: Service Worker, a new Web API, can be used as a mean to re-engineering client-side web applications, and a departure from the single-page web application paradigm. Detail of realizing that is being experimented on Gaia and proposed. In Gaia, particularly, “hosted packaged app” is served as a new iteration of security model work to make sure Service Workers work with Gaia.
Last week, I spent an entire week, in face-to-face meetings, going through the technical plans of re-architecture Gaia apps, the web applications that powers the front-end of Firefox OS, and the management plan on resourcing and deployment. Given the there were only a few of developers in the meeting and the public promise of “the new architecture”, I think it’s make sense to do a recap on what’s being proposed and what are the challenges already foreseen.
Using Service Worker
Many things previously not possible can be done with the worker proxy. For starter, it could replace AppCache while keeping the flexibility of managing cache in the hand of the app. The “flexibility” bits is the part where it gets interesting — theologically everything not touching the DOM can be moved into the worker — effectively re-creating the server-client architecture without a real remote HTTP server.
The Gaia Re-architecture Plan
Indeed, that’s what the proponent of the re-architecture is aiming for — my colleagues, mostly whom based in Paris, proposed such architecture as the 2015 iteration/departure of “traditional” single-page web application. What’s more, the intention is to create a framework where the backend, or “server” part of the code, to be individually contained in their own worker threads, with strong interface definitions to achieve maximum reusability of these components — much like Web APIs themselves, if I understand it correctly.
It does not, however, tie to a specific front-end framework. User of the proposed framework should be free to use any of the strategy she/he feel comfortable with — the UI can be as hardcore as entirely rendered in WebGL, or simply plain HTML/CSS/jQuery.
The plan is made public on a Wiki page, where I expect there will be changes as progress being made. This post intentionally does not cover many of the features the architecture promise to unlock, in favor of fresh contents (as opposed of copy-edit) so I recommend readers to check out the page.
Technical Challenges around using Service Workers
There are two major technical challenges: one is the possible performance (memory and cold-launch time) impact to fit this multi-thread framework and it’s binding middleware in to a phone, the other is the security model changes needed to make the framework usable in Gaia.
To speak about the backend, “server” side, the one key difference between real remote servers and workers is one lives in data centers with endless power supply, and the other depend on your phone battery. Remote servers can push constructed HTML as soon as possible, but for an local web app backed by workers, it might need to wait for the worker to spin up. For that the architecture might be depend on yet another out-of-spec feature of Service Worker, a cache that the worker thread have control of. The browser should render these pre-constructed HTML without waiting for the worker to launch.
Without considering the cache feature, and considering the memory usage, we kind of get to a point where we can only say for sure on performance, once there is a implementation to measure. The other solution the architecture proposed to workaround that on low-end phones would be to “merge back” the back-end code into one single thread, although I personally suspect the risk of timing issues, as essentially doing so would require the implementation to simulate multi-threading in one single thread. We would just have to wait for the real implementation.
The security model part is really tricky. Gaia currently exists as packaged zips shipped in the phone and updates with OTA images, pinning the Gecko version it ships along with. Packaging is one piece of sad workaround since Firefox OS v1.0 — the primary reasons of doing so are (1) we want to make sure proprietary APIs does not pollute the general Web and (2) we want a trusted 3rd-party (Mozilla) to involve in security decisions for users by check and sign contents.
The current Gecko implementation of Service Worker does not work with the classic packaged apps which serve from an
app: URL. Incidentally, the
app: URL something we feel not webby enough so we try to get rid off. The proposal of the week is called “hosted packaged apps”, which serve packages from the real, remote Web and allow references of content in the package directly with a special path syntax. We can’t get rid of packages yet because of the reasons stated above, but serving content from HTTP should allow us to use Service Worker from the trusted contents, i.e. Gaia.
One thing to note about this mix is that a signed package means it is offline by default by it’s own right, and it’s updates must be signed as well. The Service Worker spec will be violated a bit in order to make them work well — it’s a detail currently being work out.
Technical Challenges on the proposed implementation
As already mentioned on the paragraph on Service Worker challenges, one worker might introduce performance issue, let along many workers. With each worker threads, it would imply memory usage as well. For that the proposal is for the framework to control the start up and shut down threads (i.e. part of the app) as necessary. But again, we will have to wait for the implementation and evaluate it.
The proposed framework asks for restriction of Web API access to “back-end” only, to decouple UI with the front-end as far as possible. However, having little Web APIs available in the worker threads will be a problem. The framework proposes to workaround it with a message routing bus and send the calls back to the UI thread, and asking Gecko to implement APIs to workers from time to time.
As an abstraction to platform worker threads and attempt to abstract platform/component changes, the architecture deserves special attention on classic abstraction problems: abstraction eventually leaks, and abstraction always comes with overhead, whether is runtime performance overhead, or human costs on learning the abstraction or debugging. I am not the expert; Joel is.
Technical Challenges on enabling Gaia
Arguably, Gaia is one of the topmost complex web projects in the industry. We inherit a strong Mozilla tradition on continuous integration. The architecture proposal call for a strong separation between front-end application codebase and the back-end application codebase — includes separate integration between two when build for different form factors. The integration plan, itself, is something worthy to rethink along to meet such requirement.
With hosted packaged apps, the architecture proposal unlocks the possibility to deploy Gaia from the Web, instead of always ships with the OTA image. How to match Gaia/Gecko version all the way to every Nightly builds is something to figure out too.
Given everything is in flux and the immense amount of work (as outlined above), it’s hard to achieve any of the end goals without prioritizing the internals and land/deploy them separately. From last week, it’s already concluded parts of security model changes will be blocking Service Worker usage in signed package — we’ll would need to identify the part and resolve it first. It’s also important to make sure the implementation does not suffer any performance issue before deploy the code and start the major work of revamping every app. We should be able to figure out a scaled-back version of the work and realizing that first.
If we could plan and manage the work properly, I remain optimistic on the technical outcome of the architecture proposal. I trust my colleagues, particularly whom make the architecture proposal, to make reasonable technical judgements. It’s been years since the introduction of single-page web application — it’s indeed worthy to rethink what’s possible if we depart from it.
The key here is trying not to do all the things at once, strength what working and amend what’s not, along the process of making the proposal into a usable implementation.
Edit: This post have since been modified to fix some of the grammar errors.
Bug 783846 landing in Nightly means that Firefox for Android users—starting in version 39—can finally paste into contenteditable elements, which is huge news for the mobile-html5-responsive-shadow-and-or-virtual-dom-contenteditable apps crowd, developers and users alike.
"That's amazing! Can I cut text from contenteditable elements too?", you're asking yourself. The answer is um no, because we haven't fixed that yet. But if you wanna help me get that working come on over to bug 1112276 and let's party. Or write some JS and fix the bug or whatever.
Fun fact, when I told my manager I was working on this bug in my spare time he asked, "…Why?". 🎉
Through discussions on whatwg, I learned (or I had just forgotten) about the
Refresh HTTP header. Let's cut strait to the syntax:
HTTP/1.1 200 OK Refresh: 5; url=http://www.example.org/fresh-as-a-summer-breeze
5means here 5 seconds.
url=gives the destination where the client should head after 5 seconds.
Simon Pieters (Opera) is saying in that mail:
I think Refresh as an HTTP header is not specified anywhere, so per spec
it shouldn't work. However I think browsers all support it, so it would be
good to specify it.
Eric Law (ex-Microsoft) has written about The Performance Impact of META REFRESH. If we express the previous HTTP header in HTML, we get:
<meta http-equiv="refresh" content="5;url=http://www.example.org/fresh-as-a-summer-breeze" />
In his blog post, Eric is talking about people using
refresh to… well refresh the page. He means loading the same exact page over and over again. And indeed it means for the browser to create a certain number of "unconditional and conditional HTTP requests to revalidate the page’s resources" for each reload (refresh).
On the Web Compatibility side of things, I see the
<meta http-equiv="refresh" …/> used quite often.
<meta http-equiv="refresh" content="0;url=http://example.com/there" />
0. Probably the result of sysadmins not willing to touch the configuration of the servers, and so front-end developers taking the lead to "fix it", instead of using
HTTP 302 or
HTTP 301. Anyway, it is something which is being used for most of the time, redirecting to another domain name or uri.
Refresh HTTP Header on the other hand, I don't remember seeing it that often.
Should it be documented?
Simon is saying: "it would be good to specify it." I'm not so sure. First things first.
Let's create a test, by making a page sending a
Header set Refresh "0;url=https://www.youtube.com/watch?v=sTJ1XwGDcA4"
HTTP/1.1 200 OK Accept-Ranges: bytes Connection: Keep-Alive Content-Length: 200 Content-Type: text/html; charset=utf-8 Date: Thu, 26 Mar 2015 05:48:57 GMT ETag: "c8-5122a67ec0240" Expires: Thu, 02 Apr 2015 05:48:57 GMT Keep-Alive: timeout=5, max=100 Last-Modified: Thu, 26 Mar 2015 05:37:05 GMT Refresh: 0;url=https://www.youtube.com/watch?v=sTJ1XwGDcA4
This should redirect to this Fresh page
- Yes - Firefox 36.0.4
- Yes - Opera 29.0.1795.26
- Yes - Safari 8.0.4 (10600.4.10.7)
- Yes - IE11
- Yes - Chrome (something) said Hallvord ;)
If someone could test for IE and Chrome at least.
On Mozilla bug tracker, there are a certain number of bugs around refresh. This bug about inline resources is quite interesting and might indeed need to be addressed if there was a documentation. The bug is what the browser should do when the
Refresh HTTP header is on an image included in a Web page (this could be another test). For now, the refresh is not done for inline resources. Then what about scripts, stylesheets, JSON files, HTML document in iframes, etc? For the
SetupRefreshURIFromHeader code, there are Web Compatibility hacks in the source code of Firefox. We can read:
// Also note that the seconds and URL separator can be either // a ';' or a ','. The ',' separator should be illegal but CNN // is using it."
// Note that URI should start with "url=" but we allow omission
// We've had at least one whitespace so tolerate the mistake // and drop through. // e.g. content="10 foo"
On Webkit bug tracker, I found another couple of bugs but about
meta refresh and not specifically
Refresh:. But I'm not sure it's handled by WebCore or if it's handled elsewhere in MacOSX (
NSURLConnection, …). If someone knows, tell me. I didn't explore yet the source code.
On Chromium bug tracker, another couple of bugs for
meta refresh, with some interesting such as this person complaining that a space doesn't work instead of a
;. This is also tracked on WebKit. Something like:
<meta http-equiv="refresh" content="0 url=http://example.com/there" />
Also what should be done with a relative URL.
<meta http-equiv="refresh" content="0;url=/there" />
But for Chromium, I have not found anything really specific to
Refresh header. I didn't explore yet the source code.
On Opera bug tracker, it is still closed. We tried to open it when I was working there, and it didn't work.
Competition Of Techniques
Then you can also imagine the hierarchy of commands in a case like this:
HTTP/1.1 301 Permanent Redirect Refresh: 0;url=http://example.net/refresh-header Location: http://example.net/location <!DOCTYPE html> <html> <title>Fresh</title> <meta http-equiv="refresh" content="0;url=http://example.net/meta" /> <body onload="document.location.replace('http://example.net/body')"> </body> </html>
My guess is the
301 always win with the
Location HTTP header, or at least it's what I hope.
I can find very early references of
meta refresh such as in Netscape Developer documentation.
The earliest mention seems to be An Exploration Of Dynamic Documents I can't find anywhere the documentation for
Refresh HTTP header on old Netscape Web sites. (Thanks to SecuriTeam Web site and Amit Klein)
So another thing you obviously want to do, in addition to causing the current document to reload, is to cause another document to be reloaded in n seconds in place of the current document. This is easy. The HTTP response header will look like this:
Refresh: 12; URL=http://foo.bar/blatz.html
In June 1996, Jerry Jongerius posted about HTTP/1.1 Refresh header field comments
My concern with "Refresh" is that I do not want it to be a global concept (a browser can only keep track of one refresh)--it looks to be implemented this way in Netscape 2.x. I would like "Refresh" to apply to individual objects (RE: the message below to netscape).
which Roy T. Fielding replied to:
Refresh is no longer in the HTTP/1.1 document -- it has been deferred to HTTP/1.2 (or later).
Should it be documented? Well, there are plenty of issues, there are plenty of hacks around it. I have just touched the surface of it. Maybe it would be worth to document indeed how it is working as implemented now and how it is supposed to be working when there's no interoperability. If I was silly enough, maybe I would do this. HTTP, Archeology and Web Compatibility issues that seems to be close enough from my vices.
Today we’re excited to host some of our top web site partners, enterprise developers and web framework authors at the Microsoft Silicon Valley campus for a "Project Spartan" developer workshop to get an early look at Windows 10’s new default browsing experience as it rapidly approaches a public preview. This is another step in our renewed focus on reaching out and listening to the developer community we depend on, in keeping with the focus on openness and feedback-driven development that is driving initiatives like status.modern.ie and our Windows Insider Program.
If you’re interested in attending a similar event to learn more about “Project Spartan,” there are some great opportunities coming up. We’ll have lots to say about Project Spartan at Build 2015 (April 29th – May 1st in San Francisco) and Microsoft Ignite (May 4th – 8th in Chicago). We’re also excited to announce an all-new Windows 10 Web Platform Summit hosted by the Project Spartan team, which will be open to the public on May 5-6, 2015 at the Microsoft Silicon Valley Campus. Stay tuned to the blog and @IEDevChat for more information on how to register!
A simpler browser strategy in Windows 10
One of the items we’re discussing in today’s workshop is how we are incorporating feedback from the community into the work we are doing on Project Spartan, including some updates we are making related to the rendering engines. When we announced Project Spartan in January, we laid out a plan to use our new rendering engine to power both Project Spartan and Internet Explorer on Windows 10, with the capability for both browsers to switch back to our legacy engine when they encounter legacy technologies or certain enterprise sites.
However, based on strong feedback from our Windows Insiders and customers, today we’re announcing that on Windows 10, Project Spartan will host our new engine exclusively. Internet Explorer 11 will remain fundamentally unchanged from Windows 8.1, continuing to host the legacy engine exclusively.
We’re making this change for a number of reasons:
- Project Spartan was built for the next generation of the Web, taking the unique opportunity provided by Windows 10 to build a browser with a modern architecture and service model for Windows as a Service. This clean separation of legacy and new will enable us to deliver on that promise. Our testing with Project Spartan has shown that it is on track to be highly compatible with the modern Web, which means the legacy engine isn’t needed for compatibility.
- For Internet Explorer 11 on Windows 10 to be an effective solution for legacy scenarios and enterprise customers, it needs to behave consistently with Internet Explorer 11 on Windows 7 and Windows 8.1. Hosting our new engine in Internet Explorer 11 has compatibility implications that impact this promise and would have made the browser behave differently on Windows 10.
- Feedback from Insiders and developers indicated that it wasn’t clear what the difference was between Project Spartan and Internet Explorer 11 from a web capabilities perspective, or what a developer would need to do to deliver web sites for one versus the other.
We feel this change simplifies the role of each browser. Project Spartan is our future: it is the default browser for all Windows 10 customers and will provide unique user experiences including the ability to annotate on web pages, a distraction-free reading experience, and integration of Cortana for finding and doing things online faster. Web developers can expect Project Spartan’s new engine to be interoperable with the modern Web and remain “evergreen” with no document modes or compatibility views introduced going forward.
For a small set of sites on the Web that were built to work with legacy technologies, we’ll make it easy for customers to access that site using Internet Explorer 11 on Windows 10. Enterprises with large numbers of sites that rely on these legacy technologies can choose to make Internet Explorer 11 the default browser via group policy. In addition, since Internet Explorer 11 will now remain fundamentally unchanged from Windows 7 and Windows 8.1, it will provide a stable and predictable platform for enterprise customers to upgrade to Windows 10 with confidence.
Call to action for developers
Our request to web developers remains the same – try out and test our new rendering engine in the Windows 10 Technical Preview via the Windows Insider Program or via RemoteIE. It is currently hosted in Internet Explorer and can activated via the “Enable experimental web platform features” setting in about:flags. Starting in the next flight to Insiders, the new rendering engine will be removed from IE and available exclusively within Project Spartan.
We look forward to your feedback – you can reach us on Twitter at @IEDevChat, the Internet Explorer Platform Suggestion Box on UserVoice, and in the comments below. Remember to mark your calendars for our next Project Spartan developer event on May 5th – 6th in Silicon Valley. We look forward to sharing more details soon!
– Kyle Pflug, Program Manager, Project Spartan
In recent releases, we’ve talked often about our goal to bring the team and technologies behind our web platform closer to the community of developers and other vendors who are also working to move the Web forward. This has been a driving motivation behind our emphasis on providing better developer tools, resources for cross-browser testing, and more ways than ever to interact with the "Project Spartan" team.
In the same spirit of openness, we’ve been making changes internally to allow other major Web entities to contribute to the growth of our platform, as well as to allow our team to give back to the Web. In the coming months we’ll be sharing some of these stories, beginning with today’s look at how Adobe’s Web Platform Team has helped us make key improvements for a more expressive Web experience in Windows 10.
Adobe is a major contributor to open source browser engines such as WebKit, Blink, and Gecko. In the past, it was challenging for them (or anyone external to Microsoft) to make contributions to the Internet Explorer code base. As a result, as Adobe improved the Web platform in other browsers, but couldn't bring the same improvements to Microsoft's platform. This changed a few months ago when Microsoft made it possible for the Adobe Web Platform Team to contribute to Project Spartan. The team contributes in the areas of layout, typography, graphic design and motion, with significant commits to the Web platform. Adobe engineers Rik Cabanier, Max Vujovic, Sylvain Galineau, and Ethan Malasky have provided contributions in partnership with engineers on the IE team.
Adobe contributions in the Windows 10 March Technical Preview
The Adobe Web Platform Team hit a significant milestone with their first contribution landing in the March update of the Windows 10 Technical Preview! The feature is support for CSS gradient midpoints (aka color hints) and is described in the upcoming CSS images spec. With this feature, a Web developer can specify an optional location between the color stops of a CSS gradient. The color will always be exactly between the color of the 2 stops at that point. Other colors along the gradient line are calculated using an exponential interpolation function as described by the CSS spec.
linear-gradient(90deg, black 0%, 75%, yellow 100%)
radial-gradient(circle, black 0%, 75%, yellow 100%)
You can check this out yourself on this CSS Gradient Midpoints demo page. Just install the March update to Windows 10 Technical Preview and remember to enable Experimental Web Platform Features in about:flags to enable the new rendering engine. This change will bring IE to the same level as WebKit Nightly, Firefox beta and Chrome.
Another change that Adobe has recently committed is full support for <feBlend> blend modes. The W3C Filter Effects spec extended <feBlend> to support all blend modes per the CSS compositing and blending specification. Our new engine will now support these new values like the other major browsers.
New blend modes expand existing values normal, multiply, screen, overlay, darken and lighten with color-dodge, color-burn, hard-light, soft-light, difference, exclusion, hue, saturation, color and luminosity.
To use the new modes just specify the desired mode in the <feBlend> element. For example:
<feBlend mode='luminosity' in2='SourceGraphic' />
Internet Explorer 11
You can try this out today at Adobe's CodePen demo in Internet Explorer on the Windows 10 Technical Preview by selecting "Enable Experimental Web Platform Features" under about:flags.
We are just getting started
Congratulations to the Adobe Web Platform Team on their first commit! We are looking forward to a more expressive Web and moving the Web platform forward! Let us know what you think via @IEDevChat or in the comments below.
— Bogdan Brinza, Program Manager, Project Spartan
We are excited and proud of announcing WebKitGTK+ 2.8.0, your favorite web rendering engine, now faster, even more stable and with a bunch of new features and improvements.
Touch support is one the most important features missing since WebKitGTK+ 2.0.0. Thanks to the GTK+ gestures API, it’s now more pleasant to use a WebKitWebView in a touch screen. For now only the basic gestures are implemented: pan (for scrolling by dragging from any point of the WebView), tap (handling clicks with the finger) and zoom (for zooming in/out with two fingers). We plan to add more touch enhancements like kinetic scrolling, overshot feedback animation, text selections, long press, etc. in future versions.
Notifications are transparently supported by WebKitGTK+ now, using libnotify by default. The default implementation can be overridden by applications to use their own notifications system, or simply to disable notifications.
WebView background color
There’s new API now to set the base background color of a WebKitWebView. The given color is used to fill the web view before the actual contents are rendered. This will not have any visible effect if the web page contents set a background color, of course. If the web view parent window has a RGBA visual, we can even have transparent colors.
A new WebKitSnapshotOptions flag has also been added to be able to take web view snapshots over a transparent surface, instead of filling the surface with the default background color (opaque white).
User script messages
Let’s see how it works with a very simple example:
webkit_user_content_manager_register_script_message_handler (user_content, "foo"); g_signal_connect (user_content, "script-message-received::foo", G_CALLBACK (foo_message_received_cb), NULL);
webkit_dom_dom_window_webkit_message_handlers_post_message (dom_window, "foo", "bar");
Who is playing audio?
WebKitWebView has now a boolean read-only property is-playing-adio that is set to TRUE when the web view is playing audio (even if it’s a video) and to FALSE when the audio is stopped. Browsers can use this to provide visual feedback about which tab is playing audio, Epiphany already does that
HTML5 color input
Color input element is now supported by default, so instead of rendering a text field to manually input the color as hexadecimal color code, WebKit now renders a color button that when clicked shows a GTK color chooser dialog. As usual, the public API allows to override the default implementation, to use your own color chooser. MiniBrowser uses a popover, for example.
APNG (Animated PNG) is a PNG extension that allows to create animated PNGs, similar to GIF but much better, supporting 24 bit images and transparencies. Since 2.8 WebKitGTK+ can render APNG files. You can check how it works with the mozilla demos.
The POODLE vulnerability fix introduced compatibility problems with some websites when establishing the SSL connection. Those problems were actually server side issues, that were incorrectly banning SSL 3.0 record packet versions, but that could be worked around in WebKitGTK+.
WebKitGTK+ already provided a WebKitWebView signal to notify about TLS errors when loading, but only for the connection of the main resource in the main frame. However, it’s still possible that subresources fail due to TLS errors, when using a connection different to the main resource one. WebKitGTK+ 2.8 gained WebKitWebResource::failed-with-tls-errors signal to be notified when a subresource load failed because of invalid certificate.
Ciphersuites based on RC4 are now disallowed when performing TLS negotiation, because it is no longer considered secure.
Performance: bmalloc and concurrent JIT
bmalloc is a new memory allocator added to WebKit to replace TCMalloc. Apple had already used it in the Mac and iOS ports for some time with very good results, but it needed some tweaks to work on Linux. WebKitGTK+ 2.8 now also uses bmalloc which drastically improved the overall performance.
Concurrent JIT was not enabled in GTK (and EFL) port for no apparent reason. Enabling it had also an amazing impact in the performance.
Both performance improvements were very noticeable in the performance bot:
The first jump on 11th Feb corresponds to the bmalloc switch, while the other jump on 25th Feb is when concurrent JIT was enabled.
Plans for 2.10
WebKitGTK+ 2.8 is an awesome release, but the plans for 2.10 are quite promising.
- More security: mixed content for most of the resources types will be blocked by default. New API will be provided for managing mixed content.
- Sandboxing: seccomp filters will be used in the different secondary processes.
- Even more performance: this time in the graphics side, by using the threaded compositor.
- Blocking plugins API: new API to provide full control over the plugins load process, allowing to block/unblock plugins individually.
- Implementation of the Database process: to bring back IndexedDB support.
- Editing API: full editing API to allow using a WebView in editable mode with all editing capabilities.
Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Send me an email! Want to get involved? We love contributions.
What's cooking on master?
Now you can follow breaking changes as they happen!
- Fixed-size byte string literals. RFC.
- allow inherent implementations on primitives, remove some extension traits.
- Deprecate range, range_step, count, distributions.
- Remove old_io and old_path from the prelude.
- Require braces when a closure has an explicit return type.
- Johannes Oertel
- Paul ADENOT
- Sae-bom Kim
- Tero Hänninen
- RFC 529: Generic conversion traits.
- RFC 803: Type ascription.
- RFC 909: Move
- RFC 921: Entry API v3.
- RFC 940: Disallow hyphens in crate names.
- RFC 968: Tweak closure return type syntax.
- Add std::env::concurrency_hint.
- Make type ascription expressions lvalues.
- Function pointers reform.
- Allow unstable features in 1.0.
- Would Rust have prevented Heartbleed? Another look. Bascule comes to Rust's defense! /r/rust. HN.
- Rust infrastructure can be your infrastructure.
- Weekly-meetings/2015-03-17. Checked overflow and casts; hyphens in crate names.
- Rust programming language presentation at Sungkyunkwan University, South Korea.
- What is Rust bad at?
- Roguelike game architecture in Rust, parts 1, 2, 3.
- Using Rust from the Unreal engine.
- gfx_scene. High-level rendering for gfx-rs.
- glium project update, march edition.
- html5ever project update: one year!.
- capnproto-rust: error handling revisited. David Renshaw has recently modernized Cap'n'Proto's error handling.
- google-apis-rs has been relased with bindings for many Google APIs.
- rust-backtrace. Klutzy is implementing backtracing in Rust.
- Playform gets voxel terrain and even better voxel terrain.
Quote of the Week
<mbrubeck> the 5 stages of loss and rust <mbrubeck> 1. type check. 2. borrow check. 3. anger. 4. acceptance. 5. rust upgrade
Thanks to jdm for the tip. Submit your quotes for next week!.
You may have some memory of selecting between high and low quality on YouTube. When you switched it would stop the video and buffer the video at the new quality. Now it defaults to Auto but allows you to manually override. You may have noticed that the Auto mode doesn't stop playing when it changes quality. Nobody really noticed, but a tiny burden was lifted from users. You need to know exactly one less thing to watch videos on YouTube and many other sites.
It has taken a surprising amount of work to make this automatic. My team has been working on adding MSE to Firefox for a couple of years now as well as adding MP4 support on a number of platforms. We're finally getting to the point where it is working really well on Windows Vista and later in Firefox 37 beta. I know people will ask, so MSE is coming soon for Mac, and it is coming later for Linux and Windows XP.
Making significant changes isn't without its pain but it is great to finally see the light at the end of the tunnel. Firefox beta, developer edition and nightly users have put up with a number of teething problems. Most of them have been sorted out. I'd like to thank everyone who has submitted a crash report, written feedback or filed bugs. It has all helped us to find problems and make the video experience better.
Robustness goes further than simply fixing bugs. To make something robust it is necessary to keep simplifying the design and to create re-usable abstractions. We've switched to using a thread pool for decoding, which keeps the number of threads down. Threads use a lot of address space, which is at a premium in a 32 bit application.
We're working towards getting all the complex logic on a single thread, with all the computation done in a thread pool. Putting the video playback machinery on a single thread makes it much clearer which operations are synchronous and which ones are asynchronous. It doesn't hurt performance as long as the state machine thread never blocks. In fact you get a performance win because you avoid locking and cache contention.
We're white listing MSE for YouTube at first but we are intending to roll it out to other sites soon. There are a couple of spec compliance issues that we need to resolve before we can remove the white list. Meanwhile, YouTube is looking really good in Firefox 37.
People regularly ask me what I am working on at the W3C, here is a run down of standards/guidance documents I am editing/co-editing, contributing to (note: I am only 1 of the people at The Paciello Group involved directly in standards development at the W3C)
This specification defines the 5th major version, first minor revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). Editing updates to and maintenance of (mainly) accessibility related advice and requirements, with an emphasis on information for web developers.
HTML5.1 specification module defining the web developer rules for the use of ARIA attributes on HTML 5.1 elements. It also defines requirements for Conformance Checking tools. In HTML 5.1 this spec replaces the web developer (author) conformance requirements in section 3.2.7 WAI-ARIA of the HTML5 spec (titled 3.2.7 WAI-ARIA and HTML Accessibility API Mappings in HTML 5.1).
Defines how user agents map HTML 5.1 elements and attributes to platform accessibility application programming interfaces (APIs). this spec replaces (and extends to all HTML elements/attributes) the user agent implementation requirements in section 3.2.7 WAI-ARIA of the HTML5 Recommendation (titled 3.2.7 WAI-ARIA and HTML Accessibility API Mappings in HTML 5.1).
This specification defines the web developer (author) rules (conformance requirements) for the use of ARIA attributes on SVG 1.1 elements. It also defines the requirements for Conformance Checking tools.
This specification describes the method for enabling the author to define and use new types of DOM elements in a document.
Editing the Custom Element Semantics section of the specification.
This document contains best practice guidance for authors of HTML documents on providing text alternatives for images. Edited until October 2104, the bulk of this document is included in the HTML5 and HTML 5.1 specifications under section 220.127.116.11 Requirements for providing text to act as an alternative for images where I continue to update and maintain.
This document is a practical guide for developers on how to add accessibility information to HTML elements using the Accessible Rich Internet Applications (ARIA) specification.
Based on feedback from Windows Insiders, we are working to release preview builds more often. Today we flighted the first update to Insiders on this accelerated cadence, which includes the latest updates to our new rendering engine. Due to the change in cadence, this build does not yet include the Project Spartan preview, which will be available in the next release.
Today’s build has a number of updates to the new engine, including new features and improvements to existing features. Some of these include:
- Improved ECMAScript 6 compatibility (up to 74% in the Kangax ES6 compatibility test in this preview)
- Expanded support for DOM L3 XPath
- Support for WAI-ARIA Landmark Roles
- Support for CSS Conditional Rules (@Supports)
- Support for the Web Audio API
- Support for CSS Gradient Midpoints (aka color hints)
- Improved FeBlend mode support
- Unprefixed support for the Fullscreen API
- Support for the Touch Events API and related interoperability improvements. Touch Events are enabled when a touchscreen is present, and can be enabled under about:flags.
In addition, you may notice some features partially implemented and available for testing in Internet Explorer under about:flags. These features are under active development and will continue to evolve in future preview builds.
- Support for the HTML5 Date-Related Inputs API. This is off by default and can be enabled in about:flags. Improved accessibility is coming in a future build.
- Partial support for CSS Transitions & Animations on SVG elements
- A toggle for the CSS Filters API is available in about:flags but the feature is not yet implemented in this build.
Watch this space over the next week as we’ll be diving into these in more detail in a series of individual posts. In the meantime, you can try these improvements out in the latest preview by signing up for the Windows Insiders program and joining the “Fast” update ring. To enable the new engine in Internet Explorer on preview builds, navigate to about:flags and select “Enable experimental Web platform features.” We'll also be updating RemoteIE with the new preview soon. Don’t forget to share your feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.
– Kyle Pflug, Program Manager, Project Spartan
Since the HTML design principles (which are effectively design principles for modern Web technology) were published, I've thought that the priority of constituencies was among the most important. It's certainly among the most frequently cited in debates over Web technology. But I've also thought that it was wrong in a subtle way.
I'd rather it had been phrased in terms of utility, so that instead of stating as a rule that value (benefit minus cost) to users is more important than value to authors, it recognized that there are generally more users than authors, which means that a smaller value per user multiplied by the number of users is generally more important than a somewhat larger value per author, because it provides more total value when the value is multiplied by the number of people it applies to. However, this doesn't hold for a very large difference in value, that is, one where multiplying the cost and benefit by the numbers of people they apply to yields results where the magnitude of the cost and benefit control which side is larger, rather than the numbers of people. The same holds for implementors and specification authors; there are generally fewer in each group. Likewise, the principle should recognize that something that benefits a very small portion of users doesn't outweigh the interests of authors as much, because the number of users it benefits is no longer so much greater than the number of authors who have to work to make it happen.
Also, the current wording of the principle doesn't consider the scarcity of the smaller groups (particularly implementors and specification authors), and thus the opportunity costs of choosing one behavior over another. In other words, there might be a behavior that we could implement that would be slightly better for authors, but would take more time for implementors to implement. But there aren't all that many implementors, and they can only work on so many things. (Their number isn't completely fixed, but it can't be changed quickly.) So given the scarcity of implementors, we shouldn't consider only whether the net benefit to users is greater than the net cost to implementors; we should also consider whether there are other things those implementors could work on in that time that would provide greater net benefit to users. The same holds for scarcity of specification authors. A good description of the principle in terms of utility would also correct this problem.