gmane.org.w3c.whatwg.discuss

[mimesniff] Complete MIME type parsing algorithm forsection 5

Peter Occil — 2013-05-25T07:58:30

I present this draft of the complete algorithm for parsing a MIME type.  I would appreciate comments.

--Peter

----------------------------------------------------

An ASCII alphanumeric is a byte or character in the ranges 0x41-0x5A, 0x61-0x7A, and 0x30-0x39.
A MIME type byte is an ASCII alphanumeric or one of the following bytes: ! # $ & ^ _ . + -
A parameter value byte is a MIME type byte or one of the following bytes: % ' * ` | ~

To parse a MIME type, run the following steps:

1. Let length be the length of the byte sequence of the MIME type.
2. If length is less than 1, return undefined.
3. Let pointer be 0.  Pointer is a zero-based index to the current byte in the byte sequence.
4. Advance pointer to the next byte other than 0x20 (SPACE) or 0x09 (TAB).
5. Let type be the byte string from the current byte up to but not including the next "/" byte. Advance pointer to the next "/" byte.
6. If the current byte isn't "/", return undefined.
7. Increment pointer by 1.
8. Let subtype be the byte string from the current byte up to but not including the next 0x20 (SPACE), 0x09 (TAB), or ";" byte.  Advance pointer to the next 0x20 (SPACE), 0x09 (TAB), or ";" byte.
9. If type is empty, contains a byte that isn't a MIME type byte, or doesn't
begin with an ASCII alphanumeric, or is longer than 127 bytes, return undefined.
10. If subtype is empty, contains a byte that isn't a MIME type byte, or doesn't begin with an ASCII alphanumeric, or is longer than 127 bytes, return undefined.
11. Convert type and subtype to ASCII lowercase.
12. Let parameters be an empty dictionary.
13. Run the following substeps in a loop.
     1. Advance pointer to the next byte other than 0x20 (SPACE) or 0x09 (TAB).
     2. If pointer is equal to length, return type, subtype, and parameters.
     3. If the current byte isn't ";", return undefined.
     4. Increment pointer by 1.
     5. If pointer is equal to length, return type, subtype, and parameters.
     6. Let parameter be the byte string from the current byte up to but not including the next "=" byte. Advance pointer to the next "=" byte.
     7. If parameter is empty, contains a byte that isn't a MIME type byte, or doesn't begin with an ASCII alphanumeric, or is longer than 127 bytes, return undefined.
     8. If parameters contains a mapping for parameter, return undefined.
     9. Convert parameter to ASCII lowercase.
     10. If the current byte isn't "=", return undefined.
     11. Increment pointer by 1.
     12. If the current byte equals 0x22 (quotation mark), run the following substeps:
              1. Let value be an empty byte string.
              2. Increment pointer by 1.
              3. Run these substeps in a loop.
                      1. If pointer is equal to length, return type, subtype, and parameters.
                      2. If the current byte equals 0x7F or is less than 0x20, and the current byte isn't TAB (0x09), return type, subtype, and parameters.
                      3. If the current byte equals 0x22 (quotation mark), increment pointer by 1 and terminate this loop.
                      4. Otherwise, if the current byte is "\", increment pointer by 1. Then, if there is a current byte, append that byte to value.
                      5. Otherwise, append the current byte to value.
                      6. Increment pointer by 1.
              4. Add the mapping of parameter to value to the parameters dictionary.
     13. Otherwise, run these substeps:
              1. Let value be the byte string from the current byte up to but not including the next 0x20 (SPACE), 0x09 (TAB), or ";" byte.  Advance pointer to the next 0x20 (SPACE), 0x09 (TAB), or ";" byte.
              2. If value is empty or contains a byte that isn't a parameter value byte, return undefined.
              3. Add the mapping of parameter to value to the parameters dictionary.

-------------------

Inert nodes and element.click()

Matt Falkenhagen — 2013-05-23T09:48:41

I have some questions about these concepts.

1. For an inert element, what happens on element.click() or
element.dispatchEvent(new Event('click'))? The spec says an inert node is
treated as absent "for the purposes of targeting user interaction events" [1].
My interpretation is that the element receives the 'click' event as usual; the
intent is to block actual user interaction, e.g., if user the physically clicks
on the element.

2. The definition of element.click() seems ambiguous. The spec says:
  The click() method must run synthetic click activation steps on the element.
[2] There is a 6 step algorithm for "synthetic click activation steps" followed
by a separate 6 step algorithm for "when a pointing device is clicked". Below
that is a note which seems to say "the above" happens when the click() method
is called [3]. It's ambiguous what "the above" refers to and if it's the second
algorithm, that seems to contradict the click() definition text.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#inert-subtrees
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#activation
[3] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#run-synthetic-click-activation-steps

An alternative approach to section 9 of Mime Sniffing

Peter Occil — 2013-05-23T06:10:49

I propose rewriting section 9 and parts of section 10 in a different way, to use the ABNF format in RFC 5234. (Note that ABNFs are already  used in the current Fetch specification.) With this approach, the definitions for "byte pattern",  "pattern mask", and the "pattern matching algorithm" can be eliminated (all of which are found before section 9.1).

An example for the image pattern matching algorithm is given below.
 
---------------------------------------------------

9.1  Matching an image type pattern

The image pattern matching algorithm takes a byte sequence as input.  The algorithm goes through the following image types in the order given.  For each image MIME type given below, if the start of the byte sequence matches its ABNF, return the concatenation of "image/" and the name of the ABNF (in lowercase), and terminate the image pattern matching algorithm. 

vnd.microsoft.icon = %x00.00.01.00 
   ; A Windows Icon signature. 
bmp = %x42.4D 
   ; The string "BM", a BMP signature. 
gif = %x47.49.46.38 (%x37 / %x39) %x61 
   ; The string "GIF87a" or "GIF89a", a GIF signature. 
webp = %x52.49.46.46 4OCTET %57.45.42.50.56.50
   ; The string "RIFF" followed by four bytes followed by the string "WEBPVP". 
png = %x89.50.4E.47.0D.0A.1A.0A
   ; The byte 0x89 followed by the string "PNG"
   ; followed by CR LF SUB LF, the PNG signature. 
jpeg = %xFF.D8.FF
   ;     The JPEG Start of Image marker followed by the indicator 
   ; byte of another marker. 

If the start of the byte sequence doesn't match any ABNF given above, return undefined.

---------------------------------------------------

I would appreciate comments.

--Peter

Fetch: please review!

Anne van Kesteren — 2013-05-22T09:50:37

I'm reaching the point where I want to start integrating
http://fetch.spec.whatwg.org/ into http://xhr.spec.whatwg.org/ so I
can remove a lot of the duplicate requirements with respect to
networking and at the same time clarify a lot of the networking
behavior.

And although http://fetch.spec.whatwg.org/ is pretty dry reading it
would be good if people could take a look at it as the idea is for it
to define the fetching behavior across the platform. This task is
currently divided between HTML, CORS, Web Origin Concept, and CSP
(integration hooks not yet in Fetch) and creates a real messy
situation for specifications building on top of them. The idea is to
remove that complexity and have a simple hook for fetching a request
and get a response in return.


--
http://annevankesteren.nl/

Reorganizing and fixing "origin"

Anne van Kesteren — 2013-05-22T07:53:13

As Björn points out in
http://www.ietf.org/mail-archive/web/websec/current/msg01512.html
defining origin of a URL in terms of STD66 is broken. So we should
define it in terms of the URL Standard.

The Origin header also has problems, as it suggests you can have a
space-separated list, which we disallowed almost immediately after the
Origin RFC was published and the IETF group did not accept errata for.

Now "Origin of a URL" can be defined in the URL Standard (not done
yet). I put an updated definition of the header here:
http://fetch.spec.whatwg.org/#http-origin-header

Where should we put the definition of origin itself? Back in HTML? I
guess it still is mostly.


--
http://annevankesteren.nl/

Iframe IDL sandbox readonly attribute

Marta Pawlowska — 2013-05-21T10:31:30

Hello,

In spec I read that IDL sandbox is readonly:

[PutForwards=value] readonly attribute
<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.
html#domsettabletokenlist> DOMSettableTokenList
<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-elem
ent.html#dom-iframe-sandbox> sandbox;

 

 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-elem
ent.html#the-iframe-element>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-eleme
nt.html#the-iframe-element

 

I've prepared TC where I change sandbox value and it can be changes with
most browsers. How should I interpret this "readonly" in case of sandbox
attribute? Readonly indicates at least for me that we should not be able to
change it.

 

Example: 

ifrm = document.createElement("IFRAME");

ifrm.sandbox="blabla";

 

I've tried to find answer on the whatwg discussion list, but no direct
answer how we should interpret this readonly for sandbox. Especially that
with other readonly attributes like "contentDocument" it does work as
expected - I can't change it.

Only reference on whatwg I found is Boris email, but I could not find any
further discussion about "readonly" sandbox :
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035180.html

 

Can you help me and explain it? I'll be grateful for your help.   

 

Best regards,

Marta

links within an iframe cannot replace the parent document?

Constantine A. Murenin — 2013-05-17T19:11:38

Hello,

I'm designing a deterministic URL shortener in nginx, now using HTML5
and iframes, and I got stuck with not being able to specify that all
links within the iframe referenced from my site, have to be opened up
by replacing my site.  (Obviously with the domain of the problem --
URL shortening -- I generally have no control over the URLs that are
loaded within the iframe.)

I've tried using <base target="_top">, and also a target="_parent" on
the iframe (which is not legal in HTML5, BTW), but to no avail.

I'd very much prefer not to use JavaScript (and even then, it's not
clear whether the same origin policies would even let me to), and I'd
also very much prefer not to confuse my users of where they are by
needlessly and endlessly squatting on the Location Bar.

What are my options?  Does HTML5 not supports any such flows?  I've
noticed there's a new `seamless` attribute, but, apart from still
being unsupported by many browsers, it seems to have some restrictions
in regards to same-origin, plus it's an all-or-nothing solution, and
I'm looking for something in the middle -- the iframe occupying most
of the screen (indeed in a seamless way, which is already possible
through CSS), plus links opening up such that they replace the parent
document.  Why HTML5 goes all or nothing instead?

On SO: http://stackoverflow.com/questions/16602378/make-links-within-an-iframe-replace-parent-document

Best regards,
Constantine.

Media aware JS loading

Yoav Weiss — 2013-05-16T13:22:53

Arguably, the biggest problem in responsive Web design today is the fact
that many resource loading mechanisms are media query agnostic, and
download resources upfront regardless of whether they will be used or not.

One of the biggest resources in question (right after images) is external
JavaScript. JavaScript also has secondary performance effects, beside its
download size, since parsing and running it are also time (& battery)
consuming operations.

Currently authors that want their scripts to load only under certain
viewport sizes are forced to use JS based script loaders, which have the
side-effect of preventing these scripts from being parsed out by the
preloader.

I believe that an HTML based solution would be a better fit, will be easier
to use by authors, and will enable preloaders to do their job and preload
these scripts.

Common use-cases for avoiding the load of JS based components based on
layout are:

* JS based maps, which don't fit in a narrow layout
* Social widgets, which don't fit in a narrow layout
* Mobile/desktop oriented UI libraries
* Ad placements

I was thinking along the lines of adding a `media` attribute to the
`<script>` element.
Doing that raises several interesting questions:

* What will be the execution order of these scripts if the media conditions
of the page change?
* Should `media` be permitted for scripts with no `defer`/`async`
attributes, that may contain document.write directives?
* Should scripts re-run if media conditions changed more than once (e.g.
their `media` intially matched conditions, then stopped, then matched again)
* Should events handlers that were registered by scripts which media no
longer matches run?

I believe that mandating `async` (at least as a first step) will enable
avoiding the running-order problems, with authors being obliged to avoid
any dependencies between `media` scripts and other (`media` or non-`media`)
scripts.

Regarding the script re-run and event handler scenarios, I'm not sure what
the right answer should be.

I'd highly appreciate any thoughts on the subject.

Yoav

Microdata status

Jirka Kosek — 2013-05-14T15:22:14

Hi,

are there any plans to change Microdata API? From the following
conversation between Chromium developers it's not clear to me whether
they consider API itself bad or only their implementation.

https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/b54nW_mGSVU

Any insight welcomed.

Jirka

Pull requests for HTML5 spec?

Michael Day — 2013-05-14T06:50:37

Hi,

There are various branches and versions of the W3C and WHAT-WG HTML 
specifications hosted on Github.

Is there any standard procedure in place for pull requests, if you have 
editorial changes to suggest?

Or is there a better way to track these kinds of changes?

Cheers,

Michael

Proposing: some companions to `requestAnimationFrame(..)`

Kyle Simpson — 2013-05-14T03:32:50

I'm proposing a couple of companion APIs to the already standardized `requestAnimationFrame(..)` API.


First: https://gist.github.com/getify/5130304

`requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)`

This is the analog to `setInterval(..)`, in that it runs the handler automatically for every animation-frame, instead of requiring you to re-queue your function each time. Hopefully that could be made slightly more performant than the manual re-attachment, and since this is often a very tight loop where performance really does matter, that could be useful.

It will make animation loops, frame-rate detection, and other such things, a little easier, and possibly slightly more performant. The code linked above has the polyfill (aka "prollyfill" aka "hopefull-fill") logic.


------------------


Second: https://gist.github.com/getify/3004342#file-naf-js

`requestNextAnimationFrame(..)` and `cancelNextAnimationFrame(..)`

`requestNextAnimationFrame(..)` queues up a function not for the current upcoming animation-frame, but for the next one. It can be accomplished by nesting one rAF call inside another, as the polyfill implies, but again, my presumption is that this sort of logic is not only more awkward but also possibly slightly less efficient than if it were built-in as I'm proposing.

Why would we need this? Well, there are some sorts of CSS-based tasks which end up getting automatically batched-together if they happen to be processed in the same rendering pass. For example: if you want to unhide an element (by setting display:block) and then tell the element to move via a CSS transition (say by adding a class to it). If you do both those tasks in the same rendering pass, then the transition won't occur, and the repaint will show the element at its final location. Bummer. So, I have to first unhide it in the current animation-frame, and then add the class for the transition to the *next* animation-frame.

Do that kind of thing enough times (which I have), and you start wishing there was a codified API for it, instead of my hack. Thus, my simple proposal here.




--Kyle

Proposing: "autoscroll" event

Kyle Simpson — 2013-05-14T02:53:47

Increasingly, sites are doing client-side rendering at page load time, which is breaking the (useful) functionality of being able to have a #hash on a URL that auto-scrolls the page to make some element visible after page-load.

A perfect example of this problem is that most #hash URLs (as far as scrolling) are broken on gist.github and github when viewed in recent Firefox.

https://gist.github.com/getify/5558974

I am proposing that the browser throw a JS event right before it's about to try an auto-scroll to an element with the #id of the #hash in the URL (during a page's initial loading), called for instance "autoscroll". The purpose of this event is to simplify how a web app can detect and respond to a URL having a #hash on it that would normally create a scrolling behavior, even if the element isn't yet rendered for the window to scroll to. That gist shows how you could listen for the event, and store for later use which target-ID was going to be scrolled to, and manually scroll to it at a later time.

If you have an app that does client-side rendering where it can break auto-scrolling, but you want it to work properly, you can of course manually inspect the URL for a #hash at any point, but it's a bit awkward, especially if you are already relying entirely on event-driven architecture in the app, and you want to just detect and respond to events. This "autoscroll" event will normalize that handling.

Notice the polyfill code in the above gist shows that you can obviously detect it yourself, but it's awkward, and would be nice if it were just built-in.

Additionally, having it be a built-in event would allow an app to prevent the browser from doing unwanted auto-scrolling in a very simple and natural way, by just trapping the event and calling `preventDefault()`. Currently, there's not really a clean way to accomplish that, if you needed to.

--Kyle

Spec ambiguity and Firefox bug for newlines following

 and </h1>
<p>Michael Day — 2013-05-14T02:36:01</p>
<pre>Hi,

If a newline character token follows a <pre> or <textarea> start tag, it 
is supposed to be ignored as an authoring convenience.

However, what if a NULL character token gets in the way? Consider these 
two cases, where "NULL" represents a literal U+0000 character:

<pre>NULL&#xA;

<textarea>NULL&#xA;

For textarea, the tokenizer will be in the rcdata state, which generates 
replacement character (U+FFFD) tokens for each NULL. So the newline will 
not be the next token following the start tag, and should not be 
ignored. Chrome gets this right, Firefox get this wrong, and displays 
the replacement character *and* strips the newline.

For pre, the tokenizer will be in the data state, which emits NULL 
characters as-is. The NULL character token is then ignored by the "in 
body" insertion mode. Does this mean it doesn't count as the next token 
after the start tag? Both browsers seem to think so.

In general, the concept of "next token" is not well defined; in fact I 
don't think it is ever explicitly defined in the spec. If a token is 
ignored, is it still the next token?

Since this concept is only used for the specific case of ignoring 
newlines at the start of <pre>, <listing>, and <textarea>, perhaps a 
better mechanism could be found to describe how it should work.

Best regards,

Michael

</pre>
</article>
<article>
<h1>[mimesniff] First pass at speccing theX-Content-Type-Options header</h1>
<p>Gordon P. Hemsley — 2013-05-10T19:15:11</p>
<pre>I've made a first pass at speccing the X-Content-Type-Options header:

https://github.com/whatwg/mimesniff/commit/1599b7900afb923eff3af94e7e92a3d895eeb8f7
http://mimesniff.spec.whatwg.org/

As it stands now:

* If any resource retrieved over HTTP has an X-Content-Type-Options
header with a value of "nosniff", sniffing is turned off. (That means
multiple headers, with possible other values, will not turn sniffing
back on.)

* Sniffing can only be turned off by the X-Content-Type-Options in
contexts that call the main MIME type sniffing algorithm. In general,
that means sniffing is only turned off in contexts that do not have a
type hint. Contexts such as <img> call context-sniffing algorithms
from the HTML spec, and so are subject to different algorithmic
restrictions. However, <script> does not have its own context-specific
algorithm; I don't know how the HTML spec handles that. I also don't
know how the HTML spec handles <iframe>, but I assume that it calls
the main MIME type sniffing algorithm as any primary browsing context
would.

* If the X-Content-Type-Options header turns sniffing off, but the
supplied MIME type is unknown, non-scriptable types are still sniffed,
because we need to have some idea of what the resource is. (If no
known signatures are detected, the algorithm ends with either
"text/plain" or "application/octet-stream", depending on whether there
are any binary bytes in the resource header.)

Now, I have to admit up front that I didn't actually test whether this
behavior matches existing implementations. Instead, I used others'
reports [1][2] as a basis and made the least number of changes to the
existing spec as I probably could. I know Mozilla is looking for what
to implement and this, as now specced, seems like reasonable behavior
to me.

Let us now commence quibbling about the details.

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/037983.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=471020

--
Gordon P. Hemsley
me-f5q39Z2f4HCxbKUeIHjxjQ< at >public.gmane.org
http://gphemsley.org/ • http://gphemsley.org/blog/

</pre>
</article>
<article>
<h1>Question about DOMImplementation.createHTMLDocument()specifications</h1>
<p>Thomas Fétiveau — 2013-05-10T05:10:38</p>
<pre>Hi,

There is something unclear to me in the current HTML spec:

- The "initial" insertion mode of the tree construction stage specifies 
to add a doctype to the associated document when a doctype token shows 
up: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#the-initial-insertion-mode

- However the document object has already been built at this stage and 
is an HTML document, thus created by DOMImplementation.createHTMLDocument().

   But the specification of this methods says :


There is a problem here IMO because if we've already created our HTML 
document object before the initial stage of the tree contruction stage, 
it means it already has a doctype, a HTMLHtmlElement, a HTMLHeadElement, ...

How should we manage that in the "initial", "before html", "after HTML", 
... insertion modes when are asked to append/associate doctypes, html 
element, head element (...) to our assiocated document object which 
already has all that ?

My point is : Shouldn't the  DOMImplementation.createHTMLDocument() just 
create a Document object with  content type set to "text/html" and 
nothing else ?

Thanks and regards,

</pre>
</article>
<article>
<h1>HTML5 is broken: <menuitem> causes infinite loop</h1>
<p>Michael Day — 2013-05-09T05:47:08</p>
<pre>Hilarious spec bug of the week: HTML5 requires implementations to loop 
indefinitely if they see a <menuitem> start tag.

12.2.5.4.7 "in body" insertion mode
  => see a <menuitem> start tag, process using rules for "in head"

12.2.5.4.4 "in head" insertion mode
  => see <menuitem>, act as if </head> and reprocess

12.2.5.4.6 "after head" insertion mode
  => see <menuitem>, act as if <body> and reprocess

...and we're back at "in body" insertion mode, and will continue to 
bounce around with the <menuitem> start tag token making absolutely no 
progress whatsoever.

What is the <menuitem> tag supposed to be, anyway? A test to ensure that 
implementers are awake, like the </sarcasm> close tag?

Cheers,

Michael

</pre>
</article>
<article>
<h1>API to delay the document load event (continued)</h1>
<p>James Burke — 2013-05-06T19:35:20</p>
<pre>I just joined the mailing list, so I apologize for not continuing the
existing thread started here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html

Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of
capability in this area.

Summarizing previous discussion points:

1) Should this be tied to document load or some new event/state?
Concerns about messing up scripts that bind to document load.

Not using document load as the API target means also adding a
mechanism for a script that does want to wait for this new state to
detect if that state is in play. For the paired JS API, it implies
providing something like a document.appReadyState if the new event is
tied to some name like "appload". For the html attribute approach,
detecting the attribute is probably enough.

In my experience as a JS library provider (first with dojo and more
recently with requirejs), JS scripts heavily favor binding to
DOMContentLoaded over document load to do work. DOMContentLoaded is
also what jQuery's ready() uses, which I expect is what most sites
that use jQuery use.

It would be good to do a survey of existing public source to verify
the uses of document load vs. DOMContentLoaded. Anyone know if this
has been done before?

Just going on my experience (admittedly a limited data set): anything
that actually binds to document load really wants to know when "all
resources loaded (images/iframes) and page is considered complete",
which fits with the motivations of this new capability.

2) Use paired JS API (document.delayLoadEvent and
document.stopDelayingLoadEvent being one example) vs. setting an html
attribute "loading" and removal the attribute trigger the event.

The JS API allows less coordination among multiple scripts. I can see
this becoming more important with Web Components. The HTML attribute
loading solution would likely push that API into library-specific APIs
use cases, which just seems to result in the same outcome, but in ways
that make it harder to use scripts from disparate sources -- the
scripts would need to buy into library-specific APIs.

3) What about errors?

I would expect this to work how errors affect onload notification now.
The behavior/consequences seem to be the same for paired JS API vs.
attribute approach.

If the concern is about an async script erroring out between the
paired calls/addition and removal of an attribute, then perhaps any
uncaught error ends up triggering the same behavior that occurs now
when there is an error during onload determination.

----
Summary
----

I am fine with the paired JS API approach tied to document load, as a
web app developer and consumer of the API. I do not have a particular
favored design of what that paired API looks like.

If there is agreement on focusing on a paired JS API and for it being
tied to onload, perhaps the API discussion could begin.
document.delayLoadEvent and document.stopDelayingLoadEvent is one
suggestion, and I am fine with that. Glenn Maynard also suggested a
`new Something` then `somethingInstance.finished()` as the API. That
one implies tracking the instance, so something that could get lost
particularly if attached to an object and incorrect `this` bindings
interfere. But I have no strong opinion on the API matter, and defer
to whatever browser vendors would want to implement.

James

</pre>
</article>
<article>
<h1>suggestions for the Notifications API(http://notifications.spec.whatwg.org/)</h1>
<p>alonn — 2013-05-03T15:50:36</p>
<pre>I played a little bit with the Notification API and I have a couple of
suggestions (I tried the chrome implementation with Mozille hacks jsFiddle
http://jsfiddle.net/robnyman/TuJHx/) for improvement (at least
in my view) or a more consistent API as web developer:

1. Having a way to check for the current permission without initiating a
new Notification object first. something like webkit has (I'm not sure it's
not deprecated) window.webkitNotification.checkPermission()
I saw this isn't in the api, and I think having this would be a great

*Real life usecase example:*I would like to show different content or apply
different logic for someone who didn't explicitly granted permission, but
didn't deny it either, without having to show the confirmation dialog first
and frighten them away.

2.having a collection to iterate over notification instances  (from my page
only).

3.having to set the "title" only when initiating the Notification object,
instead in the dictionary NotificationOptions Iooks inconsistent to me. my
instinctive attempt was to set the title together with the rest of the
notification options. but that won't work. I think it belongs there  (or at
least, also there)

I would also like to say that this can be a really useful api, and you're
doing a great work with it! thanks everyone for the great job!

</pre>
</article>
<article>
<h1>suggestions for the Notifications API(http://notifications.spec.whatwg.org/)</h1>
<p>alonn — 2013-05-03T15:48:13</p>
<pre>I played a little bit with the Notification API and I have a couple of
suggestions (I tried the chrome implementation with Mozille hacks jsFiddle
http://jsfiddle.net/robnyman/TuJHx/) for improvement (at least
in my view) or a more consistent API as web developer:

1. Having a way to check for the current permission without initiating a
new Notification object first. something like webkit has (I'm not sure it's
not deprecated) window.webkitNotification.checkPermission()
I saw this isn't in the api, and I think having this would be a great

*Real life usecase example:*I would like to show different content or apply
different logic for someone who didn't explicitly granted permission, but
didn't deny it either, without having to show the confirmation dialog first
and frighten them away.

2.having a collection to iterate over notification instances  (from my page
only).

3.having to set the "title" only when initiating the Notification object,
instead in the dictionary NotificationOptions Iooks inconsistent to me. my
instinctive attempt was to set the title together with the rest of the
notification options. but that won't work. I think it belongs there  (or at
least, also there)

I would also like to say that this can be a really useful api, and you're
doing a great work with it! thanks everyone for the great job!

</pre>
</article>
<article>
<h1>HTML differences from HTML4 document updated</h1>
<p>Simon Pieters — 2013-05-03T15:37:21</p>
<pre>Hi

The past few days I've been working on updating the HTML differences from  
HTML4 document, which is a deliverable of the W3C HTML WG but is now also  
available as a version with the WHATWG style sheet:

http://html-differences.whatwg.org/

Review welcome. Please file bugs.

</pre>
</article>
<article>
<h1>font security on measureText</h1>
<p>Rik Cabanier — 2013-05-02T21:36:14</p>
<pre>The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]

If doing these measurements requires using a font that has an origin that
is not the same as that of the Document object that owns the canvas element
(even if "using a font" means just checking if that font has a particular
glyph in it before falling back to another font), then the method must
throw a SecurityError exception.


Does anyone know what this is? It seems to us, that if the font is
available to CSS (depending on if the browser supports CORS for fonts), it
should be fine to call measureText.

1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-measuretext
2: http://www.w3.org/TR/2dcontext/#dom-context-2d-measuretext

</pre>
</article>
</main></body></html>