Tags: specification

14

sparkline

Wednesday, July 25th, 2018

Badging API Explainer

Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.

This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.

Wednesday, July 26th, 2017

Web Publications for the Open Web Platform: Vision And Technical Challenges

Given my experience publishing Resilient Web Design as a web book, I think I should take a good look at this nascent spec.

What we envision for Packaged Web Publications is similar to the goals and techniques of Progressive Web Apps: breaking the boundaries between web sites and mobile apps, an emphasis on “offline” paradigms, and so on. The time is right to broaden the scope and power of the web to include publications.

Tuesday, July 4th, 2017

Let small include subheadings? · Issue #929 · w3c/html

Here’s an interesting proposal to slightly amend the semantics of the small element so it could apply to the use-case that hgroup was trying to cover.

Tuesday, May 30th, 2017

Micropub is a W3C Recommendation • Aaron Parecki

I was just talking about micropub …and now it’s officially a W3C spec. Great work!

If you’re building a blogging platform, you can allow your users choose from a wide variety of posting clients by implementing the Micropub spec.

If you’re building a posting client and want it to work with many different server backends instead of hard-coding it to Twitter or other proprietary APIs, implement the Micropub spec and you’ll quickly have people eager to start using the app!

Saturday, August 6th, 2016

Service worker meeting notes - JakeArchibald.com

Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:

We’re considering allowing the browser to run multiple concurrent instances of a service worker.

Tuesday, August 2nd, 2016

Battery Status readout as a privacy risk

The security research that went into improving the spec for the Battery Status API. This is why it’s so important that the web holds itself to high standard.

Even most unlikely mechanisms bring unexpected consequences from privacy point of views. That’s why it is necessary to analyze new features, standards, designs, architectures - and products with a privacy angle. This careful process will yield results, decrease the number of issues, abuses and unwelcome surprizes.

Monday, August 4th, 2014

The Web Manifest specification | HTML5 Doctor

The Web Manifest spec is still very much in draft, but it’s worth reading through Bruce’s explanation of it now. Basically, it will provide a way for us to specify in one external file what we currently have to specify in umpteen meta tags and link elements.

Thursday, January 31st, 2013

The main issue

The inclusion of a main element in HTML has been the subject of debate for quite a while now. After Steve outlined the use cases, the element has now landed in the draft of the W3C spec. It isn’t in the WHATWG spec yet, but seeing as it is being shipped in browsers, it’s only a matter of time.

But I have some qualms about the implementation details so I fired off an email to the HTML working group with my concerns about the main element as it is current specced.

I’m curious as to why its use is specifically scoped to the body element rather than any kind of sectioning content:

Authors must not include more than one main element in a document.

I get the rationale behind the main element: it plugs a gap in the overlap between native semantics and ARIA landmark roles (namely role="main"). But if you look at the other elements that map to ARIA roles (header, footer, nav), those elements can be used multiple times in a single document by being scoped to their sectioning content ancestor.

Let’s say, for example, that I have a document like this, containing two header elements:

<body>
 <header>Page header</header>
 Page main content starts here
 <section>
  <header>Section header</header>
  Section main content
 </section>
 Page main content finishes here
</body>

…only the first header element (the one that’s scoped to the body element) will correspond to role="banner", right?

Similarly, in this example, only the final footer element will correspond to role=”contentinfo”:

<body>
 <header>Page header</header>
 Page main content starts here
 <section>
  <header>Section header</header>
  Section main content
  <footer>Section footer</footer>
 </section>
 Page main content finishes here
 <footer>Page footer</footer>
</body>

So what I don’t understand is why we can’t have the main element work the same way i.e. scope it to its sectioning content ancestor so that only the main element that is scoped to the body element will correspond to role="main":

<body>
 <header>Page header</header>
 <main>
  Page main content starts here
  <section>
   <header>Section header</header>
   <main>Section main content</main>
   <footer>Section footer</footer>
  </section>
  Page main content finishes here
 </main>
 <footer>Page footer</footer>
</body>

Here are the corresponding ARIA roles:

<body>
 <header>Page header</header> <!-- role="banner" -->
 <main>Page main content</main> <!-- role="main" -->
 <footer>Page footer</footer> <!-- role="contentinfo" -->
</body>

Why not allow the main element to exist within sectioning content (section, article, nav, aside) the same as header and footer?

<section>
 <header>Section header</header> <!-- no corresponding role -->
 <main>Section main content</main> <!-- no corresponding role -->
 <footer>Section footer</footer> <!-- no corresponding role -->
</section>

Deciding how to treat the main element would then be the same as header and footer. Here’s what the spec says about the scope of footers:

When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

I could easily imagine the same principle being applied to the main element. From an implementation viewpoint, this is already what browsers have to do with header and footer. Wouldn’t it be just as simple to apply the same parsing to the main element?

It seems a shame to introduce a new element that can only be used zero or one time in a document …I think the head and body elements are the only other elements with this restriction (and I believe the title element is the only element that is used precisely once per document).

It would be handy to be able to explicitly mark up the main content of an article or an aside—for exactly the same reasons that it would be useful to mark up the main content of a document.

So why not?

Monday, February 21st, 2011

HTML5 — Edition for Web Developers

A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!

Wednesday, December 8th, 2010

Bobbie Johnson dot org : Ian Hickson on HTML5: “The W3C lost sight of the fact that they have no power”

Bobbie is publishing the interviews he conducted with various HTML5 bods when he was researching his Technology Review article. First up: Hixie.

Friday, October 22nd, 2010

Mobile Web Application Best Practices

This W3C document is done and dusted: proposed recommendation. Every one of the guidelines for optimising for mobile also holds true for "desktop" sites.

Saturday, December 12th, 2009

HTML Device

Hixie is proposing a new addition to HTML but separate from HTML5, "to enable video conferencing from HTML applications."

Saturday, September 12th, 2009

The WHATWG Blog » Blog Archive » Spelling HTML5

The official word on that darned space.

Friday, November 14th, 2008

HTML: The Markup Language

Mike Smith has extracted all the parts of the HTML5 spec related to authoring (as opposed to error handling, DOM and other user-agent instructions) to create a pure markup spec. Very handy.