Re: [whatwg] Audio synthesis
On Wed, 22 Jul 2009 04:38:08 +0200, Patrick Mueller pmue...@muellerware.org wrote: Robert O'Callahan wrote: On Wed, Jul 22, 2009 at 1:36 AM, Patrick Mueller pmue...@muellerware.orgwrote: I've just started playing a bit with audio. One thing I noticed with both FF 3.5 and WebKit nightlies is that usage of the loop attribute set to true does not provide seamless looping. ie, there is a significant pause between when the audio clip end is reached and when the clip starts again. That might be related to the fact that we haven't implemented 'loop' yet. Woops, caught me there. It's exciting to have programmatic audio available AT ALL, was forgetting some of the details. But since you mention it, any idea whether the Moz developers plan on implementing seamless looping or not? I'm curious whether anyone cares, and what folks interpretation of looping means. The spec should be made more specific, one way or another (must/should/may implement seamless looping). Or even provide some other mechanism to allow for seamless looping if the current APIs are insufficient, and it's deemed important. The spec simply says If the media element has a loop attribute specified, then seek to the earliest possible position of the media resource and abort these steps. This would give seamless looping if an implementation makes an effort to make it so. I certainly don't think there should be an option to have seamless looping or not, each implementation will simply have to do its best. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Idea: Links w/o end anchors (is possible)
Hi All, I've just joined the list, hopefully only to make a single suggestion. I couldn't find this idea in the archives, so apologies if I'm way behind where everyone else is going. Brief background history: A couple of years ago in 2006-7, a group I was with were interested in linking without anchors at the end of traversal (in basic HTML). We wanted to be able to link to any text in within a document. A friend, Matt Schneider, creator of PurpleSlurple, had/passed on the idea that only a short string of ~100 chars was required to uniquely identify any document. Playing with it, I discovered that even shorter strings could be used to uniquely identify places within a web page. I created an overweight prototype proxy server, capable of approximate match measurement, transclusion chunk separation... many features, zero adoption rate, it seemed. Unofficial spec and code (in Ruby) can be found on the internet archive at: http://web.archive.org/web/20070701121314/www.concept67.net/blog/?page_id=141 Unknown to me at the time, in India, someone I only know as Nataranjan created LiveURLs (based on some work in Ahoy) and introduced them in a Firefox plugin called WebMarker. http://knutties.livejournal.com/24270.html LiveURLs differed in that they use a checksum to encode the search text, so it isn't open to direct user scrutiny but is more compact. Unlike my XPunt prototype WebMarker was more lightweight and didn't support approximate match indication etc. Both these implemetations suffered from the issue that two users had to have the relevant piece of software installed to share the links. However, together those prototypes prove that the technology to do linking without anchors exists, and is relatively straightforward. Back to the present. The way around this shared software issue is simply to have browsers include something like the following as basic link traversal behaviour. The Goal: Links w/o anchors. The Strategy: Two stage process. 1) get an extra 'search' attribute on to the a tag in HTML so that we have: e.g. a href='...' search='...'link text/a 2) If there's take-up, then later on push for adding a date-time of creation attribute to a. This will add link history to the internet. The way (1) works is someone sticks the basic href to a page in the href attribute, and then sticks the text they want to link to in the search attr. The browser fetches the page, and as a secondary action (at user option) searches for the text. The simple option is that it just searches for the plain string, maybe later it can do all the fancy approximate match stuff that I put in the XPunt prototype in '06/07. Since we know those search strings don't have to be very long to find the unique location, it shouldn't burden the document text very much. Just thought it would be good to put these ideas to the list. I'm hoping everyone just gets how much this could advance the world. Best regards, Peter P. Jones
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Am Mittwoch, den 22.07.2009, 10:38 + schrieb ppj: The Goal: Links w/o anchors. The Strategy: Two stage process. 1) get an extra 'search' attribute on to the a tag in HTML so that we have: e.g. a href='...' search='...'link text/a 2) If there's take-up, then later on push for adding a date-time of creation attribute to a. This will add link history to the internet. The way (1) works is someone sticks the basic href to a page in the href attribute, and then sticks the text they want to link to in the search attr. The browser fetches the page, and as a secondary action (at user option) searches for the text. The simple option is that it just searches for the plain string, maybe later it can do all the fancy approximate match stuff that I put in the XPunt prototype in '06/07. Since we know those search strings don't have to be very long to find the unique location, it shouldn't burden the document text very much. An additional element seems very hackish; this likely is something better brought up in the context of an URI working group. I would also recommend talking to implementors directly. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Nils Dagsson Moskopp wrote: Am Mittwoch, den 22.07.2009, 10:38 + schrieb ppj: The Goal: Links w/o anchors. The Strategy: Two stage process. 1) get an extra 'search' attribute on to the a tag in HTML so that we have: e.g. a href='...' search='...'link text/a 2) If there's take-up, then later on push for adding a date-time of creation attribute to a. This will add link history to the internet. The way (1) works is someone sticks the basic href to a page in the href attribute, and then sticks the text they want to link to in the search attr. The browser fetches the page, and as a secondary action (at user option) searches for the text. The simple option is that it just searches for the plain string, maybe later it can do all the fancy approximate match stuff that I put in the XPunt prototype in '06/07. Since we know those search strings don't have to be very long to find the unique location, it shouldn't burden the document text very much. An additional element seems very hackish; this likely is something better brought up in the context of an URI working group. I would also recommend talking to implementors directly. Fragment identifiers depend on the MIME type, thus it's in scope for the HTML WG (which is in charge of text/html and application/xhtml+xml). ...but do consider existing work in this area, such as XPointer... BR, Julian
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 15 Jul 2009 00:30:05 +0200, Aaron Whyte awh...@google.com wrote: Most apps provide different contents for the same uncacheable main-page URL, depending on the identity of the user, which is typically stored in a cookie and read by the server. However, the HTML5 AppCache spec doesn't allow cookies to influence the choice of AppCaches or the contents of a response returned by the cache. Why not? I cannot find anything like that in the specification. It seems to me that the generic fetching algorithm is used which does not forbid sending cookies and even explicitly calls out setting them. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On Wed, Jul 22, 2009 at 12:19:04PM +0200, Julian Reschke wrote: Nils Dagsson Moskopp wrote: Am Mittwoch, den 22.07.2009, 10:38 + schrieb ppj: The Goal: Links w/o anchors. The Strategy: Two stage process. 1) get an extra 'search' attribute on to the a tag in HTML so that we have: e.g. a href='...' search='...'link text/a 2) If there's take-up, then later on push for adding a date-time of creation attribute to a. This will add link history to the internet. The way (1) works is someone sticks the basic href to a page in the href attribute, and then sticks the text they want to link to in the search attr. The browser fetches the page, and as a secondary action (at user option) searches for the text. The simple option is that it just searches for the plain string, maybe later it can do all the fancy approximate match stuff that I put in the XPunt prototype in '06/07. Since we know those search strings don't have to be very long to find the unique location, it shouldn't burden the document text very much. An additional element seems very hackish; this likely is something better brought up in the context of an URI working group. I would also recommend talking to implementors directly. Fragment identifiers depend on the MIME type, thus it's in scope for the HTML WG (which is in charge of text/html and application/xhtml+xml). ...but do consider existing work in this area, such as XPointer... BR, Julian Does XPointer trigger a behaviour in the browser as a basic behaviour? Seems as though few users on the web are using XPointer to create links, and even if they do, the browsers don't support this behaviour. Why would ordinary people, who create the majority of links, find XPointer useful to use? Kind Regards, Peter
Re: [whatwg] [html5] r3306 - [] (0) Define interaction with CSS case-sensitivity rules.
On Tue, 14 Jul 2009 12:59:32 +0200, Simon Pieters sim...@opera.com wrote: Hmm. In that case maybe we can remove it altogether? I think it was only implemented for compliance with CSS2 and HTML4 when Niels Leenheer wrote a Selectors test suite back in 2006. Yeah, and IE7 did not support this. Killing this useless list seems like the best way forward. As far as I know there is no compatibility reason for having it other than that test suite and having it be an arbitrary number of attributes is just confusing and slightly increases code complexity and testing. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] hasFeature() When Only 1 Syntax is Supported
On Thu, 16 Jul 2009 03:37:37 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Dienstag, den 14.07.2009, 14:46 +0200 schrieb Simon Pieters: Gecko, WebKit and Opera return true for XHTML/2.0. Who in the real world actually checks for that ? Wasn't XHTML 2.0 dead in the snow for some time now ? It means that you support DOM Level 2 HTML for XHTML. Not that you support XHTML 2.0. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On 07/22, ppj wrote: e.g. a href='...' search='...'link text/a I've wished for this a number of times, but I think I would be more interested in the spec saying that a document should include id tags at every point someone might want to link to which the author of the document is willing to provide. It seems odd to me that the definition of the id attribute doesn't mention its use as a fragment identifier. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute -- Every normal man must be tempted at times to spit upon his hands, hoist the black flag, and begin slitting throats. - Henry Louis Mencken (1880-1956) http://www.ChaosReigns.com Guns save lives.
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On Wed, Jul 22, 2009 at 06:50:33AM -0400, dar...@chaosreigns.com wrote: On 07/22, ppj wrote: e.g. a href='...' search='...'link text/a I've wished for this a number of times, but I think I would be more interested in the spec saying that a document should include id tags at every point someone might want to link to which the author of the document is willing to provide. It seems odd to me that the definition of the id attribute doesn't mention its use as a fragment identifier. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute -- Hi, We played with filling documents with ids a lot. This is not a bad idea, but the users (imho) want to link to text first and foremost. So I'm suggesting we could let them. Folks have suggested XPointer vs. attribute hack on the a element. But I would prefer the element to have something superficial ordinary people can understand, even if behind the scenes the browser turns that into XPointer. What's the present rate of user uptake of XPointer? Kind regards, Peter
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Am Mittwoch, den 22.07.2009, 06:50 -0400 schrieb dar...@chaosreigns.com: On 07/22, ppj wrote: e.g. a href='...' search='...'link text/a I've wished for this a number of times, but I think I would be more interested in the spec saying that a document should include id tags at every point someone might want to link to which the author of the document is willing to provide. Ahaha oh wow (read: this is highly unrealistic). It actually would be easier to specify Xpath or something like that as fragment thingy. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Idea: Links w/o end anchors (is possible)
ppj wrote: Does XPointer trigger a behaviour in the browser as a basic behaviour? Seems as though few users on the web are using XPointer to create links, and even if they do, the browsers don't support this behaviour. Why would ordinary people, who create the majority of links, find XPointer useful to use? ... The same applies to any new fragment identifier syntax that isn't supported by existing user agents. BR, Julian
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Darxus wrote; It seems odd to me that the definition of the id attribute doesn't mention its use as a fragment identifier. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute +1 I think it's important to mention the id attribute's relationship to the URI as well to the DOM. Currently the documentation only mentions the DOM. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Rel and META values
Hixie wrote: 1. Should I change all of the values derived from XFN from proposal to accepted as they seem to fit this criteria? Sure. Done. All we really need is a core group of strong-minded people who are willing to own this problem and maintain this list responsibly (saying no to most proposals, demanding rigorous specs for those they accept, preventing duplicates, documenting existing practices and implementations, etc). ... The community right now is defined as the microformats+w3c communities. I'd like a more dedicated community, but that doesn't just happen on its own -- someone has to step forward and own that process. It's a lot of work, and if we are to have continuity and stability in the process, it would have to be someone willing to commit to this for many years. I'll raise this with the microformats community. While I don't the microformats community itself is the right group for this job, I think that many of the people in the community would be well-suited (and have experience). I'll be sure to make the longevity of committing to a new community process clear. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Audio synthesis
On Wed, 22 Jul 2009 04:38:08 +0200, Patrick Mueller pmue...@muellerware.org wrote: But since you mention it, any idea whether the Moz developers plan on implementing seamless looping or not? I'm curious whether anyone cares, and what folks interpretation of looping means. The spec should be made more specific, one way or another (must/should/may implement seamless looping). Or even provide some other mechanism to allow for seamless looping if the current APIs are insufficient, and it's deemed important. Unless memory fails me badly, the sole reason we have a looping API at all is for seamless looping. (Otherwise you'd simply listen for the ended event and invoke play() when it is dispatched.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On Wed, Jul 22, 2009 at 7:02 AM, ppjp...@concept67.net wrote: On Wed, Jul 22, 2009 at 06:50:33AM -0400, dar...@chaosreigns.com wrote: On 07/22, ppj wrote: e.g. a href='...' search='...'link text/a I've wished for this a number of times, but I think I would be more interested in the spec saying that a document should include id tags at every point someone might want to link to which the author of the document is willing to provide. It seems odd to me that the definition of the id attribute doesn't mention its use as a fragment identifier. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-id-attribute -- Hi, We played with filling documents with ids a lot. This is not a bad idea, but the users (imho) want to link to text first and foremost. So I'm suggesting we could let them. Folks have suggested XPointer vs. attribute hack on the a element. But I would prefer the element to have something superficial ordinary people can understand, even if behind the scenes the browser turns that into XPointer. What's the present rate of user uptake of XPointer? It would be relatively simple to expose a UI that allows one to point at some text and automatically generate an XPointer to the element containing that text. Assuming that you could then generate a url with that information (which would take browser cooperation), you'd be golden. I am generally against anything that would change the target of a link, but isn't representable in the actual url. Anything I can click, I should be able to copypaste into my browser's location bar and get identical results. ~TJ
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Tab Atkins Jr. wrote: ... It would be relatively simple to expose a UI that allows one to point at some text and automatically generate an XPointer to the element containing that text. Assuming that you could then generate a url with that information (which would take browser cooperation), you'd be golden. ... For those who don't know it already...: http://codedread.com/fxpointer/. BR, Julian
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On Wed, Jul 22, 2009 at 10:31 AM, Julian Reschkejulian.resc...@gmx.de wrote: Tab Atkins Jr. wrote: ... It would be relatively simple to expose a UI that allows one to point at some text and automatically generate an XPointer to the element containing that text. Assuming that you could then generate a url with that information (which would take browser cooperation), you'd be golden. ... For those who don't know it already...: http://codedread.com/fxpointer/. Ah, excellent. Now just get that baked into all the browsers, and we're good. ^_^ ~TJ
Re: [whatwg] Definitions of DOMTokenList algorithms and element.classList
On Mon, 13 Jul 2009 05:16:19 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 15 Jun 2009, Adam Roben wrote: Should methods of element.classList treat their arguments case-insensitively in quirks mode? I think they should. This should be mentioned in the spec. I've clarified that DOMTokenList is always case-sensitive. We don't want to be adding more quirk-mode behaviours. Using quirks mode is not conforming (i.e. it's not a supported behaviour). Implementation-wise that does not seem nice if you want to use the same optimized object when dealing with style sheets or getElementsByClassName(). Alternatively we could require I suppose that in quirks mode class names are normalized to be lowercase or some such and keep getElementsByClassName() and classList case-sensitive... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. -atw On Wed, Jul 22, 2009 at 3:32 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 15 Jul 2009 00:30:05 +0200, Aaron Whyte awh...@google.com wrote: Most apps provide different contents for the same uncacheable main-page URL, depending on the identity of the user, which is typically stored in a cookie and read by the server. However, the HTML5 AppCache spec doesn't allow cookies to influence the choice of AppCaches or the contents of a response returned by the cache. Why not? I cannot find anything like that in the specification. It seems to me that the generic fetching algorithm is used which does not forbid sending cookies and even explicitly calls out setting them. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Idea: Links w/o end anchors (is possible)
Julian Reschke wrote: For those who don't know it already...: http://codedread.com/fxpointer/. For the record, Gecko has native support for XPointer anchors if you're linking to an XML document. There's no infrastructure for evaluating XPointer against HTML, though. That could probably change if it becomes necessary, though so far we've been considering just removing XPointer altogether instead. -Boris
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 22 Jul 2009 18:10:52 +0200, Drew Wilson atwil...@google.com wrote: Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. Well, as far as I can tell cookies are part of the request to the manifest file so you could serve up a different one from the server based on cookie data. Is the problem supporting multiple users completely client-side? I can see how that might not work very well. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, Jul 22, 2009 at 9:46 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 22 Jul 2009 18:10:52 +0200, Drew Wilson atwil...@google.com wrote: Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. Well, as far as I can tell cookies are part of the request to the manifest file so you could serve up a different one from the server based on cookie data. That's an interesting idea (send down a different manifest), although I don't see how you'd leverage that technique to support two different users/manifests and use the appropriate app cache depending on which user is logged in. I think this boils down to the Gears 'requiredCookie' attribute was really useful. Is the problem supporting multiple users completely client-side? I can see how that might not work very well. Yeah, I think that's the use case they are trying to support - offline access to web apps where any one of multiple users can log in. I have to say that I'm somewhat fuzzy on the precise use case, though. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Clickjacking and CSRF
Aryeh Gregor wrote on 7/21/2009 5:34 PM: If we could do reports only, then we would probably publish the data live in some form, yes. If it's desirable to add a 'report only' feature to CSP, I'd prefer see a second CSP-related header (X-Content-Security-Policy-ReportOnly???) that implements it rather than adding it to the CSP header. The presence of both headers (CSP and CSPReportOnly) would mean both would be acted upon. There's already been some discussion that authors would iteratively relax CSP until their site worked. I can see where an author enables ReportOnly, their site suddenly works and they mistakenly believe it's properly configured and actively protecting their site. - Bil
Re: [whatwg] Clickjacking and CSRF
On Wed, Jul 22, 2009 at 1:20 PM, Bil Corryb...@corry.biz wrote: If it's desirable to add a 'report only' feature to CSP, I'd prefer see a second CSP-related header (X-Content-Security-Policy-ReportOnly???) that implements it rather than adding it to the CSP header. The presence of both headers (CSP and CSPReportOnly) would mean both would be acted upon. I can't see how that makes a difference either way for any purpose, really. It just seems like it would make it slightly more annoying for authors to deploy, and somewhat more confusing (since the presence of one header would drastically change the semantics of another). There's already been some discussion that authors would iteratively relax CSP until their site worked. I can see where an author enables ReportOnly, their site suddenly works and they mistakenly believe it's properly configured and actively protecting their site. They might also make a typo in the policy file that causes Firefox to ignore the whole thing, and mistakenly believe they're being protected. Or they might enable CSP, then allow inline script and import from arbitrary foreign sites because that's what it took for their ads and Analytics to start working again, and think they're protected. You can't really do much to stop people from having a sense of false security if they neither understand nor test their security system. I don't think it's valuable to try.
Re: [whatwg] Idea: Links w/o end anchors (is possible)
On Wed, Jul 22, 2009 at 10:54:19AM -0500, Tab Atkins Jr. wrote: On Wed, Jul 22, 2009 at 10:31 AM, Julian Reschkejulian.resc...@gmx.de wrote: Tab Atkins Jr. wrote: ... It would be relatively simple to expose a UI that allows one to point at some text and automatically generate an XPointer to the element containing that text. Assuming that you could then generate a url with that information (which would take browser cooperation), you'd be golden. ... For those who don't know it already...: http://codedread.com/fxpointer/. Ah, excellent. Now just get that baked into all the browsers, and we're good. ^_^ ~TJ That would make a lot of people happy... If it had a usable UI. -- Peter
Re: [whatwg] Clickjacking and CSRF
Aryeh Gregor wrote on 7/22/2009 12:38 PM: On Wed, Jul 22, 2009 at 1:20 PM, Bil Corryb...@corry.biz wrote: If it's desirable to add a 'report only' feature to CSP, I'd prefer see a second CSP-related header (X-Content-Security-Policy-ReportOnly???) that implements it rather than adding it to the CSP header. The presence of both headers (CSP and CSPReportOnly) would mean both would be acted upon. I can't see how that makes a difference either way for any purpose, really. It just seems like it would make it slightly more annoying for authors to deploy, and somewhat more confusing (since the presence of one header would drastically change the semantics of another). The idea here is 'when in doubt, favor the more restrictive option.' There shouldn't be both headers, but if there are, then CSP wins. There's already been some discussion that authors would iteratively relax CSP until their site worked. I can see where an author enables ReportOnly, their site suddenly works and they mistakenly believe it's properly configured and actively protecting their site. They might also make a typo in the policy file that causes Firefox to ignore the whole thing, and mistakenly believe they're being protected. This won't happen as CSP explicitly enforces a 'fail closed' policy: https://wiki.mozilla.org/Security/CSP/Spec#Handling_Parse_Errors Or they might enable CSP, then allow inline script and import from arbitrary foreign sites because that's what it took for their ads and Analytics to start working again, and think they're protected. Allowing content from their advertising and analytics providers is far less serious than mistakenly turning on ReportOnly which allows content from any source. You can't really do much to stop people from having a sense of false security if they neither understand nor test their security system. I don't think it's valuable to try. It's valuable to set them up for as much success as possible. - Bil
Re: [whatwg] Definitions of DOMTokenList algorithms and element.classList
On Wed, Jul 22, 2009 at 6:07 PM, Anne van Kesterenann...@opera.com wrote: On Mon, 13 Jul 2009 05:16:19 +0200, Ian Hickson i...@hixie.ch wrote: I've clarified that DOMTokenList is always case-sensitive. We don't want to be adding more quirk-mode behaviours. Using quirks mode is not conforming (i.e. it's not a supported behaviour). Implementation-wise that does not seem nice if you want to use the same optimized object when dealing with style sheets or getElementsByClassName(). Actually for the Mozilla implementation, it's simpler to have it case sensitive (that's not a big difference though). I don't know if that could be more of an issue in other implementations. Sylvain
[whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. Gecko currently sets pageX, clientX, screenX etc. to zero on the source node events (drag, dragend). As far as I know there are no known security flaws surrounding this implementation. Browsers allow positioning values outside the browser window on mousemove events during a mousedown + mousemove operation. --- This issue is related to whether or no a DragEvent is infact a MouseEvent. The current drag specifies that User agents must, every 350ms (±200ms), perform the following steps in sequence.. It doesn't make sense to trigger this event if nothing has changed based on time alone. If something moves in front of it or behind it, it may need to be triggered again, but a user agent should be able to decide whether or not that's a possibility. All current implementations trigger this sequence faster if the mouse is moving. Effectively treating mouse movements as new drag events. Just like mousemove. IMO, it should be specified that mouse movements triggers a new iteration of this sequence, and that current mouse position should be a part of the event. The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. --- (This is a repost because the first two was blocked by mod filter, hopefully this doesn't become a double post.)
Re: [whatwg] Clickjacking and CSRF
On Wed, Jul 22, 2009 at 1:56 PM, Bil Corryb...@corry.biz wrote: The idea here is 'when in doubt, favor the more restrictive option.' There shouldn't be both headers, but if there are, then CSP wins. Ah, I see, you'd only send one header. Well, it still seems like it might be a little more confusing to have essential data split across multiple places (e.g., policy file vs. header name). It's valuable to set them up for as much success as possible. It's a detail that I don't think is really a big deal in any event, so I have no strong opinion. I do think that some report-only mode would be almost essential for safe deployment in complicated preexisting apps.
Re: [whatwg] Clickjacking and CSRF
Aryeh Gregor wrote on 7/22/2009 5:47 PM: On Wed, Jul 22, 2009 at 1:56 PM, Bil Corryb...@corry.biz wrote: The idea here is 'when in doubt, favor the more restrictive option.' There shouldn't be both headers, but if there are, then CSP wins. Ah, I see, you'd only send one header. Well, it still seems like it might be a little more confusing to have essential data split across multiple places (e.g., policy file vs. header name). To clarify, I was thinking this would run CSP in report-only mode: X-Content-Security-Policy-ReportOnly: allow self Then when you're satisfied with the ruleset, you merely rename the header to actually kick it on: X-Content-Security-Policy: allow self - Bil
[whatwg] syncing attachments to an offline-capable client?
Forums, bug trackers, mail programs, photo apps, etc. all have allow users to download attachments or view them inline in the browser. An offline-capable app should be able to sync attachments down to the browser, as data. There may be thousands of such resources for one app, added and removed constantly, as part of data synchronization. Here's one way to sync a single attachment down to an offline-capable client, by abusing the app cache: 1) Client creates a hidden iframe with the URL /manifestwrapper/attachmentID 2) Server responds with a tiny HTML page whose sole purpose is to deliver a manifest attribute, pointing to /manifest/attachmentID 3) The client requests the manifest, which has one URL in it: /attachment/attachmentID 4) Finally, the client requests the attachment and stored it locally. This isn't great, for a lot of reasons: - It makes it hard to uninstall an offline client, because there are potentially thousands of teeny manifests. - It's unlikely to scale well, since it's kind of abusing the browser. - It takes 3 server round trips to sync one attachment. - It can't be done from a worker thread, since an HTML page is needed to provide a manifest attribute. It'd be a lot better to have a JS API to capture new URLs. Since they're web resources, it's tempting to associate this with the app cache. But the update strategy is totally different from the app cache's, so a more data-centric object might be more appropriate. And if it could be pure JS, callable from a worker, even better. Gears has something just like this: http://code.google.com/apis/gears/api_localserver.html#ResourceStore
[whatwg] Encoding declaration state I hate the wording.
This took me a while to figure out. Please change: 4.2.5 The meta element Metadata content. Contexts in which this element may be used: If the charset attribute is present, or if the element is in the Encoding declaration state: in a head element. If the http-equiv attribute is present, and the element is not in the Encoding declaration state: in a head element. If the http-equiv attribute is present, and the element is not in the Encoding declaration state: in a noscript element that is a child of a head element. To: 4.2.5 The meta element Metadata content. Contexts in which this element may be used: If the charset attribute is present, or if the http-equiv attribute is present with a value of content-type: in a head element. If the http-equiv attribute is present, and the http-equiv attribute is present with a value that is not content-type: in a head element. If the http-equiv attribute is present, and the http-equiv attribute is present with a value that is not content-type: in a noscript element that is a child of a head element. And similar with 4.2.5.3. -- Force, my friends, is violence; the supreme authority from which all other authority is derived. - Michael Ironside, Starship Troopers http://www.ChaosReigns.com Guns save lives.
[whatwg] Web Workers and postMessage(): Questions
Hi all, I've been writing some code that uses web workers. It's a very nice addition to the HTML toolbox (kudos!), but I have some questions: First, why does the structured clone algorithm used by postMessage() [1] throw an exception if it encounters cycles? It seems to me that the memory-based logic which is used to catch cycles could easily be modified to resolve them instead. The only possible reason I can think of is to match JSON semantics, and the only reason I can think of to want to match JSON semantics is to make implementers lives easier (witness Firefox 3.5, which just JSONifies objects passed to postMessage()). However, this is a huge limitation, and I'm not sure that the correct trade-off is to make implementers lives easier at the expense of making web designers lives harder. Second, why not walk the prototype chain? Similar rules regarding host objects and regular objects could apply to prototypes. You would want to make sure that multiple references to the same prototype instance result in references to a single prototype clone in the cloned object graph. Again, though, it doesn't sound too hard (though I might just be optimistic). Why not make web designers' lives easier? Overall, it just appears that the current web worker spec ignores the class of computational problems involving results which need to be modeled in a complex way. What do others think? Looking forward to feedback! Daniel [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#structured-clone -- Daniel Gredler http://daniel.gredler.net/
Re: [whatwg] AppCache and javascript url question?
On Sun, Jul 19, 2009 at 3:10 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Jul 2009, Michael Nordman wrote:
On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 4 Jun 2009, Michael Nordman wrote:
What appcache (if any) should the resulting iframes be associated
with? I
think per the spec, the answer is none. Is that the correct answer?
html manifest='myManifestFile'
body
script language=JavaScript
function frameContents1()
{
var doc = frame1.document;
doc.open();
doc.write('img src=image.png');
doc.close();
return;
}
function frameContents2()
{
return hello;
}
/script
iframe name=frame1 src=javascript:parent.frameContents1()
iframe name=frame2 src=javascript:parent.frameContents2()
/body
/html
If there's no manifest=, there's no application cache selected, as
far
as I can tell.
Thats what it looks like to me too in the current draft. Wondering if
thats the right behavior though?
Generally when loading a frame, the appcache from which the doc resource
was loaded gets selected (augmented by an explicit manifest attribute
that can make something 'foreign').
In this case, the src is a script embedded in a page that is appcached,
so in a transitory sense the doc resource was loaded from an appcache,
but that cache does not get selected.
The doc resource was not loaded from the cache, it was loaded from
evaluating JavaScript.
The key phrase was in a transitory sense. The script that was evaluated
was loaded from an appcache.
Feels like maybe image.png should load from myManifestFile in the
sample?
It's trivial for the script to manually include a manifest, if that's what
the script really wants to do.
Not sure that would produce the desired result?
The appcache would attempt to add this javascript url as a 'master' entry.
But it would be rejected since its not an http url and the cache would not
be selected and its image.png would not be loaded. Right?
I don't think we really want to be encouraging javascript: iframes,
anyway.
Very much agreed.
Also, consider this case:
iframe
src=javascript:parent.frameContents3()+frames['otherWin'].frameContents4()
...where frames['otherWin'] is from a different manifest. Now what?
Good question.
Regardless of how complex the script is, there is only one document
containing the javascript url. So in that transitory sense, the appcache
associated with that document (in this case the one containing the iframe
tag).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] syncing attachments to an offline-capable client?
There is a proposal in the w3c world that attempts to address this use case...http://dev.w3.org/2006/webapi/DataCache/ There seems to be a growing consensus (on the public-webapps list) that the feature set described in that proposal should be folded in as an extension to the appcache. The draft encompasses some features that have historically been mentioned for the appcache and are reflective of Gears. On Wed, Jul 22, 2009 at 5:14 PM, Aaron Whyte awh...@google.com wrote: Forums, bug trackers, mail programs, photo apps, etc. all have allow users to download attachments or view them inline in the browser. An offline-capable app should be able to sync attachments down to the browser, as data. There may be thousands of such resources for one app, added and removed constantly, as part of data synchronization. Here's one way to sync a single attachment down to an offline-capable client, by abusing the app cache: 1) Client creates a hidden iframe with the URL /manifestwrapper/attachmentID 2) Server responds with a tiny HTML page whose sole purpose is to deliver a manifest attribute, pointing to /manifest/attachmentID 3) The client requests the manifest, which has one URL in it: /attachment/attachmentID 4) Finally, the client requests the attachment and stored it locally. This isn't great, for a lot of reasons: - It makes it hard to uninstall an offline client, because there are potentially thousands of teeny manifests. - It's unlikely to scale well, since it's kind of abusing the browser. - It takes 3 server round trips to sync one attachment. - It can't be done from a worker thread, since an HTML page is needed to provide a manifest attribute. It'd be a lot better to have a JS API to capture new URLs. Since they're web resources, it's tempting to associate this with the app cache. But the update strategy is totally different from the app cache's, so a more data-centric object might be more appropriate. And if it could be pure JS, callable from a worker, even better. Gears has something just like this: http://code.google.com/apis/gears/api_localserver.html#ResourceStore
Re: [whatwg] Encoding declaration state I hate the wording.
Maybe it would be better to just add A meta element is in an Encoding declaration state when its http-equiv attribute is present with a value of content-type. To the top of the definition of Encoding declaration state: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-content-type If you go to 4.2.5, the meta element, to figure out what constitutes a valid meta element, you see a few uses of the phrase Encoding declaration state. They're all links. You click one, and it takes you to its definition. Which says nothing about how to know if an element is in such a state. Because that's in a table about one page up. -- Whatever you do will be insignificant, but it is very important that you do it. - Mahatma Gandhi http://www.ChaosReigns.com Guns save lives.
[whatwg] HTML form controls inside of editable area
Hi. HTML 5 contentEditable section doesn't define behaviour of HTML form controls inside of editable area explicitly (http://dev.w3.org/html5/spec/Overview.html#user-editing-actions). The question is the following: is behaviour on keyboard or mouse interaction with form controls inside of editable the same like it is for form controls outside of editable area? So that for example if I click on HTML button inside of editable area then will button be clicked and onclick event handler be invoked? Or, for example, if HTML select is focused and I press down arrow key then will selected option be changed? It's obviously some keyboard shortcuts can have one meaning on focused HTML element and another meaning in editable area. It's necessary to define who wins. HTML 5 specification has words confirming implicitly the idea HTML form controls inside of editable area should preserve behaviour. These words are When an editable form control is edited, the changes must be reflected in both its current value and its default value. for select elements it means updating the option elements' defaultSelected DOM attribute as well as the selected DOM attribute which means user should be able to change selected option and therefore it's reasonable to expect form control behaves as usually. Can I get some clarification please? Thank you. Alex.
