Re: [whatwg] Quirks Mode Standard
On Fri, 17 Feb 2012 15:45:37 +0100, Simon Pieters wrote:
I did some quick and dirty research on dotnetdotcom's web200904 data,
I also searched for "braces in style attribute":
grep -iaPo "<[a-z]+\s[^>]*style\s*=\s*[\"']{[^\"'>]+" web200904 >
style-braces.txt
6556 matches
WebKit and IE9 in non-compat view don't support this quirk.
Then I searched for "space before unit":
$ grep -iaPo
"([a-z]+-)*(position|spacing|width|bottom|clip|size|height|left|right|top|bottom|margin|padding|indent|align|width|end|start|columns|border|shadow)\s*:\s*-?([1-9][0-9]*(\.[0-9]+)?|[0-9]?\.[0-9]+)\s+(px|em|ex|cm|mm|in|pt|pc)"
web200904 > space-before-unit.txt
6265 matches
Firefox doesn't support this quirk. Opera used to, but we have now dropped
it because supporting it broke some sites.
Can we also drop the braces in style attribute quirk? (Note that the data
does not include external style sheets, so the second quirk might have
more usage than the first.)
http://simon.html5.org/specs/quirks-mode#the-braces-in-style-attribute-quirk
--
Simon Pieters
Opera Software
[whatwg] crypto.getRandomValues feedback
Hi All, For reference, much of this feedback has been given in the Firefox Bugzilla bug. See [1] and forward. Basically the in/out nature of the getRandomValues function looks very bad to me. This is inconsistent with almost every other JS API which uses return values rather than in/out arguments. The main exception that I can find is Array.splice, but this appears to be so that it can return the removed items. But the main thing that I dislike about in/out arguments over return values is that it makes coding with them very cumbersome. This is a common pattern in perl: $tempString = getSomeValue(); $tempString =~ s/expression/; doStuff($tempString); This because the =~ operator doesn't return the result of the search'n'replace expression which is generally the value that you want to use. The same thing is the case with the getRandomValues API as it currently exists. The web JS will have to look something like this: var tempBuffer = new UInt8Array(65536); crypto.getRandomValues(tempBuffer); doStuff(tempBuffer); This can be greatly improved if we make getRandomValues return the buffer passed to it. That way the following code would work: doStuff(crypto.getRandomValues(new UInt8Array(65536))); This will also make it possible to nicely expand the API to take an integer which the API would use to create a buffer of the passed in size and fill that with random values. Not something we have to do right now, but would be easy to add later if we feel the need. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=440046#c205 / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Tue, Feb 14, 2012 at 10:05 PM, Ian Hickson wrote: > In short, I agree that if the implementation cost was high here that we > could compromise on this design and go with something less clean or with > less graceful fallback, because it is true that many authors will not use > this fallback feature. However, given that the cost is low, I don't see > why we would remove the fallback feature. It's relatively simple, > inobtrusive, and works. The fact that a feature is easy to implement should carry very little value. We shouldn't add features unless they are going to be used. I'm personally very unconvinced that this feature would be used enough to warrant adding it to the spec and implementing it in browsers. / Jonas
Re: [whatwg] Document's base URI should use the document's *current* address
On 20/02/12 2:35 PM, Sean Hogan wrote: On 16/02/12 5:03 PM, Justin Lebar wrote: On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson wrote: On Wed, 15 Feb 2012, Justin Lebar wrote: - It sets "the document's current address" to ".../page.html#foo". Well, this is pretty bad. document.location is the document's current address [1]. So clicking #foo changed document.location from page2.html to page.html#foo, which I certainly wouldn't expect (and does not match implementations). Seems to me we should change the implementations then. There isn't any fundamental difference between linking to #foo and linking to page.html#foo if the base URL is page.html, as far as I can tell. If the implementations can't change, then I'll change the spec, but it really seems bad to me that relative URLs will break depending on when they are resolved relative to pushState() changes. When I implemented pushState, I explicitly didn't want authors to have to rewrite all their anchor links after they changed the document's current URI. > From an author's point of view, there's no such thing as the document's original URI and, unless you're a nerd, you've never heard of the base URI. There's just the document's URI, modified by pushState. > From this point of view, I'd say it's less surprising that relative URIs would break when you change directories (hey, you *asked* for it) than that anchor refs would update the browser's address bar and document.location relative to the old URI. I share your perspective, Justin (if I'm interpreting it correctly). By the way, this doesn't quite match what is currently implemented in Firefox and Webkit. According to my testing, although the baseURI after pushState() is the same as the documentURI (so far I've tested , and elts) the actual images and stylesheets used for rendering aren't updated by the pushState() - they should be updated if @src, @href is a rel path. If they were updated then the ones relying on rel paths would often break, which I consider a good behavior - an obvious visual cue to the page author, etc that something was implemented wrongly. Sean I've just realized that Firefox's behavior matches the spec for dynamic changes to base URLs, http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls Personally I think that facilitates broken behavior, but it's not significant as the issue of this thread. Sean
Re: [whatwg] crypto.getRandomValues feedback
I've updated http://wiki.whatwg.org/wiki/Crypto to have getRandomValues return the array. Adam On Mon, Feb 20, 2012 at 2:51 PM, Jonas Sicking wrote: > Hi All, > > For reference, much of this feedback has been given in the Firefox > Bugzilla bug. See [1] and forward. > > Basically the in/out nature of the getRandomValues function looks very > bad to me. This is inconsistent with almost every other JS API which > uses return values rather than in/out arguments. The main exception > that I can find is Array.splice, but this appears to be so that it can > return the removed items. > > But the main thing that I dislike about in/out arguments over return > values is that it makes coding with them very cumbersome. This is a > common pattern in perl: > > $tempString = getSomeValue(); > $tempString =~ s/expression/; > doStuff($tempString); > > This because the =~ operator doesn't return the result of the > search'n'replace expression which is generally the value that you want > to use. The same thing is the case with the getRandomValues API as it > currently exists. The web JS will have to look something like this: > > var tempBuffer = new UInt8Array(65536); > crypto.getRandomValues(tempBuffer); > doStuff(tempBuffer); > > This can be greatly improved if we make getRandomValues return the > buffer passed to it. That way the following code would work: > > doStuff(crypto.getRandomValues(new UInt8Array(65536))); > > This will also make it possible to nicely expand the API to take an > integer which the API would use to create a buffer of the passed in > size and fill that with random values. Not something we have to do > right now, but would be easy to add later if we feel the need. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=440046#c205 > > / Jonas
[whatwg] Web Intents with System-Wide Sharing Features
Mac OSX 10.8 (Mountain Lion), along with most mobile operating systems, has a system-wide sharing functionality. Could the Web Intents API add a "SHOULD" or "MAY" clause for adding web intents to the system-wide "share sheet" or similar functionality, rather than just on the web? It fits with a few other parts of the HTML5 spec that move towards OS integration (e.g. notifications, which would fit well with Android/iOS/OSX10.8's built-in notification centers).
Re: [whatwg] Web Intents with System-Wide Sharing Features
Definitely, though I'd limit it to a "MAY" recommendation. James On Mon, Feb 20, 2012 at 9:08 PM, Rodger Combs wrote: > Mac OSX 10.8 (Mountain Lion), along with most mobile operating systems, has a > system-wide sharing functionality. Could the Web Intents API add a "SHOULD" > or "MAY" clause for adding web intents to the system-wide "share sheet" or > similar functionality, rather than just on the web? It fits with a few other > parts of the HTML5 spec that move towards OS integration (e.g. notifications, > which would fit well with Android/iOS/OSX10.8's built-in notification > centers).
Re: [whatwg] Web Intents with System-Wide Sharing Features
On 2/20/12 9:08 PM, Rodger Combs wrote: Mac OSX 10.8 (Mountain Lion), along with most mobile operating systems, has a system-wide sharing functionality. Could the Web Intents API add a "SHOULD" or "MAY" clause for adding web intents to the system-wide "share sheet" or similar functionality, rather than just on the web? It fits with a few other parts of the HTML5 spec that move towards OS integration (e.g. notifications, which would fit well with Android/iOS/OSX10.8's built-in notification centers). I certainly see this happening with Chrome OS in place of the file system handler they currently have. I'd imagine it'll make its way to the Windows shell in the future, via Chrome: think of the "Send to" context menu amongst others. At some point, it will be very easy. -Charles
