Re: [whatwg] Some video questions
On Tue, 29 Jan 2008 20:57:35 -0500, Charles [EMAIL PROTECTED] wrote: Here's a precise scenario: A user creates an HTML5 page, and of course uses the video element to embed their Windows Media content. They're rude, and could care less about Mac or Linux support. Will Safari provide an API that allows Microsoft to support this scenario by enhancing their Silverlight plug-in? Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? http://www.microsoft.com/windows/windowsmedia/player/wmcomponents.mspx I don't understand why you're complicating things by talking about Silverlight, here. -- J. King http://jking.dark-phantasy.com/
Re: [whatwg] Referer header sent with a ping?
On Wed, 23 Jan 2008, Darin Fisher wrote: HTTP auth headers may be required to access the internet (e.g., to pass a request through a proxy server), so this should only apply to the Authorization request header, right? On Thu, 24 Jan 2008, Kornel Lesinski wrote: I don't think that attack vector discussed on mozilla.dev.platform should be taken so seriously. In my opinion case when a ping enables attack (instead of being just one of countless possible attack vectors) is very very unlikely: - If site accepts data from GET as well as POST (e.g. is using PHP's register_globals), then a ping is not needed at all -- a better attack can be performed with simple img src or a href. - If site allows HTML from untrusted source and allows ping to slip through, it is very likely that the site can be tricked to allow other potentially dangerous attributes or scripts. - Because not all browsers/proxies/firewalls send Referer header, public-facing websites have to accept POSTs without Referer, so forbidding Referer for a ping may not increase security and even make it harder to protect against CSRF. OTOH Referer can help save bandwidth. Without it page may need to include its own URL in every a ping attribute. On pages with lots of links (portals, directories) this can noticeably increases size of HTML. Maybe these problems could be solved with an additional HTTP header in the ping request? e.g.: X-Ping: from=http://example.com/here;, to=http://example.com/there; This would make it easy to protect against unwanted ping-originated requests (one could configure server or set up application firewall to filter pings), and URL in a ping wouldn't have to contain copies of page's URL and href. What do people think of this idea: We make Referer always have the value PING. We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. We continue to send all cookie and authentication headers. What do people think? Would this address all the issues raised? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some video questions
Thanks for the conversation, folks! I was hoping that video would make Objecty http://wiltgen.net/objecty/ redundant by making it easy for authors to embed video in a very simple, normalized fashion across formats, browsers and OSs. Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? Unfortunately not. There's the installed base problem we've talked about a lot in the thread, plus Flip4Mac WM doesn't support all Windows Media features. Really, it was always just a stop-gap until Silverlight. -- Charles
Re: [whatwg] Some video questions
On 30/01/2008, at 12:54 PM, Charles wrote: Thanks for the conversation, folks! I was hoping that video would make Objecty http://wiltgen.net/ objecty/ redundant by making it easy for authors to embed video in a very simple, normalized fashion across formats, browsers and OSs. Now I understand that video will be considered successful without having fixed video embeddeding in general, which is fine. What part of video does it not fix? It defines a standard API for all implementers, with standard html-native markup. Afaict you just want to be able to replace your use of object with video which is entirely pointless, the purpose of the video tag is to provide a standardised native html element, not another plugin mechanism to replace object -- by definition a plugin is both non- native and non-standard so has no relevance here. Once the spec is complete you'll be able to use standard html to say here is a video, then use JS to bind custom controls (if you so desire), and everything will be wholesome and good. If you want to use a plugin use object that's what object is for. --Oliver Microsoft provides a QuickTime component for Windows Media; would that not be sufficient? Unfortunately not. There's the installed base problem we've talked about a lot in the thread, plus Flip4Mac WM doesn't support all Windows Media features. Really, it was always just a stop-gap until Silverlight. -- Charles
Re: [whatwg] scope attribute on td
James Graham skrev: FWIW the HTML 4 behavior which turns a td scope=somthing into a heading from the point of view of the UA is, in principle, useful since there are cases (particularly for row headings) where one cell is effectively both data and a heading but the formatting should be data-like rather than heading like. I use TH for those cases and fix the formatting with CSS... To keep the scope attribute for formatting purposes is a really bad argument, IMHO. If an element is turned into a heading it should be marked up as a heading. Lars Gunther
Re: [whatwg] Some video questions
What part of video does it not fix? It fixes the problem for formats supported by the player(s) that a particular browser vendor thinks is important. That's good as far as it goes, don't get me wrong. I understand Apple's POV is that cascading source elements makes the debate moot. Unfortunately, content providers usually can't provide the same content in different formats -- either it's too expensive to re-author a similar experience for multiple formats, or functionality they need isn't available in multiple formats, or it's too costly to create server farms for multiple formats, etc. History shows us that even when they can, they don't. Afaict you just want to be able to replace your use of object with video which is entirely pointless... Semantically, you don't want web video (regardless of format) to be marked up as video? Once the spec is complete you'll be able to use standard html to say here is a video, then use JS to bind custom controls (if you so desire), and everything will be wholesome and good. Again, that's great for what it is. -- Charles
[whatwg] A potential slight security enhancement to postMessage
I briefly wrote up some documentation on postMessage for the Mozilla Developer Center: http://developer.mozilla.org/en/docs/DOM:window.postMessage If you pull it up, you'll note two places where I include big, huge, overbearing, somewhat-exaggerating injunctions about first checking the domain/uri/source properties of the received message before trusting the sent data. Writing those got me thinking: what if we could enforce not touching the data before verifying the sender's identity? Specifically, what if we required that either .domain or .uri be read prior to allowing .data to be successfully accessed, say, without throwing a security error? (No reason comes to mind for .source to participate in this scheme, either to throw or to allow access to .data, but I haven't given it serious thought.) This would prevent unknowing misuse of this functionality, and safe uses wouldn't be affected. I think this would only apply to the event dispatched by postMessage, not to MessageEvent, as the latter is same-origin and there's no harm to a same-origin MessageEvent. Thoughts? A no-harm slight increase of the ability to prevent incorrect use of postMessage, or excessive nannying? Jeff
Re: [whatwg] Canvas - non-standard globalCompositeOperation
On Thu, 28 Jun 2007, Philip Taylor wrote: In addition to the standard values for globalCompositeOperation (and ignoring 'darker'), Gecko supports: [...] Webkit supports: [...] [...] As far as I can imagine, for each non-standard value, the possible situations are: * No content relies on that value. = Web browsers should remove support for it: it has no purpose, and it may result in authors accidentally using that value and becoming confused when their code doesn't work in other browsers which will be irritating for everyone and it will evolve into the next situation: * Web content relies on that value. = It should be added to the spec, because it's necessary for handling web content. * Non-web, browser-specific content (extensions, widgets, etc) relies on that value, and web content doesn't. = It should be disabled except when run in the extension/widget/etc context, to avoid the problems as in the first case. That may cause minor confusion to the extension/widget/etc authors about why their code [which is relying on undocumented features] works differently if they run it on the web instead, but that seems insignificant compared to having interoperability problems on the web. * Nobody cares. = Nothing happens. Am I missing any issues here? Would any browser developer think one of the first three situations applies, and be willing to make the necessary changes in that case? I agree with your conclusions. I've not changed the spec. I recommend that test suites test for the lack of support here. If we find content relies on these, I can add them to the spec later. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A potential slight security enhancement to postMessage
On Jan 30, 2008, at 6:00 PM, Jeff Walden wrote: I briefly wrote up some documentation on postMessage for the Mozilla Developer Center: http://developer.mozilla.org/en/docs/DOM:window.postMessage If you pull it up, you'll note two places where I include big, huge, overbearing, somewhat-exaggerating injunctions about first checking the domain/uri/source properties of the received message before trusting the sent data. Writing those got me thinking: what if we could enforce not touching the data before verifying the sender's identity? Specifically, what if we required that either .domain or .uri be read prior to allowing .data to be successfully accessed, say, without throwing a security error? (No reason comes to mind for .source to participate in this scheme, either to throw or to allow access to .data, but I haven't given it serious thought.) This would prevent unknowing misuse of this functionality, and safe uses wouldn't be affected. I think this would only apply to the event dispatched by postMessage, not to MessageEvent, as the latter is same-origin and there's no harm to a same-origin MessageEvent. Thoughts? A no-harm slight increase of the ability to prevent incorrect use of postMessage, or excessive nannying? The more convenient version of that would be to require clients to describe allowed senders when registering for the event in some way. That would seem more like a convenience and less like a hoop to jump through. Regards, Maciej
Re: [whatwg] Canvas rectangles
On Sun, 1 Jul 2007, Philip Taylor wrote: The clearRect() method ... The fillRect() method ... The strokeRect() method ... - should say clearRect(x, y, w, h) etc, for consistency with all the other function definitions. Fixed. Shapes are ... subject to ... shadow effects, global alpha, ... and global composition operators is a bit confusing since clearRect isn't subject to those things. (Actually, clearRect is subject to shadow effects in Safari, and subject to composition operators in Opera, but I'd say those are just bugs.) Fixed. strokeRect: The definition is vague about where line-joins occur, in the normal case and in the If only one of [width and height] is zero ... case, since it doesn't really say that it's a closed path. Fixed as part of the earlier changes to lines and strokes, I think. Is it better now? There is minor implementation disagreement in the zero-width case (http://canvex.lazyilluminati.com/misc/rects.html) - in Safari it is equivalent to drawing a rectangle with infinitesimal width (hence with four line-joins connecting perpendicular edges), whereas in FF/Opera/spec it's equivalent to a line (with two line-joins connecting parallel edges). Also, Safari/FF3 draw stuff in the width=height=0 case, though that's related to the more general line-caps-on-zero-length-lines thing (as in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011883.html). I believe it would be nice (for consistency and predictability) if strokeRect worked the same as rect+stroke (and the same as moveTo+lineTo+lineTo+lineTo+closePath+stroke) - that is what everyone except Safari does, but it doesn't seem to be explicit or obvious in the spec. This is basically now the case, I think, but mostly because of the changes we made before for zero-length line segments, and so on. Perhaps it would be easier and most precise to define strokeRect in terms of existing methods, like: The strokeRect(x, y, w, h) method must be equivalent to the following sequence of method calls: beginPath(); rect(x, y, w, h); stroke(); except with the current path after calling the strokeRect method remaining the same as before the call. The except is why I don't really want to do this. Could you take a look again and let me know if you think the new definitions work ok? Don't hesitate to tell me that they're still broken. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some video questions
Charles wrote: Unfortunately, content providers usually can't provide the same content in different formats -- either it's too expensive to re-author a similar experience for multiple formats, or functionality they need isn't available in multiple formats, Transcoding video really isn't hard thesedays -- e.g. you can download VLC and set a job going within minutes. or it's too costly to create server farms for multiple formats, etc. History shows us that even when they can, they don't. This, however, is a fair point. Andrew Sidwell
Re: [whatwg] Canvas patterns, and miscellaneous other things
On Sat, 23 Jun 2007, Philip Taylor wrote:
What should happen if you try drawing a 0x0-pixel repeating pattern? (I
can't find a way to make a 0x0 image that any browser will load, but the
spec says you can make a 0x0 canvas. Firefox and Opera can't make a 0x0
canvas - it acts like it's 300x150 pixels instead. Safari returns null
from createPattern when it's 0x0.)
I've made this do the same as passing an incomplete Image object.
On a somewhat related note: What should canvas.width = canvas.height =
0; canvas.toDataURL() do, given that you can never make a valid 0x0
PNG? (Firefox and Opera make the canvas 300x150 pixels instead, so you
can't actually get it that small. Safari can make it that small, but
doesn't implement toDataURL.)
I've made toDataURL() return data:, if it's faced with a 0-pixel image.
It's arbitrary, but I guess it represents the image, at least!
Similarly, what should toDataURL do when the canvas is really large and
the browser doesn't want to give you a data URI? (Opera returns
'undefined' if it's = 30001 pixels in any dimension, and crashes if
it's 3 in each dimension. Firefox (2 and trunk) crashes or hangs on
Linux if it's = 32768 pixels in any dimension, and crashes on Windows
if it's = 65536 pixels).
User agents may impose implementation-specific limits on otherwise
unconstrained inputs, e.g. to prevent denial of service attacks, to guard
against running out of memory, or to work around platform-specific
limitations. (See ...#hardwareLimitations.)
More generally, the spec says If the user agent does not support the
requested type, it must return the image using the PNG format - what if
it does support the requested type, but still doesn't want to give you a
data URI, e.g. because it's the wrong size (too large, too small, not a
multiple of 4, etc) or because of other environmental factors (e.g. it
wants you to do getContext('vendor-2d').enableVectorCapture() before
toDataURL('image/svg+xml'))? (Presumably it would be some combination of
falling back to PNG (if you asked for something else), returning
undefined, and throwing exceptions.)
The spec doesn't define support the requested type. I could definitely
see arguing that support of the requested type is dependent upon other
factors, so that returning a PNG is ok. Throwing exceptions in the face of
hardware limitations (data too big) is always allowed, as noted above.
Also, browsers could crop or extend or stretch the image if the image
format requires a particular multiple in its output dimensions. That's
just part of outputting the image.
If the empty string or null is specified, repeat must be assumed. -
why allow null, but not undefined or missing? (It would seem quite
reasonable for createPattern(img) to default to a repeating pattern).
(Currently all implementations throw exceptions for undefined/missing,
and Opera and Safari throw for null.)
'undefined' is a JS-specific thing, and I'm assuming that the DOM Bindings
for JS spec will define how 'undefined' really means 'null'. Same with
missing arguments.
'complete' for images is underspecified, so it's not possible to test
the related createPattern/drawImage requirements. (Is it set before
onload is called?
As defined, yes. I've called this out, but it was already unambiguous.
Can it be set as soon as the Image() constructor returns?
No, since you can't have an image set from the Image() constructor (it
doesn't take a URI argument).
(I'm aware that this doesn't match implementations.)
Can it be set at an arbitrary point during execution of the script that
called the Image() constructor?
As defined, yes.
Is it reset when you change src? [...])
Yes, according to the spec today, since the definition is dependent on
the src attribute.
I'm not really sure I agree that it's underspecified, to be honest.
However, feel free to raise this again if you want it changed (if possible
in a separate e-mail).
About radial gradients: If x0 = x1 and y0 = y1 and r0 = r1, then the
radial gradient must paint nothing. - that conflicts with the previous
must for following the algorithm, so it's not precise about which you
must do. It should probably say If ... then the radial gradient must
paint nothing. Otherwise, radial gradients must be rendered by following
these steps:.
Fixed.
code title=dom-attr-completecomplete/code (twice) - looks like
it should be dom-img-complete, so it points to #complete.
Fixed.
createPattern(image, repetition) - the parameters should be in vars.
Fixed.
The images are not be scaled by this process - s/be //
Fixed.
interface HTMLCanvasElement : HTMLElement {
attribute unsigned long width;
attribute unsigned long height;
^ incorrect indentation (should have two more spaces).
Fixed.
Somewhere totally unrelated:
interface HTMLDetailsElement : HTMLElement {
attribute boolean open;
^ incorrect indentation
Re: [whatwg] A potential slight security enhancement to postMessage
Here is a suggestion for a backwards-compatible addition to the
postMessage specification:
Currently postMessage is great for sending authenticated messages
between frames. The receiver knows exactly where each message came
from. However, it doesn't provide any confidentiality guarantees. When
you're posting a message to a window, you have no way of knowing who
is listening on the other end, because the same-origin policy prevents
you from reading the domain and URI of that window. The window may
have been showing a page loaded from foo.com the last time you
received a message from it, but it might be displaying content from
bar.com now; if you send it a message, you don't whether the message
will be received by foo.com or bar.com.
For non-security-sensitive messages, like change your font color to
red, confidentiality might not be needed. However, if the message
you're trying to send contains a password, it would be nice to be able
to specify which domain you're trying to send it to.
The postMessage API could be extended to provide confidentiality by
adding some optional arguments:
void postMessage(in DOMString message, [optional] in DOMString domain,
[optional] in DOMString uri);
If domain or uri are specified, the browser would only deliver the
message if the recipient's location matches the specified domain and/or
URI. (Being able to specify the URI allows sites to differentiate
between http and https URIs.) If domain and uri are not defined,
the message would be delivered regardless of who the recipient is,
making this change backwards compatible for sites that aren't aware
of the optional parameters.
For privacy, postMessage should be designed not to reveal the domain
or URI of the receiving window, so if there is a mismatch, the message
should be silently dropped.
Providing the domain and URI for replies should be easy since these
values are already parameters of the event. Here is an example of code
that specifies the expected domain and URI for the recipient:
document.addEventListener('message', receiver, false);
function receiver(e) {
if (e.domain == 'example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.domain, e.uri);
} else {
alert(e.data);
}
}
}
Re: [whatwg] nextSiblingElement ?
On Jan 24, 2008 5:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008, Garrett Smith wrote: nextSibling and previousSibling are useful, but not always what I want. I usually want to get a siblingElement than a sibling, which might be a text node. One of the following drafts probably already handles your needs: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#TreeWalker http://www.w3.org/TR/ElementTraversal/ To create a tree walker, define an accept() and then iterate through nodes, would be more effort than rewriting the hand-rolled Dom.getNextSibling function I posted every time. I guess I could replace the source code of my dom.getNextSiblingElement, but a for() loop is probably simpler. REally, all I want is nextSiblingElement/previousSiblingElement/childElements properties so I don't have to have library code or write a for() loop every time i want to just find the next sibling element. Garrett HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] nextSiblingElement ?
On Wed, 30 Jan 2008, Garrett Smith wrote: One of the following drafts probably already handles your needs: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#TreeWalker http://www.w3.org/TR/ElementTraversal/ To create a tree walker, define an accept() and then iterate through nodes, would be more effort than rewriting the hand-rolled Dom.getNextSibling function I posted every time. I guess I could replace the source code of my dom.getNextSiblingElement, but a for() loop is probably simpler. REally, all I want is nextSiblingElement/previousSiblingElement/childElements properties so I don't have to have library code or write a for() loop every time i want to just find the next sibling element. Well then the second link I posted above is probably what you want. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
