Semantics vs. Style Importance of Standards Why we follow the rules

Semantic vs Style Semantic  Meaning This is a picture of a tiger A caption is meaningful. Images typically have a caption that describes the image. Style   Appearance This is a picture of a tiger Here, we specify how to display the caption but not the fact that it’s actually a caption.

Semantics + CSS Figure 1 Figure 2 Figure 3 … Figure 99.caption { font-size: 10pt; font-style: italic; }

Problem with Presentational HTML Sub-title 1 Figure 1 Sub-title 2 Figure 2 Figure 3 … Sub-title 99 Figure 999 How would you change the font-size of all the figure captions but not the sub-titles?

History Lesson: The Good Times Standardization was very important in the initial design of HTML HTML was 100% structural/semantic Designers would create style sheets that could be used, but The presentation was determined by the device and the user settings Users could define their own style sheet – Favorite background color – Preferred font type and size

History Lesson: The Bad Times Netscape & Microsoft Internet Explorer supported style tags ( for example) so that web page designers could control the presentation. CSS existed, but presentation HTML was supported for novice designers Eventually, presentation HTML become more commonly used than CSS

History Lesson: Browser Wars Netscape vs. Microsoft Internet Explorer Added many proprietary enhancements to HTML ( ) – Proprietary = Not Open Source – Not standard = Only works in specific browsers Web designers would use HTML tags to control the visual appearance, but these tags were implemented differently on each browsers. Web pages that looked good on one browser would break on other browsers. In 1998, the web development community and W3C said “Enough is enough”

W3C – What is it anyway? The World Wide Web Consortium (W3C)World Wide Web Consortium – international consortium of web developers – sub-organizations, full-time staff, web experts Work together to develop Web standards

HTML5 and WHATWG Web Hypertext Application Technology Working Group – Pioneers of HTML5, which better supports web applications, and the idea of a living standard. founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004 who were increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors.

Fixed vs. Living standard Fixed Example HTML 3.0 Once the rules are established, they cannot be changed. After some time, all the good ideas are implemented in a new standard – HTML 4.0 Living Example HTML 5 Initial standard is established based on previous work Good ideas can be immediately adopted into the living standard – progressive improvement rather than incremental.

Fixed standard Pro Companies implement browsers, servers and tools using a specific standard (HTML 4.0) Developers make website and applications using the same specific standard (HTML 4.0). Since everyone is using the same fixed standard, websites and applications are more stable and less buggy. Con Even if the W3C likes a new innovation, they might still want to consider other innovations before they publish a new standard (4.01) Developers end up waiting along time before they can use the innovation in a standard way.

Living standard Pro Companies update browsers based on the current live standard, which is progressively improving. Thus, designers can start using innovations faster. Con Designers and vendors aren’t using the exact same standard, so things are more likely to break It is often unclear if a browser supports a new innovation. Fixed standards were clearer and more transparent.

Why Living may be better than fixed Fixed Web browsers need to be backward compatible with old standards, i.e., HTML 1.0, 2.0, 3.0, etc., otherwise old websites will break. Thus, browsers need to support too many old standards and they get too complex and bloated Old websites should really be updated to the latest standard Living Web browsers only need to support the current living standard. But, the current standard does its best to be backward compatible. If something gets dropped from the standard it is for good reason, and designers should stop using it. Websites may break, but it may be for very good reasons.

Why Standards? Advantages 1.Accessibility 2.Forward Compatibility 3.Simpler and Faster Development 4.Faster Download & Display

Why Standards? 1.Accessibility 2.Forward Compatibility 3.Simpler and Faster Development 4.Faster Download & Display Standardized web pages look good on all browsers. And on all different types of devices. – iPhone, Android – Tablets, watches – Screen readers for the visually impaired

Why Standards? 1.Accessibility 2.Forward Compatibility 3.Simpler and Faster Development 4.Faster Download & Display Future standards are built on top of current standards Thus, Web pages made today should work in the future Unless there is a really good reason to make them break.

Why Standards? 1.Accessibility 2.Forward Compatibility 3.Simpler and Faster Development 4.Faster Download & Display Faster: You don’t have to build separate websites for separate browsers/devices Concurrent Development: Content and style can be developed separately by different teams.

Why Standards? 1.Accessibility 2.Forward Compatibility 3.Simpler and Faster Development 4.Faster Download & Display Style/Appearance tags are bloated Rather than load bloated presentational HTML for every page, just load one style sheet for an entire website

Rendering Engines Some web browsers actually have different rendering engines for parsing different versions of HTML. The and tag can tell a browser which engine to use.

Rendering Engines Standard, validated HTML code can be rendered faster. – Rendering engine doesn’t have to handle special cases and errors Most web browsers can display Non-standard HTML, – The rendering engine must actually try to autocorrect you HTML syntax errors – auto correction slow things down and doesn’t always work

Standards: Big Motivation The devices we use are becoming more diverse Tablets, phones, iPods, watches, huge displays W3C wants WWW to fully work regardless of devices properties. Non-standard websites may NOT display properly on many types of devices. More importantly, non-standard page page may NOT be able to be parsed or process when they are used in larger applications.

Validate Validate Validate It’s a pain but… At least you know that your web page will display properly on hundreds of different browser variations that now support HTML5.

Summary Originally HTML was meant to be a standard structural/semantic language The browser wars lead to the de-standardization of HTML, CSS, and JavaScript. – Proprietary code and technology (Flash for example) became popular. Standardization has made a comeback and HTML5 + CSS + JavaScript is all you need on the client tier to make web applications. There are no standards for the server tier, i.e., you can use whatever you want (PHP, ASP, JSP, Ruby, Python).

Key Question As a web application developer, why is it so important to have standard languages for the client-side, but not the server-side? Seriously, aside for the fact that web servers have to follow the HTTP protocol, there are no standardized languages that must be used on the server-side. You can use whatever ever language you want. Why? Why are standards less important on the server?