DOCSLIB.ORG

Formal Foundations for Provably Safe Web Components

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Foundations for Provably Safe Web Components Formal Foundations for Provably Safe Web Components By: Michael Stefan Herzberg A thesis submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy The University Of Sheffield Faculty of Engineering Department of Computer Science Submission Date: 11th December, 2019 Abstract One of the cornerstones of modern software development that enables the creation of sophisticated software systems is the concept of reusable software components. Especially the fast-paced and business-driven web ecosystem is in need of a robust and safe way of reusing components. As it stands, however, the concepts and functions needed to create web components are spread out, immature, and not clearly defined, leaving much room for misunderstandings. To improve the situation, we need to look at the core of web browsers: the Document Object Model (DOM). It represents the state of a website with which users and client-side code (JavaScript) interact. Being in this central position makes the DOM the most central and critical part of a web browser with respect to safety and security, so we need to understand exactly what it does and which guarantees it provides. A well- established approach for this kind of highly critical system is to apply formal methods to mathematically prove certain properties. In this thesis, we provide a formal analysis of web components based on shadow roots, highlight their short-comings by proving them unsafe in many circumstances, and propose suggestions to provably improve their safety. In more detail, we build a formalisation of the Core DOM in Isabelle/HOL into which we introduce shadow roots. Then, we extract novel properties and invariants that improve the often implicit assumptions of the standard. We show that the model complies to the standard by symbolically evaluating all relevant test cases from the official compliance suite successfully onour model. We introduce novel definitions of web components and their safety and classify the most important DOM API accordingly, by which we uncover surprising behavior and shortcomings. Finally, we propose changes to the DOM standard by altering our model and proving that the safety of many DOM API methods improves while leading to a less ambiguous API. i Declaration I, the author, confirm that the Thesis is my own work. I am aware of the University’s Guidance on the Use of Unfair Means (www.sheffield.ac.uk/ssid/unfair-means). This work has not been previously been presented for an award at this, or any other, university. Publications arising from this thesis: 1. Achim D. Brucker and Michael Herzberg. ‘A Formal Semantics of the Core DOM in Isabelle/HOL’. in: Companion Proceedings of the The Web Conference 2018. WWW 1́8. Lyon, France: International World Wide Web Conferences Steering Committee, 2018, pp. 741–749. isbn: 978-1-4503-5640-4. doi: 10.1145/3184558.3185980 2. Achim D. Brucker and Michael Herzberg. ‘Formalizing (Web) Standards - An Application of Test and Proof’. In: Tests and Proofs - 12th International Conference, TAP 2018, Held as Part of STAF 2018, Toulouse, France, June 27-29, 2018, Proceedings. Ed. by Catherine Dubois and Burkhart Wolff. Vol. 10889. Lecture Notes in Computer Science. Springer, 2018, pp. 159–166. doi: 10.1007/978-3- 319-92994-1_9 3. Achim D. Brucker and Michael Herzberg. ‘A Formally Verified Model of Web Components’. In: Formal Aspects of Component Software - 16th International Con- ference on Formal Aspects of Component Software, 23-25 October 2019, Amsterdam, Proceedings. 2019 4. Achim D. Brucker and Michael Herzberg. ‘The Core DOM’. in: Archive of Formal Proofs (2018). https://www.isa-afp.org/entries/Core_DOM.html, Formal proof development. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x 5. Achim D. Brucker and Michael Herzberg. ‘Shadow DOM: A Formal Model of the Document Object Model with Shadow Roots’. In: Archive of Formal Proofs (28th Sept. 2020). Formal proof development. Submitted. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x 6. Achim D. Brucker and Michael Herzberg. ‘A Formalization of Web Components’. In: Archive of Formal Proofs (28th Sept. 2020). Formal proof development. Submitted. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x 7. Achim D. Brucker and Michael Herzberg. ‘The Safely Composable DOM’. in: Archive of Formal Proofs (28th Sept. 2020). Formal proof development. Submitted. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x iii 8. Achim D. Brucker and Michael Herzberg. ‘Shadow SC DOM: A Formal Model of the Safelty Composable Document Object Model with Shadow Roots’. In: Archive of Formal Proofs (28th Sept. 2020). Formal proof development. Submitted. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x 9. Achim D. Brucker and Michael Herzberg. ‘A Formalization of Safely Composable Web Components’. In: Archive of Formal Proofs (28th Sept. 2020). Formal proof development. Submitted. A snapshot taken at thesis submission time can be found under [21]. issn: 2150-914x iv Acknowledgements I would like to express my sincere gratitude to: • My supervisor Achim Brucker, who spent countless hours introducing me to Isa- belle/HOL and the world of academia, and who never grew tired of just another round of revising drafts. • My thesis panel, Anthony Simons and Eleni Vasilaki, who gave valuable suggestions throughout my PhD and helped keeping me on track. • The Isabelle group at the University of Sheffield, who always gave valuable technical and moral support and broadened my understanding of the many uses of the tool. • The Department of Computer Science of the University of Sheffield, whose scholar- ship supported me throughout my research and enabled me to travel to conferences. • All the anonymous reviewers of my conference papers, who gave helpful feedback. • All my friends and family, who provided all kinds of support and encouragement. v Contents 1 Introduction 1 1.1 Motivation . 1 1.2 Contributions . 3 1.3 Thesis Structure . 4 1.4 Externally Reviewed Parts . 4 2 Background 7 2.1 Isabelle/HOL . 7 2.1.1 Basic Definitions . 7 2.1.2 Extending Logics . 8 2.1.3 Monads . 9 2.1.4 Locales . 10 2.1.5 Code Generator . 12 2.2 Web Standards . 13 2.2.1 Document Object Model (DOM) . 13 2.2.2 Hypertext Markup Language (HTML) and JavaScript . 14 3 A Formal Core DOM: fDOM 15 3.1 The Core DOM Data Model . 15 3.1.1 Classes as Datatypes . 17 3.1.2 Pointer datatypes . 21 3.2 Defining Operations and Queries on Node-Trees . 24 3.3 Well-Formedness of the DOM Heap . 30 3.3.1 Node Sharing . 30 3.3.2 The Owner Document . 31 3.3.3 Restricting DOMs to Trees . 32 3.3.4 Pointer Validity . 32 3.3.5 Heaps are Strongly Typed . 33 3.3.6 Well-Formed Heaps . 33 3.4 Reasoning over the DOM . 33 3.4.1 Locality of Heap Modifications . 34 3.4.2 Exceptions and Non-Termination . 37 3.4.3 Functional Correctness . 38 3.4.4 Well-Formedness of the Heap Methods . 44 4 A DOM with Shadow Roots 47 4.1 Motivating Example . 48 vii Contents 4.2 Data Model and Basic Accessors . 52 4.3 Graph Relations . 56 4.4 Heap Invariants . 57 4.5 Interfacing Shadow Trees: Slotting . 59 4.6 Flattening Shadow Trees . 63 5 Compliance to the Standard 65 5.1 Formal Software Standards . 65 5.2 Selecting Test Cases . 67 5.3 Translating Test Cases . 70 5.4 Beyond Compliance: Enhancing the Specification . 71 6 A New Notion of Web Components 77 6.1 A Formal Definition of Web Components . 77 6.1.1 Definition . 77 6.1.2 Different Kinds of DOM-Components . 78 6.1.3 Properties of DOM-Components . 79 6.2 Definition of DOM-Component Safety . 81 6.2.1 Strong DOM-Component Safety . 82 6.2.2 Weak DOM-Component Safety . 83 6.3 Component Safety Classification of the DOM Methods . 84 6.3.1 Getters and Simple Recursive DOM Methods . 84 6.3.2 Constructors . 86 6.3.3 Shadow Root Methods . 88 6.3.4 Heap-Modifying and Global Methods . 89 7 Beyond the Standard: Safe Web Components 91 7.1 Making the DOM Safely Composable . 91 7.1.1 Data Model . 92 7.1.2 Heap Invariants . 92 7.1.3 Methods . 93 7.2 A New Kind of Component . 95 7.3 General Properties of SCDOM-Components . 98 7.4 Updated DOM Method Classification . 99 8 Related Work 103 8.1 Formal Models of Software Standards . 103 8.2 Program Verification . 104 8.3 Formal Approaches to Object-Orientation . 105 8.4 Iframes and Shadow Roots . 105 8.5 Components in General . 106 9 Conclusion and Future Work 107 Bibliography 109 viii List of Figures 2.1 A Simple DOM Instance . 13 3.1 Alternative, Purely Functional Data Model . 16 3.2 Core DOM IDL Specification . 18 3.3 Type Hierarchy . 18 3.4 Data Model Attribute Example . 19 3.5 Example of a Formal DOM Instance . 23 3.6 Formal Types of the DOM API . 25 3.7 Description of Pre-Insertion Validity . 27 3.8 InsertBefore Example . 28 3.9 Disconnected DOM Trees . 31 3.10 Formalisation of Ensuring Pre-Insertion Validity . 42 4.1 Running Example: Fancy Tab . 48 4.2 Two Variants of Fancy Tab . 50 4.3 Shadow Roots Restrict Node Iterators . 51 4.4 Internal DOM Structure of Shadow Roots . 51 4.5 Updated Data Model with Shadow Roots . 52 4.6 Visualisation of Slotting . 62 5.1 Test and Proof for Software Standards . 66 5.2 Translating a sub-test from the W3C test suite into HOL.
Load more

Recommended publications
  • PDF-LATEX 2Ε Abstract
    Universität Ulm | 89069 Ulm | Germany Faculty of Engineering, Computer Science and Psychology Databases and Information Systems Department Evaluating State-of-the-Art Web Component Frameworks Bachelor’s thesisat Universität Ulm Submitted by: Stefan Engelmayer stefan.engelmayer@uni-ulm.de Reviewer: Prof. Dr. Manfred Reichert Supervisor: Dr. Johannes Schobel 2019 Version from May 29, 2019 c 2019 Stefan Engelmayer This work is licensed under the Creative Commons. Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Composition: PDF-LATEX 2ε Abstract Websites are getting more complex over the years because it is not just used to display information, but to use some applications. One challenge is to maintain these services and keep them up to date. To reuse existing code, Web Components are introduced to outsource complex structures as an HTML element including its functionality. Therefore, some frameworks available which help to create Web Components by providing some useful tools and make the development process easier for developers. Because there are numerous different frameworks available for the development, it is not easy to find the right one for the own project. Because the standards are changing fast in computer science, the development process should always be State-of-the-Art. The aim of this thesis is to give a brief overview over Web Component frameworks and find out which framework is a good choice for given use cases. First some frameworks are introduced.
    [Show full text]
  • Google AMP and What It Can Do for Mobile Applications in Terms of Rendering Speed and User-Experience
    URI: urn:nbn:se:bth-17952 Google AMP and what it can do for mobile applications in terms of rendering speed and user-experience Niklas Andersson Oscar B¨ack June 3, 2019 Faculty of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the bachelor degree in Software Engineering. The thesis is equivalent to 10 weeks of full time studies. The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identi- fied as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree. Contact Information: Authors: Niklas Andersson me.niklas.andersson@outlook.com Oscar B¨ack oscarbackk@gmail.com External Advisor: Simon Nord, Prisjakt simon.nord@prisjakt.nu University Advisor: Michel Nass michel.nass@bth.se Faculty of Computing Internet: www.bth.se Blekinge Institute of Technology Phone: +46 455 38 50 00 SE-371 79 Karlskrona, Sweden Fax: +46 455 38 50 57 1 1 Abstract On today’s web, a web page needs to load fast and have a great user experience in order to be successful. The faster the better. A server side rendered web page can have a prominent initial load speed while a client side rendered web page will have a great interactive user experience. When combining the two, some users with a bad internet connection or a slow device could receive a poor user experience.
    [Show full text]
  • Web Components in Action MEAP
    MEAP Edition Manning Early Access Program Web Components in Action Version 2 Copyright 2018 Manning Publications For more information on this and other Manning titles go to www.manning.com ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. https://forums.manning.com/forums/web-components-in-action welcome Thank you very much for purchasing the MEAP for Web Components in Action. I’ve been speaking and blogging for over a decade now, and the common thread throughout has been that there hasn’t really been a common thread. I get excited about new technologies and techniques, but ultimately move to the next new thing. Web Components have been a bit different for me. I spoke at a few conferences and wrote some blog posts about them, and I did move on to other new and exciting things, but the difference here is that I never stopped building with Web Components. They’ve been a staple of my web development workflow for four years now. Like many web developers, I too have cycled through many frameworks and libraries that help with application development. Most we really good! It’s easy to laugh at a three or four year old framework years later, but it’s been very interesting to see how we as web developers progress as we try to make better and better applications with better and better tools. I’ve also been fortunate enough to use many other programming languages and platforms as well.
    [Show full text]
  • Document Object Model
    Document Object Model Copyright © 1999 - 2020 Ellis Horowitz DOM 1 What is DOM • The Document Object Model (DOM) is a programming interface for XML documents. – It defines the way an XML document can be accessed and manipulated – this includes HTML documents • The XML DOM is designed to be used with any programming language and any operating system. • The DOM represents an XML file as a tree – The documentElement is the top-level of the tree. This element has one or many childNodes that represent the branches of the tree. Copyright © 1999 - 2020 Ellis Horowitz DOM 2 Version History • DOM Level 1 concentrates on HTML and XML document models. It contains functionality for document navigation and manipulation. See: – http://www.w3.org/DOM/ • DOM Level 2 adds a stylesheet object model to DOM Level 1, defines functionality for manipulating the style information attached to a document, and defines an event model and provides support for XML namespaces. The DOM Level 2 specification is a set of 6 released W3C Recommendations, see: – https://www.w3.org/DOM/DOMTR#dom2 • DOM Level 3 consists of 3 different specifications (Recommendations) – DOM Level 3 Core, Load and Save, Validation, http://www.w3.org/TR/DOM-Level-3/ • DOM Level 4 (aka DOM4) consists of 1 specification (Recommendation) – W3C DOM4, http://www.w3.org/TR/domcore/ • Consolidates previous specifications, and moves some to HTML5 • See All DOM Technical Reports at: – https://www.w3.org/DOM/DOMTR • Now DOM specification is DOM Living Standard (WHATWG), see: – https://dom.spec.whatwg.org
    [Show full text]
  • HTML5 Microdata and Schema.Org
    HTML5 Microdata and Schema.org journal.code4lib.org/articles/6400 On June 2, 2011, Bing, Google, and Yahoo! announced the joint effort Schema.org. When the big search engines talk, Web site authors listen. This article is an introduction to Microdata and Schema.org. The first section describes what HTML5, Microdata and Schema.org are, and the problems they have been designed to solve. With this foundation in place section 2 provides a practical tutorial of how to use Microdata and Schema.org using a real life example from the cultural heritage sector. Along the way some tools for implementers will also be introduced. Issues with applying these technologies to cultural heritage materials will crop up along with opportunities to improve the situation. By Jason Ronallo Foundation HTML5 The HTML5 standard or (depending on who you ask) the HTML Living Standard has brought a lot of changes to Web authoring. Amongst all the buzz about HTML5 is a new semantic markup syntax called Microdata. HTML elements have semantics. For example, an ol element is an ordered list, and by default gets rendered with numbers for the list items. HTML5 provides new semantic elements like header , nav , article , aside , section and footer that allow more expressiveness for page authors. A bunch of div elements with various class names is no longer the only way to markup this content. These new HTML5 elements enable new tools and better services for the Web ecosystem. Browser plugins can more easily pull out the text of the article for a cleaner reading experience. Search engines can give more weight to the article content rather than the advertising in the sidebar.
    [Show full text]
  • Web Components the Lego Bricks of Web Developers
    Web Components The Lego bricks of web developers Aaron Czichon • Aaron Czichon • Head of Software Development • NodeJS & Web Components The basic problem of HTML elements Building a login form… <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Dev Days Europe 2019</title> <meta name="description" content="Example for Web Components"> <meta name="author" content="Aaron Czichon"> <link rel="stylesheet" href="./assets/edel-elements.css"> </head> <body> <!-- CONTENT HERE --> </body> </html> <div class="login-card card"> <div class="card-meta"> <h3>Login</h3> <p>Please login first</p> </div> <div class="login-card-form"> <div class="form form--grid"> <div class="form-item"> <label>Username or email</label> <input placeholder="Username or email" type="text"> </div> <div class="form-item"> <label>Password</label> <input placeholder="Super Secret Password" type="password"> </div> <div class="form-item"> <button type=“submit“ class="button button--primary">Login</button> </div> </div </div> </div> Want using it in multiple applications? Multiple Framework Options • Mostly only usable inside the framework Downsides • (Angular has export options for web components) • Sometimes a lot of overhead which is not needed Web Components! „Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags“ Source: webcomponents.org Custom Elements HTML Imports Shadow DOM HTML Template Web Platform APIs Web Component Custom Elements HTML Imports Shadow DOM HTML Template Web Platform APIs
    [Show full text]
  • HTML 5.0 Specification Released As a Stable W3C Recommendation
    INTERNET SYSTEMS H T M L 5 TOMASZ PAWLAK, PHD MARCIN SZUBERT, PHD POZNAN UNIVERSITY OF TECHNOLOGY, INSTITUTE OF COMPUTING SCIENCE PRESENTATION OUTLINE • History and Motivation • HTML5 basics • HTML5 features • Semantics • Connectivity • Offline & Storage • Multimedia • 2D/3D Graphics & Effects • Performance & Integration • Device Access • Styling MODERN WEB APPLICATION DATABASE SERVER HISTORICAL PERSPECTIVE • 1991 — HTML Tags, an informal CERN document • 1993 — HTML Internet Draft published by the IETF • 1995 — HTML 2.0 (RFC 1866) published by the IETF • 1997 — HTML 3.2 published as a W3C Recommendation • 1997 — HTML 4.0 published as a W3C Recommendation: • Transitional, which allowed for deprecated elements • Strict, which forbids deprecated elements • Frameset, which allowed embedding multiple documents using frames • 1998 — W3C decided to stop evolving HTML and instead begin work on an XML-based equivalent, called XHTML HISTORICAL PERSPECTIVE — XHTML • 2000 — XHTML 1.0 published as W3C Recommendation: • reformulation of HTML 4 as an application of XML 1.0, offering stricter rules for writing and parsing markup: lower case tags, end tags for all elements, quoting attributes, escaping ampersands • new MIME type application/xhtml+xml enforces draconian error handling in web browsers. • combatibility guidelines: allowed serving pages as HTML (text/html) to continue using forgiving error handling in HTML parsers. • 2002-2006 — W3C released working drafts of XHTML 2.0 which break backward compatibility. • 2009 — W3C abandoned the work on
    [Show full text]
  • Web-Enabled DDS Version 1.0
    Date: July 2016 Web-Enabled DDS Version 1.0 __________________________________________________ OMG Document Number: formal/2016-03-01 Standard document URL: http://www.omg.org/spec/DDS-WEB Machine Consumable File(s): Normative: http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd http://www.omg.org/spec/DDS-WEB/20150901/webdds_websockets1.xsd http://www.omg.org/spec/DDS-WEB/20131122/webdds_soap1_types.xsd http://www.omg.org/spec/DDS-WEB/20131122/webdds_soap1.wsdl http://www.omg.org/spec/DDS-WEB/20131122/webdds_soap1_notify.wsdl Non-normative: http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1_example.xml http://www.omg.org/spec/DDS-WEB/20150901/webdds_pim_model_v1.eap _______________________________________________ Copyright © 2013, eProsima Copyright © 2016, Object Management Group, Inc. (OMG) Copyright © 2013, Real-Time Innovations, Inc. (RTI) Copyright © 2013, THALES USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, condi- tions and notices set forth below. This document does not represent a commitment to implement any portion of this speci- fication in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.
    [Show full text]
  • Google Javascript
    SED 698 Transcript EPISODE 698 [INTRODUCTION] [00:00:00] JM: Google Search is a highly interactive JavaScript application. As you enter a query, results are being automatically suggested to you before you even finish typing. When you press enter, some of your search results may be widgets that represent the weather, or the price of a stock, or a recipe for green bean soup, or a language translation for praise. These complex frontend components are loading dynamically. The Google search application is not pre-fetching every single possible widget that you might ask for. It's not prefetching the weather widget, and the price of a stock widget, and the currency conversion widget. All of these things are a little bit expensive and they would slow down the page of Google were to pre-fetch the JavaScript for all of these different components, but the results do load very quickly. If you search for a currency conversion, Google loads the results of that currency conversion widget quite quickly. So you know that Google is doing some advanced JavaScript engineering to deliver you the code for that currency conversion widget very quickly, and Google has many other examples of advanced JavaScript programming. The company is mostly known for backend engineering inventions like MapReduce, and TensorFlow, and Dremel, and Spanner, and to turn these backend tools into user-facing products, Google develops its own JavaScript frameworks and infrastructure to deliver information from the backend to the frontend. Backend and frontend are terms that are not very precise. A backend is a backend only relative to a frontend, and at Google there are so many layers of infrastructure between a user and the data center, that if you're an engineer working on a service at Google, you probably have several frontends on one side of you and several backends on either side of you.
    [Show full text]
  • Fido-Uaf-Client-Api-Transport-V1.0-Ps
    FIDO UAF Application API and Transport Binding Specification v1.0 FIDO Alliance Proposed Standard 08 December 2014 This version: https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-client-api-transport-v1.0-ps-20141208.html Previous version: https://fidoalliance.org/specs/fido-uaf-client-api-transport-v1.0-rd-20141008.pdf Editor: Brad Hill, PayPal, Inc. Contributors: Davit Baghdasaryan, Nok Nok Labs, Inc. Bill Blanke, Nok Nok Labs, Inc. Dr. Rolf Lindemann, Nok Nok Labs, Inc. Jeff Hodges, PayPal, Inc. The English version of this specification is the only normative version. Non-normative translations may also be available. Copyright © 2013-2014 FIDO Alliance All Rights Reserved. Abstract Describes APIs and an interoperability profile for client applications to utilize FIDO UAF. This includes methods of communicating with a FIDO UAF Client for both Web platform and Android applications, transport requirements, and an HTTPS interoperability profile for sending FIDO UAF messages to a compatible server. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current FIDO Alliance publications and the latest revision of this technical report can be found in the FIDO Alliance specifications index at https://www.fidoalliance.org/specifications/. This document was published by the FIDO Alliance as a Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome. Implementation of certain elements of this Specification may require licenses under third party intellectual property rights, including without limitation, patent rights.
    [Show full text]
  • Use the Right Font
    Internet Explorer 9: Future of the Web Ziad Ismail Director IE Developer Marketing Agenda: Future of the Web Sites at the Center Fully Hardware Accelerated HTML Same Markup 2 3 The sites of tomorrow and 3 opportunities 1 Sites at the Center Sites at the center The sites of tomorrow and 3 opportunities 1 Sites at the Center Sites at the Center Demo: Never Mind the Bullets PAGE 7 The sites of tomorrow and 3 opportunities 1 Sites at the Center 2 Integrated with Windows The sites of tomorrow and 3 opportunities 1 Sites at the Center 2 Integrated with Windows 3 Fully Hardware Accelerated Fully Hardware Accelerated HTML Demo: Fish Tank PAGE 10 Developers should be able to build web sites that work consistently 11 Getting to Same Markup Compatible Coding for W3C and WHATWG Implementations same markup PAGE 12 W3C and WhatWG “Recent activity in the HTML5 Working Group and the apparent split between W3C and WhatWG suggests HTML5 might not be on the path we expect, or deliver what I believe our industry requires. “ . Eric Huggers, Director of BBC Future Media & Technology . http://www.bbc.co.uk/blogs/bbcinternet/2010/08/html5_open_standa rds_and_the_b.html PAGE 13 Working With the W3C The HTML Working Group Leading the HTML5 45+ W3C Member Member of many Organizations Testing Task W3C Working 430+ group participants Force and chairing Groups 250+ invited experts the HTML 70+ participants 1100+ pages Working Group 40+ groups Spec is still a working draft, and continually changing 14 Getting to a W3C Test Suite that fully tests same markup 97 approved tests as of 9/2010.
    [Show full text]
  • Tr 126 981 V15.0.0 (2018-07)
    ETSI TR 126 981 V15.0.0 (2018-07) TECHNICAL REPORT LTE; MBMS Extensions for Provisioning and Content Ingestion (3GPP TR 26.981 version 15.0.0 Release 15) 3GPP TR 26.981 version 15.0.0 Release 15 1 ETSI TR 126 981 V15.0.0 (2018-07) Reference RTR/TSGS-0426981vf00 Keywords LTE ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]