Re: [whatwg] nextSiblingElement ?

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] nextSiblingElement ?

[Garrett Smith]

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] A potential slight security enhancement to postMessage

[Collin Jackson]

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] Some questions

[Andrew Sidwell]

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 rectangles

[Ian Hickson]

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 
> () - 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 
> ). 
> 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] A potential slight security enhancement to postMessage

[Maciej Stachowiak]

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 - non-standard globalCompositeOperation

[Ian Hickson]

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] Canvas patterns, and miscellaneous other things

[Ian Hickson]

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.


> "complete" (twice) - looks like 
> it should be dom-img-complete, so it points to #complete.

Fixed.


> "createPattern(image, repetition)" - the parameters should be in s.

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 {
>   att

[whatwg] A potential slight security enhancement to postMessage

[Jeff Walden]

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] Some questions

[Charles]

> 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 
> with  which is entirely pointless...

Semantically, you don't want web video (regardless of format) to be marked
up as ?

> 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

Re: [whatwg] scope attribute on td

[Keryx Web]

James Graham skrev:
FWIW the HTML 4 behavior which turns a  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 questions

[Oliver Hunt]

On 30/01/2008, at 12:54 PM, Charles wrote:


Thanks for the conversation, folks!

I was hoping that  would make 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  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  with  
 which is entirely pointless, the purpose of the video tag is  
to provide a standardised native html element, not another plugin  
mechanism to replace  -- 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  that's what  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] Some questions

[Charles]

Thanks for the conversation, folks!

I was hoping that  would make 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 
 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] Referer header sent with ?

[Ian Hickson]

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  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  is not needed at all -- a better attack 
> can be performed with simple  or .
>
> - 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  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  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  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 questions

[J. King]

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  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?




I don't understand why you're complicating things by talking about  
Silverlight, here.


--
J. King
http://jking.dark-phantasy.com/