[PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
And if so, which objects should they be on? Window? Documents? Elements? -Boris
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
[Including Anne Tantek due to their work on Fullscreen] The pointer lock specification intentionally mimics the fullscreen specification to provide consistency for developers, as they are similar and expected to be commonly used in the same apps. Neither specification mention event properties. Mozilla and Chrome implement document.onprefixfullscreenchange document.onprefixfullscreenerror document.onprefixpointerlockchange document.onprefixpointerlockerror Pending agreement to add properties to the fullscreen specification, I agree this should be included in the specification. On Thu, Jan 10, 2013 at 9:24 AM, Boris Zbarsky bzbar...@mit.edu wrote: And if so, which objects should they be on? Window? Documents? Elements? -Boris
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On 1/10/13 1:19 PM, Vincent Scheib wrote: The pointer lock specification intentionally mimics the fullscreen specification to provide consistency for developers, as they are similar and expected to be commonly used in the same apps. Neither specification mention event properties. But HTML5 mentions onfullscreenchange/onfullscreenerror. Right now it only puts it on window/body/frameset, but not on document or any other node. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 that I filed earlier today. Mozilla and Chrome implement document.onprefixfullscreenchange document.onprefixfullscreenerror document.onprefixpointerlockchange document.onprefixpointerlockerror Mozilla currently puts these properties on all HTML elements and on Document and Window, for what it's worth. Pending agreement to add properties to the fullscreen specification, I agree this should be included in the specification. Please! -Boris
RE: Digital Books, Web Components, Bookmarking and Hyperlinking
Web Applications Working Group, Greetings. In the BookmarkML approach, we can add bibliographic metadata, useful for graphical user interface summarizations and visualizations of bookmarks and useful for interoperability with authoring software when quoting, citing and referencing materials. Digital book reading software can produce bookmarks, including with one or more text or multimedia selections (see also: http://idpf.org/epub/linking/cfi/epub-cfi.html, http://www.w3.org/TR/media-frags/, http://www.w3.org/TR/xpath-30/, http://www.w3.org/TR/xpath-full-text-10/) and authoring software can be interoperable with bookmarks. bookmark href=... !-- bibliographic metadata about the bookmarked book, chapter, section, page, configuration, for example http://bibliontology.com/ -- data path=...xpath1... param name=x1 value=value_1 / param name=x2 value=value_2 / ... /data data path=...xpath2... param name=x3 value=value_3 / param name=x4 value=value_4 / ... /data ... /bookmark or bookmark !-- bibliographic metadata about the bookmarked book, chapter, section, page, configuration, for example http://bibliontology.com/ -- resources url type=application/epub+zipftp://...url url type=application/epub+ziphttp://...url ... /resources data path=...xpath1... param name=x1 value=value_1 / param name=x2 value=value_2 / ... /data data path=...xpath2... param name=x3 value=value_3 / param name=x4 value=value_4 / ... /data ... /bookmark Kind regards, Adam Sobieski
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On 1/10/13 2:02 PM, Vincent Scheib wrote: I'm confused why HTML should include the properties, and not the respective specifications. Other than scope creep? I am too; see the bug I linked to. -Boris
Re: [shadow-dom] text-decoration
On Thu, Dec 27, 2012 at 9:01 PM, Jens O. Meiert j...@meiert.com wrote: Thanks for clarifying. Can you help me explain the disconnect that I’m seeing in how the draft is clear? All it says is: 6.2 text-decoration Property The text decorations, specified by the text-decoration property must not be propagated from shadow hosts to shadow trees. That’s literally it—there are no other occurrences of the word “text-decoration” in the whole draft, if you don’t count the TOC entry pointing to said section. Are you referring to another draft that is more clear, should I have expected an explanation in the Shadow DOM one, for example (admittedly, I didn’t look there)? Just asking as I’d like to understand, and to gauge whether there is need to make this more clear for other readers too. I'm probably using a different definition of clear than most people here. ^_^ The lack of a hyphen in text decorations distinguishes it from text-decoration, the property - the former refers to the decorations that are specified by the property. If you're intimately familiar with how text decorations work, you'll also know that they inherit in a funky way that is different than CSS properties. ~TJ
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Thu, Jan 10, 2013 at 7:19 PM, Vincent Scheib sch...@google.com wrote: Pending agreement to add properties to the fullscreen specification, I agree this should be included in the specification. I think HTML should maintain the registry and policy for on* attributes insofar they concern Window/Document/HTMLElement objects. http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw. -- http://annevankesteren.nl/
