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
--
You can make pull requests for the master branch for
https://github.com/w3c/html , which will end up in the HTML5.1 spec
[1]. Patches to the CR branch end up in the HTML5.0 spec [2] if
accepted. For anything that's more than editorial, register a bug on
Hi Silvia,
If you want to contribute to the WHATWG spec, you should register a
bug on https://www.w3.org/Bugs/Public/describecomponents.cgi?product=WHATWG
. WHATWG patches eventually get cherry-picked into the W3C spec, too,
unless there is strong opposition in the HTML WG.
If the WHATWG spec
On 05/14/2013 09:41 AM, Michael Day wrote:
Hi Silvia,
If you want to contribute to the WHATWG spec, you should register a
bug on
https://www.w3.org/Bugs/Public/describecomponents.cgi?product=WHATWG
. WHATWG patches eventually get cherry-picked into the W3C spec, too,
unless there is strong
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
Sorry, missed this the first time through:
On Sun, Mar 31, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl wrote:
There is some interest in exposing Notification objects in a worker so
creating one does not require a postMessage() roundtrip.
This seems problematic for shared workers as
when should autoscroll be called? only after a url with a hash is clicked in
the same page? when following a link to a : url#specific_hash? both cases?
I initially conceived it as only firing on initial page load for a URL#hash, so
definitely that case. But I can also see how it might be
So, to that end, what about just adjusting the spec for the hashchange
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the hashchange event.
Sincerely,
James Greene
On Tue, May
On Tue, May 14, 2013 at 8:51 AM, Andrew Wilson atwil...@google.com wrote:
On Sun, Mar 31, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl wrote:
This seems problematic for shared workers as it is not clear which
window the notification would be for. For normal workers this seems
like less
So, to that end, what about just adjusting the spec for the hashchange
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the hashchange event.
I think there's one critical thing
Kyle Simpson get...@gmail.com schrieb am Tue, 14 May 2013 16:08:17
-0500:
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Kyle Simpson get...@gmail.com schrieb am Tue, 14 May 2013 16:08:17
-0500:
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain
I thought the point was that the JavaScript event would fire before the scroll,
which would allow you to cancel the default action, no?
Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Kyle Simpson
Tab Atkins Jr. jackalm...@gmail.com schrieb am Tue, 14 May 2013
14:34:09 -0700:
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not
On Tue, May 14, 2013 at 3:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The simplest solution (by far) would be to stop storing “information
that is used by JS” in a hash. Even Internet Explorer has pushState()
these days: http://caniuse.com/history.
Applying private
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not understand it.
In my case, I ran across this once (not too long ago)
On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The simplest solution (by far) would be to stop storing “information
that is used by JS” in a hash. Even Internet Explorer has pushState()
these days: http://caniuse.com/history.
Web APIs have to deal
17 matches
Mail list logo
