Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote:

>
> c) that the contents of the container, once fetched and un-packed,
> logically 'shadow' the directory where the container came from.
>

It sounds like that affects all loads, which leads to issues:

So if I load 
http://www.example.com/x.m21#y.htmland
(in the same document, or in another tab?) load
http://www.example.com/z.html, and x.m21 contains a z.html but the server
also responds to http://example.com/z.html, does the second load (z.html)
come from the server or the container? Does it depend on whether the second
load starts before the first load finishes?

The same questions apply to Russell's proposal.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  My complaint was about how the jar URL scheme wannabe conceptually
> differs from the schemes we already officially have, not about how ugly it
> is to have two consecutive colons.  It is ugly but it does not matter.  What
> matters is that a scheme is being promoted that is specific to one content
> type, just as the APPLET element is discouraged for the same reason.
>

Suppose it was called "archive:" instead of "jar:" and the spec was made
open-ended so that other archive types other than ZIP files were permitted.
Would your objection still apply?


> Anyway, it is not obvious at all that linking inside a packaged HTML
> application should be supported.
>

Multiple entry points to a single application are common.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Kristof Zelechovski]

Archive: is not generic enough but perhaps you could bend the URL notation
to embrace something like inside:.  I still would not recommend it but it
would not make me that sore.

How about http://www.site.com/app.jar>?

The user agent would be required to append a query string to local
hyperlinks and that parameter would be reserved (or rename it to
h809370dfwhbwa0r92347090).

Of course this URL scheme would never leak to HTTP.

OTOH, you can simulate several entry points by having all supported entry
points on the start page (à la Microsoft Access) and have the user navigate
to what she needs.  I do not think this would be prohibitive from the
customer’s point of view.  And I am sure there is no need to publish each
local address.

Chris

 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert
O'Callahan
Sent: Tuesday, July 29, 2008 9:55 AM
To: Kristof Zelechovski
Cc: Adrian Sutton; Adam Barth; [EMAIL PROTECTED]; Russell Leggett; Philipp
Serafin
Subject: Re: [whatwg] Application deployment

 

On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski <[EMAIL PROTECTED]>
wrote:

My complaint was about how the jar URL scheme wannabe conceptually differs
from the schemes we already officially have, not about how ugly it is to
have two consecutive colons.  It is ugly but it does not matter.  What
matters is that a scheme is being promoted that is specific to one content
type, just as the APPLET element is discouraged for the same reason.  


Suppose it was called "archive:" instead of "jar:" and the spec was made
open-ended so that other archive types other than ZIP files were permitted.
Would your objection still apply?

 

Anyway, it is not obvious at all that linking inside a packaged HTML
application should be supported.


Multiple entry points to a single application are common.

Rob

Re: [whatwg] Application deployment

[Kristof Zelechovski]

I think that just puts some restrictions on the arrangement on the server.
My guess is that once a resource is shadowed, it becomes invisible, and the
server should not serve resources that might be shadowed unless the
publisher knows what she is doing.  It is not the only way to make a site
inconsistent.

Chris

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan
Sent: Tuesday, July 29, 2008 9:51 AM
To: Dave Singer
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] Application deployment

 

On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote:


c) that the contents of the container, once fetched and un-packed, logically
'shadow' the directory where the container came from.


It sounds like that affects all loads, which leads to issues:

So if I load 
http://www.example.com/x.m21#y.html and (in the same document, or in another
tab?) load http://www.example.com/z.html, and x.m21 contains a z.html but
the server also responds to http://example.com/z.html, does the second load
(z.html) come from the server or the container? Does it depend on whether
the second load starts before the first load finishes?

The same questions apply to Russell's proposal.

Rob

 

Re: [whatwg] shadow compositing oddities

[Oliver Hunt]

On Jul 27, 2008, at 12:06 PM, Eric Butler wrote:

It would seem Safari isn't quite following the spec here, since it  
appears to never draw shadows when the shadow color is fully  
transparent or something and doesn't encounter these issues. I'm not  
sure that should be the correct behavior since transparent shadows  
can have an effect, but I do think there should be some way to  
explicitly disable shadows, since there is no shadow color/offset  
that can be set such that shadows will have no effect on any of the  
composite operators.


By default the shadowBlur is 0, which the spec states should not draw  
anything -- so that should act as an explicit mechanism for disabling  
shadows should it not?  It's possible i've missed something, but this  
would appear to accomplish what you desire afaict.



-Eric Butler


--Oliver Hunt

Re: [whatwg] style='' on every element

[Ian Hickson]

On Fri, 4 May 2007, Henri Sivonen wrote:
>
> Re: http://krijnhoetmer.nl/irc-logs/whatwg/20070503
> 
> First, I hope that we are in agreement that the following are realities:
>  * Browsers will have to support style='' on every element.

Yes.


>  * When you make something a critical mass of authors really want to do 
> non-conforming because it is bad, the authors find worse workarounds 
> that are not caught by checkers. Case study: target='' vs. 
> window.open().

Yes. style="" is allowed everywhere now.


>  *  with a transparent content model is not backwards-compatible 
> with existing Gecko text/html parsing.

Ok.  is gone.


>  * When a conformance definition outlaws something that works and that a 
> critical mass of authors want to do, the respect for the conformance 
> definition as a whole is diluted.

To some extent, though if what they want to do is bad, e.g. using tables 
for layout, or not configuring their servers (and thus sending their PNG 
images as text/html or their videos as text/plain), then it is still worth 
calling it out as errorneous.


>  * Defining two conformance levels (ideal and realistic) doesn't 
> eradicate the difference of realistic and idealistic. Case study: Strict 
> and Transitional.

I don't think Strict vs Transitional is equivalent to what I want to do.

With Strict vs Transitional, you declare your intent, and then the 
validator tells you you got it right.

What I want is that you don't declare intent, and the validator tells you 
if you got an A+ or a B. Both passing grades, but one is better than the 
other. It's a different attitude, IMHO.


>  * The way  has been currently drafted is a political failure,
> because instead of attaching the stigma of  to style='' it has attached
> the stigma of  to HTML5.

n/a now.


>  * As implemented, style='' doesn't provide for media query-scoped styling.

Right, we have 

Re: [whatwg]

[Ian Hickson]

(I'm replying only to the more salient e-mails in this thread, as the 
others mostly just repeated stuff. I'm also only cc'ing whatwg, since that 
seems to be where most of the contributors on this thread were subscribed 
to -- please don't cross-post, as it results in threads that appears to be 
missing parts in both lists, when people only subscribed to one list reply 
to e-mails from people on both lists.)

On Thu, 3 May 2007, Sander Tekelenburg wrote:
> At 06:48 +1000 UTC, on 2007-05-03, Adrian Sutton wrote:
> > On 3/5/07 2:23 AM, "Sander Tekelenburg" <[EMAIL PROTECTED]> wrote:
> > > [HTML -> PDF converters ignore CSS]
> > >
> > > OK. Real world issues. But that doesn't mean that the HTML spec is 
> > > the place to fix those. Looks more like an opportunity for better 
> > > PDF generators to grab market share and for IE to fix security bugs.
> >
> > Well sure you can ignore the real world if you like, I'm just letting 
> > you know what's currently happening. If the spec chooses to ignore 
> > that then it's gambling on the fact that implementors care more about 
> > being spec compliant than making things work for their clients.
> 
> I don't think we need look at it in such a dramatic way. While some 
> people may 'need'  because their HTML -> PDF converter ignores 
> CSS, I imagine they'd much rather have a HTML -> PDF converter that 
> *does* support CSS. That would give them much more control over their 
> final product after all.
> 
> Now if there is something about the HTML spec that stands in the way of 
> HTML->PDF converters to support CSS, that would logically be something 
> to try to fix in the HTML spec. But otherwise I don't see why HTML 
> should try to solve it, or even how it *could*. Authors can generate 
>  already anyway. Their document just won't be conforming. What 
> would those authors win by  being conforming? And then what about 
> the rest of their problems? Because if their problem is their tool 
> ignores CSS, they'll likely need much more presentational HTML than just 
> .
> 
> And while we add all that presentational HTML to the spec, some 
> enterprising hacker builds a HTML->PDF converter that has CSS support -- 
> we'll have a spec allowing things we didn't really want to allow and for 
> which there's not even a use case anymore.

I tend to agree with this.


On Tue, 8 May 2007, Adrian Sutton wrote:
> On 8/5/07 8:13 PM, "Adrian Lynch" <[EMAIL PROTECTED]> wrote:
> >
> > I am sure there are just as many ingrained CMS's producing  tags 
> > in their output without using a WYSIWYG editor - they will need to be 
> > modified to meet specification, but WYSIWYG editors get a reprieve? 
> > Surely making a WYSIWYG editor remove font tags is no harder than any 
> > other system. Or am I seeing it from the wrong angle?
> 
> The issue isn't that it's hard to fix the WYSIWYG editor, the issue is 
> that it's hard to fix all the rest of the systems the client wants and 
> the fact that clients tend to want a font menu in their editor otherwise 
> they completely eliminate it from consideration without even talking to 
> the vendor. It's simple to make the font menu apply fonts using a span 
> tag and inline styles but that's no better than using a font tag and it 
> breaks some backend processing systems (PDF generation being the one 
> that I encounter most).
> 
> > Our CMS disallows any font menu/tags at all, has done for about 18 
> > months. Sure some clients question it initially, but after an 
> > explanation of the benefits no client has requested the feature be 
> > added back in.
> 
> I'm glad to hear it, sadly it doesn't reflect my experience despite my 
> trying.

We have to aim for the future, not the past. By the time HTML5 is done, 
hopefully non-CSS-capable backend systems will be a thing of the past.


On Wed, 9 May 2007, Adrian Lynch wrote:
> 
> I also disagree - using  and in-line styles is a significant 
> improvement on using the  tag.  is a well established 
> neutral container, whereas  is purely presentational. Again, I 
> don't see why this is even being questioned.

This I don't really agree with, but it's mostly moot. Having  with 
only style="" vs  with only style="" gains us nothing. Having the 
presentational attributes loses us valuable mindshare.


On Wed, 9 May 2007, Adrian Sutton wrote:
> 
> Let me first just reiterate:
> 1. The font tag allowance in the current spec is pointless, does not
> actually help any of the issues I've mentioned and needs to be removed.

It's gone now.


> 2. I strongly recommend that people don't include a font menu and 
> instead use CSS to apply styling to ensure a consistent look for their 
> site.
> 
> The only reason I said anything in this thread is so that the list was 
> aware of the realities of what a WYSIWYG HTML editor has to deal with.
> 
> Now as for particular use cases - there are many people who are using 
> HTML editors as a replacement for a word processor. They may be using an 
> internal wiki where 

Re: [whatwg] shadow compositing oddities

[Oliver Hunt]

On Jul 29, 2008, at 3:56 AM, Oliver Hunt wrote:



On Jul 27, 2008, at 12:06 PM, Eric Butler wrote:

It would seem Safari isn't quite following the spec here, since it  
appears to never draw shadows when the shadow color is fully  
transparent or something and doesn't encounter these issues. I'm  
not sure that should be the correct behavior since transparent  
shadows can have an effect, but I do think there should be some way  
to explicitly disable shadows, since there is no shadow color/ 
offset that can be set such that shadows will have no effect on any  
of the composite operators.


By default the shadowBlur is 0, which the spec states should not  
draw anything -- so that should act as an explicit mechanism for  
disabling shadows should it not?  It's possible i've missed  
something, but this would appear to accomplish what you desire afaict.
Philip Taylor has corrected my obvious mistake (eg. drawing a non- 
opaque object or with non 0,0 shadow offsets)


We could special case opacity 0, with 0,0 offset, and 0 blur radius as  
being a "do not draw shadow" flag perhaps?






-Eric Butler


--Oliver Hunt

Re: [whatwg]

[Kristof Zelechovski]

I think corporate and community flavors are out of scope; they can do
whatever they like, including having a custom validator and browser.  On the
other hand, if there is a way to such content to get published to the WWW,
the publisher should transform the content and/or discipline the authors.
The transformation will, of course, depend on the particular content, and
should probably involve considerations the authors have no chance of taking.
Chris


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Tuesday, July 29, 2008 12:49 PM
To: Sander Tekelenburg; Adrian Sutton; Adrian Lynch; Benjamin Hawkes-Lewis
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] 


On Wed, 9 May 2007, Adrian Sutton wrote:
> 
> 2. I strongly recommend that people don't include a font menu and 
> instead use CSS to apply styling to ensure a consistent look for their 
> site.
> 
> The only reason I said anything in this thread is so that the list was 
> aware of the realities of what a WYSIWYG HTML editor has to deal with.
> 
> Now as for particular use cases - there are many people who are using 
> HTML editors as a replacement for a word processor. They may be using an 
> internal wiki where anything goes, a content management system or a 
> range of other systems. These people basically don't care about content 
> vs presentation, they want it to work like Word does and as such they 
> want a font menu, color menus, the whole lot. For them it works and 
> since I'm not an on-site consultant, I don't necessarily have all the 
> details of why they want it to work this way. What I do know is that 
> there are people who want to use presentational markup in HTML. This use 
> case is completely supported by inline styles and span tags, there's no 
> need for an exception in the spec.
> 
> Hopefully that clears up the confusion over what I'm seeing our clients 
> do vs what I think the spec should include.

Sadly those systems end up tied to a particular medium, and fail to render 
in a good way for, say, users of text browsers or speech renderers. Not 
sure what to do about that though.

Re: [whatwg] Application deployment

[Russell Leggett]

>
> So if I load 
> http://www.example.com/x.m21#y.html and
> (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.


Yes, the one major hang up that I foresee is how a browser should handle
asynchronous loading. How would it know the contents of the archive before
it loaded the archive so it did not try to load the same files directly? The
simple answer would be to load the archive(s) synchronously. In my previous
example:









The browser could begin loading the zip, and during the load wait before
loading any other files. In an effort to take advantage of multiple
connections, multiple archives could be used. Multiple archives could be
loaded asynchronously without issue.

As for references in a different tab, if the separate tab/document did not
reference the zip archive first, it would operate as normal. It would check
the cache and then attempt to load. If the zip had been loaded from the
first page already, the file would be present in the cache, and if not, then
the browser would attempt to retrieve it from the server.

My proposal is only intended as a way to make HTML work the way it was
intended and remain efficient.  CSS sprites and concatenated scripts are
assumed for any high performance site, but they add an unnecessary level of
complexity. Other suggestions such as HTTP pipelining and the jar protocol
are more complex and out of scope of the HTML5 specification. I think my
proposal degrades gracefully, and while I am not a browser manufacturer, it
seems relatively simple to implement.

Russ

On Tue, Jul 29, 2008 at 3:51 AM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote:
>
>>
>> c) that the contents of the container, once fetched and un-packed,
>> logically 'shadow' the directory where the container came from.
>>
>
> It sounds like that affects all loads, which leads to issues:
>
> So if I load 
> http://www.example.com/x.m21#y.htmland 
> (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Re: [whatwg] shadow compositing oddities

[Philip Taylor]

On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler <[EMAIL PROTECTED]> wrote:
> [...]
> However, following the spec's drawing model, there are a few operators that
> behave rather unexpectedly if the shadow color is left at its default value.
> For instance, since A in B always results in transparency if either A or B
> is fully transparent, source-in will always simply clear the clipping region
> to fully transparent no matter what the source and destination are.

Oops - that does seem quite broken. (It's probably my fault - I didn't
notice that problem when I was looking at how shadows should work...)

> It would seem Safari isn't quite following the spec here, since it appears
> to never draw shadows when the shadow color is fully transparent or
> something and doesn't encounter these issues.

As far as I can tell: It never draws shadows when shadowColor.alpha <
1/256, regardless of the other attributes. Also, it never draws
shadows when blur=0 and abs(offsetX) <= 1 and abs(offsetY) <= 1,
regardless of the colour.

In the cases where it does draw shadows, there's also an issue that
its compositor ignores the area outside the shape that's being drawn
(instead of treating it as transparent-black, as is required by the
spec and implemented by Opera and (usually) Firefox) - so in cases
like http://philip.html5.org/demos/canvas/shadow-composite.html with
the source-in mode, WebKit fails to clear the area outside the
shape/shadow to transparent-black. (I'm testing with Safari 3.0.4 - I
hope not much has changed since then). That is probably a sufficiently
unusual situation that it's sensible for the spec to stay as it is and
require WebKit to change, though the spec still needs to change for
the default shadows-disabled case.

-- 
Philip Taylor
[EMAIL PROTECTED]

Re: [whatwg] pushState

[Jonas Sicking]

Ian Hickson wrote:

On Fri, 25 Jul 2008, Jonas Sicking wrote:

So what I think we should do is to enforce that 'data' is a JSON
serializable object.


(We need a better term -- and definition -- for this.)


I'll check with the ECMA Script folks, but this one might be an
alternative to link to:

http://wiki.ecmascript.org/doku.php?id=es3.1:json_support

State that the object passed as 'data' is passed to JSON.parse with the
second argument not specified. Any exception thrown is forwarded out to
the caller of pushState as usual.

When entering a SH state for which a Document has been destroyed, we 
load the URL associated with that SH entry. After the 'load' event for 
the Document has fired, and if a data object was provided in the 
pushState call for the SH entry, we fire a PopStateEvent event 
containing the data stored for the object.


How would this work with bookmarking?


Just as specified (or at least intended) in the spec right now.

Say that the user starts on page1.html

   (bookmarks page1.html)
pushState("title", "data")
   (bookmarks page1.html)
pushState("title", "data", "page2.html")
   (bookmarks page2.html)

Additionally, a UA is free to add the ability to store the data 
parameter in its bookmark storage. For example firefox under some 
circumstances flags URIs in the bookmark store as POST URIs, i.e. they 
should be fetched with POST rather than GET (this is specifically for 
search engine bookmarks). Similarly the data can be stored alongside the 
URI for the bookmark, however this is optional, just like the fastback 
cache.


/ Jonas

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett
<[EMAIL PROTECTED]>wrote:

> Yes, the one major hang up that I foresee is how a browser should handle
> asynchronous loading. How would it know the contents of the archive before
> it loaded the archive so it did not try to load the same files directly? The
> simple answer would be to load the archive(s) synchronously.
>

That is a performance killer.

As for references in a different tab, if the separate tab/document did not
> reference the zip archive first, it would operate as normal. It would check
> the cache and then attempt to load. If the zip had been loaded from the
> first page already, the file would be present in the cache, and if not, then
> the browser would attempt to retrieve it from the server.
>

So you get nondeterministic load behaviour anyway. This is not good.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Application deployment

[Dave Singer]

At 19:51  +1200 29/07/08, Robert O'Callahan wrote:
On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer 
<[EMAIL PROTECTED]> wrote:



c) that the contents of the container, once fetched and un-packed, 
logically 'shadow' the directory where the container came from.



It sounds like that affects all loads, which leads to issues:

So if I load 
http://www.example.com/x.m21#y.html and (in the same document, or in 
another tab?) load 
http://www.example.com/z.html, and 
x.m21 contains a z.html but the server also responds to 
http://example.com/z.html, does the 
second load (z.html) come from the server or the container? Does it 
depend on whether the second load starts before the first load 
finishes?


Caching is on a full URL basis, of course.  Once that is decided, 
then yes, I think that pre-cached items for a given URL are in the 
general cache for that site.  If that site doesn't want that effect, 
then don't have z.html inside a ZIP archive in a directory, and a 
different z.html in the directory by itself.


Nor should you refer to z.html as a simple file, outside the archive 
in which it is packaged, unless it is also available separately, 
since there is no assurance that the archive has been fetched and 
pre-cached.


I don't see any of these restrictions as particularly un-obvious or 
unreasonable.






The same questions apply to Russell's proposal.

Rob

--
"He was pierced for our transgressions, he was crushed for our 
iniquities; the punishment that brought us peace was upon him, and 
by his wounds we are healed. We all, like sheep, have gone astray, 
each of us has turned to his own way; and the LORD has laid on him 
the iniquity of us all." [Isaiah 53:5-6]



--
David Singer
Apple/QuickTime

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 2:52 AM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  Archive: is not generic enough but perhaps you could bend the URL
> notation to embrace something like inside:.  I still would not recommend it
> but it would not make me that sore.
>
> How about http://www.site.com/app.jar>?
>
> The user agent would be required to append a query string to local
> hyperlinks and that parameter would be reserved (or rename it to
> h809370dfwhbwa0r92347090).
>
>
That query string would have to be appended everywhere you do baseURI +
relativeURI -> absoluteURI conversion. So you're really just messing with
relative URI syntax for this particular scheme. That's not cleaner than the
URI extension for jar:/archive: (or whatever you want to call it), IMHO.

OTOH, you can simulate several entry points by having all supported entry
> points on the start page (à la Microsoft Access) and have the user navigate
> to what she needs.  I do not think this would be prohibitive from the
> customer's point of view.  And I am sure there is no need to publish each
> local address.
>
That breaks bookmarks and similar navigation mechanisms such as intelligent
URLbar autocompletion. Also note that an entry point can be a particular
document hosted in a Web application, or even a particular email message, so
you can't always offer one-click navigation.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]

[Olli Pettay]

Chapter "5.4.4.3. Events and the Window object" [1] says that event is
also dispatched to window before (and after) dispatching to DOM
nodes. I'd rather say window object is part of the event target chain
(unfortunately load event is a special case), so events automatically 
propagate from document to window. No need to re-dispatch anything.

(This is how gecko works ;) )

Or perhaps that is what the text is trying to say, but it should 
probably talk about event propagation, not about dispatching to window.


-Olli

[1] http://www.whatwg.org/specs/web-apps/current-work/#events0

Web Applications Working Group Issue Tracker wrote:

ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events 
and the Window object? [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/44

Raised by: Ian Hickson
On product: DOM3 Events

We need to decide whether HTML5 or DOM3 Events (or another spec) defines how 
events interact with the Window object that browsers have.

Right now HTML5 says this:
http://www.whatwg.org/specs/web-apps/current-work/#events0
and DOM3 Events says this:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow

Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]

[Kristof Zelechovski]

I am not sure where it is relevant but I remember from learning Borland
Paradox that events are dispatched to window first so that the window can
intercept them universally and then they bubble bottom up if not
intercepted.  This feature is called "global grab" (if the window decides to
handle the event exclusively) or "global filter" (if the event is allowed to
pass to the control).
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Olli Pettay
Sent: Tuesday, July 29, 2008 8:51 PM
To: Web Applications Working Group WG; whatwg List
Subject: Re: [whatwg] ISSUE-44 (EventsAndWindow): Should DOM3 Events cover
the interaction of events and the Window object? [DOM3 Events]

Chapter "5.4.4.3. Events and the Window object" [1] says that event is
also dispatched to window before (and after) dispatching to DOM
nodes. I'd rather say window object is part of the event target chain
(unfortunately load event is a special case), so events automatically 
propagate from document to window. No need to re-dispatch anything.
(This is how gecko works ;) )

Or perhaps that is what the text is trying to say, but it should 
probably talk about event propagation, not about dispatching to window.

-Olli

[1] http://www.whatwg.org/specs/web-apps/current-work/#events0

Web Applications Working Group Issue Tracker wrote:
> ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of
events and the Window object? [DOM3 Events]
> 
> http://www.w3.org/2008/webapps/track/issues/44
> 
> Raised by: Ian Hickson
> On product: DOM3 Events
> 
> We need to decide whether HTML5 or DOM3 Events (or another spec) defines
how events interact with the Window object that browsers have.
> 
> Right now HTML5 says this:
> http://www.whatwg.org/specs/web-apps/current-work/#events0
> and DOM3 Events says this:
>
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event
s-Events-flow
> 
> 
> 
> 
> 

Re: [whatwg] pushState

[Ian Hickson]

On Tue, 29 Jul 2008, Jonas Sicking wrote:
>
> I'll check with the ECMA Script folks, but this one might be an 
> alternative to link to:
> 
> http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
> 
> State that the object passed as 'data' is passed to JSON.parse with the 
> second argument not specified. Any exception thrown is forwarded out to 
> the caller of pushState as usual.

Interesting, thanks. Doesn't really define it clearly though. :-(


> > > When entering a SH state for which a Document has been destroyed, we 
> > > load the URL associated with that SH entry. After the 'load' event 
> > > for the Document has fired, and if a data object was provided in the 
> > > pushState call for the SH entry, we fire a PopStateEvent event 
> > > containing the data stored for the object.
> > 
> > How would this work with bookmarking?
> 
> Just as specified (or at least intended) in the spec right now.
> 
> Say that the user starts on page1.html
> 
>(bookmarks page1.html)
> pushState("title", "data")
>(bookmarks page1.html)
> pushState("title", "data", "page2.html")
>(bookmarks page2.html)
> 
> Additionally, a UA is free to add the ability to store the data 
> parameter in its bookmark storage. For example firefox under some 
> circumstances flags URIs in the bookmark store as POST URIs, i.e. they 
> should be fetched with POST rather than GET (this is specifically for 
> search engine bookmarks). Similarly the data can be stored alongside the 
> URI for the bookmark, however this is optional, just like the fastback 
> cache.

The problem I have with this is that it increases the number of possible 
user-visible behaviours and failure scenarios:

 - same Document, script knows how to handle data.
 - different Document, script knows how to handle data.
 - same URL, different Document, data ignored.
 - different URL, different Document, script knows how to handle data,
   but copying URL fails to work as expected.
 - different URL, different Document, data ignored.

If we want to not allow same-Document entries to share state using actual 
pointers into their state, I'd rather drop the data thing altogether, and 
only use URLs. That way the author doesn't have to worry about having 
multiple ways to carry state data around, and there's a clean way of 
migrating from today's hash-only approach -- keep using the hash.

What I'm suggesting gets rid of the:

   void pushState(in DOMObject data, in DOMString title);

...and makes the only pushState() definition be:

   void pushState(in DOMObject url, in DOMString title);

When the user navigates the session history amongst entries with different 
URLs that happen to have the same Document because they were added with 
pushState(), we fire an event. We drop all the stuff about the "data" 
argument. We make pushState() change the UI and the Location object. (The 
event we fire could be an event that we say always fires just after onload 
as well, so that if a page supports this stuff, it'll always support it 
even when you go straight to that URL.)

This way, bookmarking and copying URLs all works fine.

What do you think?

What do other people think? Is losing the ability to link to JS objects 
within the Document itself a problem?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] window.opener and security

[Ian Hickson]

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
>
> when a new window or tab is opened by a page it normally has a 
> "window.opener" property that points to the window object of the 
> original tab.

Indeed, this is now specced.


> If an origin check fails when comparing the locations of the old window 
> and the popup, the normal cross-domain security policies apply. This 
> means that popup contents from a different site will not be allowed to 
> call methods or manipulate the DOM of the opener.
> 
> However, this cross-domain security policy has one exception: the popup 
> may set the location of its opener. This has phishing potential, 
> particularly for webmail where opening external links in a new window is 
> a very common use case. Hence I think it would be a good idea to let a 
> site opt-out and specify that the popup should not have a window.opener 
> property. For example, one could extend the "features" argument of 
> window.open:
> 
> window.open(url, name, 'openerproperty=0');

Using window.open() for this seems silly, this should just be a link.

I've made rel=noreferrer explicitly not include the opener as well as not 
including the Referer header. Does that address your use case?


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> (An exception is Opera applying a stricter security policy if the
> opener is an https page so in this case popup can't set location of
> its opener, but I'm not sure if the other UAs do this.)

I have not specified this, so this behaviour is currently non-compliant.


On Tue, 20 Mar 2007, Gareth Hay wrote:
> 
> I don't think you need this property, you are free to send null to the 
> child window's opener as things are now, and I would argue for making 
> the property read-only in any future spec anyway, making the UA 
> responsible for security.

Opening a window then poking with it then navigating it seems like a lot 
of effort when all you want to do is have a link open a window without it 
being associated with the opener.


On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> window.opener should be read-only and attempting to write to it should 
> throw an exception.
> 
> This is a similar issue to window.history, in certain browsers you can 
> write to this with js. It has no effect, but does persist across 
> domains. The webkit team decided to just throw an exception if a write 
> to window.history was detected. I don't know if it ever got implemented, 
> or even if any of the other browser vendors addressed it.

window.opener in WebKit seems to be replaceable.


On Tue, 20 Mar 2007, Rimantas Liubertas wrote:
> 
> It was possible to set window.opener in IE, alas, I do not remember
> which version :(
> But it has been fixed, AFAIK.

Not as far as I can tell.


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> I don't really see why setting opener would be dangerous, so I disagree 
> that it should throw.

On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> Well, window.opener is conceptually a link from child to parent. Can you 
> give a valid use-case for adoption of the child to another parent?

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> However, here are two use cases for you:
> 
> 1) I don't want the next page to mess with opener:
> 
> window.opener=null;
> location.href='http://some-untrusted-location/';
> 
> (basically what sites should do today to work around the phishing
> potential issue, but AFAIK none do.)
> 
> 2) I have contents in an IFRAME that I want to talk directly to MY opener:
> 
> document.getElementsByTagName('iframe')[0].contentWindow.opener=self.opener;
> 
> What are your "exploit cases" where setting .opener is so dangerous
> that it should throw? Note that making it throw also means being
> backwards incompatible with
> 
> var opener='Once upon a time, ';
> 
> which might be far-fetched but certainly will exist somewhere if
> browsers haven't thrown exceptions so far.

It's not really about use cases frankly, it's more about what browsers do 
today. Use cases are nice for new features but once pages rely on what 
browsers do, things become pretty immutable.

I've filed a bug to make sure that this is fixed once WebIDL allows us to 
fix it easily. (Right now the spec says the attribute is readonly.)

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=5909


On Tue, 20 Mar 2007, liorean wrote:
> 
> The original problem is that browsers allow cross domain setting of 
> windowobject.location. Whether windowobject in this case comes from 
> window.opener isn't really relevant, except that it provides a method of 
> getting a windowobject reference.
> 
> Hallvord's solution is a workaround - it addresses the ability to get 
> that windowobject reference, even though it doesn't address the core 
> problem. [...]
> 
> A much better solution, in my opinion, would be to make the location 
> object safe from cross domain attacks by making it only writable from 
> same domain, or if the document does not have a domain yet. (window.open 
> without

Re: [whatwg] postMessage: event.source allows navigation of sender

[Ian Hickson]

On Thu, 7 Feb 2008, Hallvord R M Steen wrote:
>
> Adam Barth and Collin Jackson pointed out to me that while investigating 
> frame navigation policies they found that a recipient of a postMessage 
> in Opera can set event.source.location, thus navigate the sender 
> window/document. I think this is a bug in the API itself.
> 
> This seems to violate the API's promise of safe cross-domain 
> communication even with untrusted documents. One can imagine use cases 
> where a script in document A has a reference to window B and thus can 
> post messages, but window B does not have any to A and would not under 
> normal circumstances be able to change A's address.
> 
> I think this should be adressed by removing event.source entirely. It 
> would be weird to disallow setting location on a window object in this 
> context only. To allow posting replies we could instead define a 
> function on the event object. Say for example
> 
> document.addEventListener(  'message', function(e){
> if(e.data=='Hi'){
> e.reply('Hello');
> }
> }, false  )

As far as I know there are no non-symmetric Window visibility cases in 
HTML5. You can only postMessage() to a Window if the Window can see you. 
Is that not true?

Anyway, getting a hold of a Window and setting its window.location.href 
are two different things, as noted below.

The idea is that message channels are the solution around this, by the 
way -- you sent a port to a window you have access to (and that has 
access to you) and if it passes it on to a window you _don't_ have access 
to, it can't navigate you.


On Thu, 7 Feb 2008, Thomas Broyer wrote:
>
> Shouldn't event.source.location be read-only? Isn't that a direct 
> application of the same-origin policy?

Yes and no -- location.href only allows navigation if a separate access 
check passes (not the same-origin check).


Adam explains it well:

On Thu, 7 Feb 2008, Adam Barth wrote:
> 
> When one frame posts a message to another frame, the recipient frame 
> obtains a pointer to the sender frame as the "source" attribute of the 
> message event.  In Opera, this leaks the capability to navigate the 
> sender's frame to the recipient because Opera assumes that if a script 
> has a JavaScript pointer to a frame then that script is permitted to 
> navigate that frame.
> 
> The source attribute of the message event does not leak any privileges 
> to the recipient in Internet Explorer, Firefox, and Safari because these 
> browsers do not make this assumption and instead check whether the 
> script is permitted to navigate the frame when the script assigns 
> window.location.
> 
> In Opera, it is difficult to obtain a JavaScript pointer to a frame 
> because Opera prevents scripts from reading window.frames[i] across 
> domains.  Internet Explorer, Firefox, and Safari all allow scripts to 
> read window.frames[i] across domains.
>
> [...]
> 
> Another way to resolve the issue is for Opera to match the other
> browsers and check whether a script is permitted to navigate a frame
> when that scripts assigns the frame's location.

Right. This is defined here:

   http://www.whatwg.org/specs/web-apps/current-work/#security6
   http://www.whatwg.org/specs/web-apps/current-work/#allowed



On Thu, 7 Feb 2008, Hallvord R M Steen wrote:
> 
> Implementing the ancestore policy takes care of most of the scenarios I 
> can think of where you may want to post messages to a window that should 
> not be allowed to change your location. One case I'm still somewhat 
> concerned about is that one is allowed to set the location of any 
> top-level window according to the ancestor policy, so calling 
> postMessage on untrusted windows from your top window is still somewhat 
> dangerous. That's something we have to allow for web compatibility and 
> for this reason I still think removing event.source from the message 
> event interface would be a good idea.

We can't remove window.source, that's how you talk back. :-)


> For example, consider
> 
> w=window.open();
> w.opener = null;
> w.location = 'http://untrusted.example.org'
> w.postMessage( '...' );
> 
> Untrusted content now gets a window reference it would not otherwise 
> have, and will be allowed to set location if this scripts runs in the 
> top context of the opener.

If the top-level location changes, the location bar will change too, and 
after that the pages can't communication usefully (all you can do is a 
phishing attack, but then the evil page could just as easily just open a 
new window and hope the user doesn't realise there are two windows open, 
it would have the same effect -- or just redirect its own window to the 
phishing window, or whatever).

If this is really a concern, then use the  option. The 
sandboxed navigation browsing context flag will then take care of 
preventing any undue navigation.


On Sat, 9 Feb 2008, Adam Barth wrote:
> 
> One possibility is to prevent one frame from navigating another if the 
> frames are in different units of rel

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

[Øistein E . Andersen]

On 22 May 2008, at 12:40, Ian Hickson wrote:

> would you say that what the spec says now is what browsers 
> implement? What should we change?

The current table seems to cover the mappings between different common
compatible 8-bit encodings as implemented in IE7, yes.  The table at
 gives a bit more detail,
most of which is better kept outside HTML5 itself. However, the following
observations can be made:

1.  Opera, Firefox and Safari all handle US-ASCII as Windows-1252.
IE7, on the other hand, simply ignores the high bit (as it does for
a few other 7-bit encodings, by the way).  Perhaps this
alias could be dropped from the other browsers.

2.  Firefox and Opera seem to sniff for text/plain; charset=ISO-8859-1 (as per 
HTML5),
whereas Safari seems to do the same for text/plain; charset=ISO-8859-11
instead [Version 3.1.2 (5525.20.1)].  Bug?

3.  For certain character sets, different browsers map to different, but 
visually
similar Unicode characters.  Sometimes, one mapping is old/outdated,
but this is not always the case.

4.  Delete (0x7F) and the C1 range (0x80--0x9F) are handled quite 
inconsistently;
different browsers do different things for the same encoding, and the same
browser gives analogous encodings different treatment.

(For the early ISO-8859-* encodings, the IANA registry points to RFC 1345,
which effectively maps 0x7F--0x9F to U+7F--U+9F, but does not really
seem to regard this feature as an essential part of the character set:

the charset is often coded with both
graphical and control character sets.  If the coded character set is
a 96-character set, it is tabled with the relevant GL set (normally
ISO-IR-6) and with ISO 6429 as C0 and C1

As for the Windows-* encodings, Microsoft documentation treats bytes
in this range as unassigned unless they are mapped to graphical characters,
whereas Microsoft products return the underlying byte value in this case.)

5. IE handles KOI8-U as KOI8-RU, whereas Safari does the opposite. The former
is probably more reasonable (assuming that letters are more important than
line-drawing characters), but neither is actually correct given that the 
encodings
are, strictly speaking, incompatible.  This issue will of course look a bit 
different
if it can be shown that documents containing the letter Ў/ў (only in 
KOI8-RU)
are frequently mislabelled as KOI8-U.

> Do you have input on the EUC-JP issue?

Not yet, but you can expect some input on CJK encodings at some point in
the future.

-- 
Øistein E. Andersen

Re: [whatwg] Application deployment

[Russell Leggett]

>
> That is a performance killer.


I don't think it is as much of a performance killer as you say it is.
Correct me if I'm wrong, but the standard connection limit is two. It is not
as though every external file could be loaded at once. Additionally, as I
said, you could split resources into multiple archives to take advantage of
multiple connections, because they can be loaded asynchronously without
issue.  Remember, the use case for this would be when there are likely
dozens of different files that need to be loaded.

So you get nondeterministic load behaviour anyway. This is not good.


This is not so different than directly requesting a file from multiple tabs.
Let's say page 1 and page 2 each use the same image. If I load page 2 first,
it will go directly to the server. If I load page 1 first, page 2 will get
the image from cache.

Clearly, there are other ways of performing this task, but I think this way
is simple and I know that I would gladly accept it as a possibility. It
falls within the same realm that any caching behavior does. It is meant
purely for performance, but if you are relying on it for a given behavior
then you are on a road to trouble.

The archived resources should be static, and also available as individual
files. Pre-fetching them should only be used for performance gains, and if
it would not be performant, it should not be used. However, I think there is
a fairly wide range of sites or applications that could benefit from this
feature. If there are other ways of improving it, or making it work better
for certain edge cases, that would be great, but don't throw the baby out
with the bath water.

Off the top of my head, I can think of a couple of ways to refine the
feature and deal with the issues raised.

   - Only blocking the loading of files that could logically be inside the
   archive: if the archive is located at "/js/resources.zip", then the only
   files that should be blocked would have to be located under "/js".  would not be blocked.
   - To go a step further, there could even be some kind of "pattern"
   attribute that would block the loading of files that matched a url pattern.
   For example, if the archive were located at "/", but had a pattern of
   "**.js,**.css,/images/*", only js, css, and files under the "/images"
   directory would be blocked.


On Tue, Jul 29, 2008 at 2:13 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett <
> [EMAIL PROTECTED]> wrote:
>
>> Yes, the one major hang up that I foresee is how a browser should handle
>> asynchronous loading. How would it know the contents of the archive before
>> it loaded the archive so it did not try to load the same files directly? The
>> simple answer would be to load the archive(s) synchronously.
>>
>
> That is a performance killer.
>
> As for references in a different tab, if the separate tab/document did not
>> reference the zip archive first, it would operate as normal. It would check
>> the cache and then attempt to load. If the zip had been loaded from the
>> first page already, the file would be present in the cache, and if not, then
>> the browser would attempt to retrieve it from the server.
>>
>
> So you get nondeterministic load behaviour anyway. This is not good.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Re: [whatwg] Application deployment

[Dave Singer]

The situation is a lot better for archives (like MPEG-21 files) that 
have a directory at the front...



At 20:10  -0400 29/07/08, Russell Leggett wrote:

That is a performance killer.


I don't think it is as much of a performance killer as you say it 
is. Correct me if I'm wrong, but the standard connection limit is 
two. It is not as though every external file could be loaded at 
once. Additionally, as I said, you could split resources into 
multiple archives to take advantage of multiple connections, because 
they can be loaded asynchronously without issue.  Remember, the use 
case for this would be when there are likely dozens of different 
files that need to be loaded.


So you get nondeterministic load behaviour anyway. This is not good.


This is not so different than directly requesting a file from 
multiple tabs. Let's say page 1 and page 2 each use the same image. 
If I load page 2 first, it will go directly to the server. If I load 
page 1 first, page 2 will get the image from cache.



Clearly, there are other ways of performing this task, but I think 
this way is simple and I know that I would gladly accept it as a 
possibility. It falls within the same realm that any caching 
behavior does. It is meant purely for performance, but if you are 
relying on it for a given behavior then you are on a road to trouble.


The archived resources should be static, and also available as 
individual files. Pre-fetching them should only be used for 
performance gains, and if it would not be performant, it should not 
be used. However, I think there is a fairly wide range of sites or 
applications that could benefit from this feature. If there are 
other ways of improving it, or making it work better for certain 
edge cases, that would be great, but don't throw the baby out with 
the bath water.


Off the top of my head, I can think of a couple of ways to refine 
the feature and deal with the issues raised.


Only blocking the loading of files that could logically be inside 
the archive: if the archive is located at "/js/resources.zip", then 
the only files that should be blocked would have to be located under 
"/js".  would not be blocked.
To go a step further, there could even be some kind of "pattern" 
attribute that would block the loading of files that matched a url 
pattern. For example, if the archive were located at "/", but had a 
pattern of "**.js,**.css,/images/*", only js, css, and files under 
the "/images" directory would be blocked.


On Tue, Jul 29, 2008 at 2:13 PM, Robert O'Callahan 
<[EMAIL PROTECTED]> wrote:


On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett 
<[EMAIL PROTECTED]> wrote:


Yes, the one major hang up that I foresee is how a browser should 
handle asynchronous loading. How would it know the contents of the 
archive before it loaded the archive so it did not try to load the 
same files directly? The simple answer would be to load the 
archive(s) synchronously.



That is a performance killer.

As for references in a different tab, if the separate tab/document 
did not reference the zip archive first, it would operate as normal. 
It would check the cache and then attempt to load. If the zip had 
been loaded from the first page already, the file would be present 
in the cache, and if not, then the browser would attempt to retrieve 
it from the server.



So you get nondeterministic load behaviour anyway. This is not good.

Rob

--
"He was pierced for our transgressions, he was crushed for our 
iniquities; the punishment that brought us peace was upon him, and 
by his wounds we are healed. We all, like sheep, have gone astray, 
each of us has turned to his own way; and the LORD has laid on him 
the iniquity of us all." [Isaiah 53:5-6]



--
David Singer
Apple/QuickTime

Re: [whatwg] HTML5 frame navigation policy

[Ian Hickson]

On Tue, 29 Apr 2008, Adam Barth wrote:
>
> A couple points about Section 4.1.4:
> 
> 1) The spec, as written, prohibits frame-busting.
> 
> Test case: 
> 
> Browser behavior:
> * Internet Explorer 8 beta: Navigation allowed.
> * Firefox 3 nightly: Navigation allowed.
> * Safari 3.1: Navigation allowed.
> * Opera 9: Navigation allowed.
> 
> Frame-busting is used by many sites, including the Yahoo sign-in page. 
> The Yahoo sign-in page uses frame-busting to avoid showing it's trusted 
> sign-in image while being framed by an attacker (who can overlay his own 
> password field on top of Yahoo's).

Defined window.top, and allowed nested browsing contexts to navigate its 
top-level browsing context.


> 2) The spec reads "The browsing context B is an auxiliary browsing 
> context and either its opener browsing context is A or A is allowed to 
> navigate B's opener browsing context."  This is redundant because if B's 
> opener browser context is A, then A is allowed to navigate B's opener 
> browsing context.

Fixed.


> 3) Consider the following set of frames.  A opens X, which opens B.
> Now A attempts to navigate B.
> 
> Test case: 
> 
> 
> Browser behavior:
> * Internet Explorer 8 beta: Navigation allowed (IE does not implement
> an opener restriction).
> * Firefox 3 nightly: Navigation denied.
> * Safari 3.1: Navigation allowed (Safari does not implement an opener
> restriction).
> * Opera 9: Navigation denied.
> 
> The spec allows this navigation because it says "A is allowed to 
> navigate B's opener browsing context."  Now, A is allowed to navigate X 
> (by this rule), which means A is also allowed to navigate B (by a second 
> application of this rule).

The theory being that if X can navigate B (because B is an auxiliary 
context opened by X), then all A has to do is navigate X to something that 
contains code that navigates B, so we might as well allow A to navigate B 
directly.


> I don't have access to the Opera source code, but Firefox's opener 
> restriction computes just one level of recursion.  Note the branch at 
>  
> and that the function passes PR_FALSE for the parameter aConsiderOpener 
> when it calls itself recursively.

The above logic can be extrapolated to any number of levels, so I don't 
see any reason to limit it to one level of recursion.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] require img dimensions to be correct?

[Ian Hickson]

On Tue, 20 Mar 2007, ddailey wrote:
>
> I sometimes enjoy the ability to clone images that have no src or no 
> width or no style. I certainly like to vary the height and width 
> attributes via setAttribute, and I might like, in the future, to be able 
> to attach an  tag (ala SMIL) to the height or width attribute 
> of an . If I had to do this through CSS, it would be a minor 
> setback.
> 
> 
> repeatCount="indefinite">
> 

Seems like CSS is the better place for this kind of thing.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] require img dimensions to be correct?

[Ian Hickson]

On Wed, 21 Mar 2007, Henri Sivonen wrote:
> On Mar 3, 2007, at 21:58, Ian Hickson wrote:
> 
> > The question isn't whether or not you should have the ability to scale 
> > images; it's clear that this is desirable. The question is whether it 
> > makes sense to put this in HTML as opposed to CSS. Why would HTML be 
> > the place to put this?
> 
> Because the dimensions vary from image to image, putting the dimensions 
> in an external style sheet would mean moving the dimensions even further 
> away from the images they pertain to. Generic reusable styles make sense 
> in an external sheet. ID selectors specific to particular image files 
> don't. OTOH, moving the dimensions from attributes to style='' or 
> 

Re: [whatwg] several messages

[Ian Hickson]

On Tue, 20 Mar 2007, Nicholas Shanks wrote:
> 
> I asked for the resurrection of HTML+'s fallback element 
> last month. The reasons I cited were exactly the same as the reasons 
> being given now in favour of the  element, however I was told 
> (paraphrasing) "Why bother, you can just use " and "That would 
> break existing implementations" (though no such implementations were 
> cited).
>
> So again, I ask for an  element to replace . Benefits include:
> - As  would cater for video/* MIME types,  would cater for
> image/*

I don't see how this is a benefit over .


> - The alt and longdesc attributes can be part of the fallback content,
> allowing markup.

If you need markup in the fallback, use . (Or, better, consider 
exposing the content to everyone and not making it only available to those 
who don't see the image.)


> - You don't have to provide a type attribute and match on: object
> [type^="image/"]

Seems like "img" handles this too.


On Wed, 21 Mar 2007, Nicholas Shanks wrote:
> On 21 Mar 2007, at 00:27, Simon Pieters wrote:
> > 
> > The  start tag is parsed as if it were , so you would get 
> > both the image and the fallback with HTML+ markup. Existing content 
> > rely on this behaviour, which is why it was added to the Parsing spec 
> > (see "A start tag whose tag name is "image"", and see comment in 
> > source).
> 
> So what's the problem?
>
> Content with a doctype of  or  is 
> treated correctly, and content without a doctype is handled in quirks 
> mode, where the UA can look for  and if found in a suitable 
> place, treat the start tag as , or if not found, treat the start 
> tag as . Any content using  in strict mode with another HTML 
> doctype is broken anyway, so it doesn't really matter how that looks.

We're not doing any DOCTYPE-based parsing differences unless we 
_absolutely_ have to. This kind of switch is a giant source of 
implementation bugs and authoring problems.


On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote:
> 
> Or, how about getting more specific?
> 
>  [e.g. image/gif of an icon]
>  [e.g. image/svg of a map]
>  [e.g. image/jpeg of a cat]
> 
> Would that help search engines, I wonder?

I don't see why it would (who would be making sure the right one was used 
each time?).

This really doesn't seem to solve a real problem.


On Wed, 21 Mar 2007, Anne van Kesteren wrote:
> 
> > I guess we have to agree to disagree here, but I think
> > Download Foo 1.4(12  > title="Megabytes">MB)
> > is preferable to
> > 
> > which it would appear you prefer.
> 
> Yeah. An abbreviation such as MB should be known by an accessibility 
> client anyway and I think it's also perfectly capable of dealing with a 
> few parenthesis. Besides, the latter has been standard practice for over 
> a decade and trying to change authoring habbits with respect to that now 
> seems silly. Besides, you can use  if you really care about 
> "proper" fallback.

In any case, what's the image in the case above? Why would you ever want 
that text _not_ visible when the image was visible?
   
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Content-Type sniffing: image

[Ian Hickson]

On Thu, 26 Apr 2007, Anne van Kesteren wrote:
>
> This section has the following line: "User agents must ignore any rows 
> for image types that they do not support." In my mind, this is in direct 
> conflict with the warning above that says it's imperative for user 
> agents to follow the same set of rules for security reasons.

Fair enough, changed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] as thumbnails

[Ian Hickson]

On Wed, 30 May 2007, ddailey wrote:
>
> This makes good sense to me. Under US case law stemming from Kelly v 
> Arriba, the thumbnail has a rather special legal status 
> (http://srufaculty.sru.edu/david.dailey/copyright/legalthumb.htm ).* I 
> believe similar discussions have taken within WIPO (and certainly did 
> under CONFU), such that that status may have burbled outward (of the US) 
> a bit.
> 
> The use case in which the thumbnail appears at a different site than the 
> thing from which it is derived is therefore highly likely, at least in 
> the US (or in places that have access to TCP/IP). If my memory is 
> correct, it was shortly after the initial decision in Kelly that Google 
> began an "image search" capability quite reminiscent of what 
> Ditto/Arriba had been doing. The case law would appear to require proper 
> citation to be provided so providing a standard typographic mechnism for 
> doing that seems worthwhile.
> 
> David (IANAL)
> 
> *The situation was muddied a bit by a recent injunction against Google, 
> http://news.com.com/2100-1030_3-6041724.html -- but upon appeal Google's 
> use was upheld 
> http://seattlepi.nwsource.com/business/316013_amazongoogle17.html .

I haven't added this, because frankly I haven't heard any requests for 
this that weren't hypothetical (like the above). In particular, Google 
Image search, cited above, hasn't asked me for anything like this.

Note that we have  now, and may in time add  to  
to handle this in a more visible way.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] element comments

[Ian Hickson]

On Sat, 13 Oct 2007, Henri Sivonen wrote:
> On Oct 13, 2007, at 01:55, Ian Hickson wrote:
> > On Tue, 7 Nov 2006, Henri Sivonen wrote:
> > > So I think width and height should not have conformance requirements 
> > > tied to pixel dimensions of the references image file. They are 
> > > presentational, but they are such a useful presentational 
> > > optimization that I think it doesn't make sense to try the get rid 
> > > of that presentationalism just to comply with a principle.
> > 
> > Is the compromise in the spec today acceptable?
> 
> I don't think "If both attributes are specified, then the ratio of the 
> specified width to the specified height must be the same as the ratio of 
> the logical width to the logical height in the image file." solves any 
> real problem given what browsers already have to implement, so I'd 
> remove that sentence.

It solves the problem of authors not being informed when they give the 
wrong dimensions by mistake and end up screwing up the ratio.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] element comments

[Ian Hickson]

On Sun, 14 Oct 2007, Matthew Paul Thomas wrote:
> On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote:
> >
> > I don't think "If both attributes are specified, then the ratio of the 
> > specified width to the specified height must be the same as the ratio 
> > of the logical width to the logical height in the image file." solves 
> > any real problem given what browsers already have to implement, so I'd 
> > remove that sentence.
> 
> As a real-world example, Launchpad currently stretches the width of 
> static images to produce simple bar charts of how much particular 
> software packages have been localized. 
> 
> 
> We have to specify both width= and height= for the images, because 
> specifying width= alone causes w3m to stretch the images vertically to 
> maintain their aspect ratio. Meanwhile, elsewhere we're using , 
> so we should really be declaring our pages to be HTML 5 site-wide.
> 
> The sentence Henri quoted would require us to choose between server-side 
> generation of every chart image, incompatibility with w3m, or 
> non-conformance with any HTML specification. I know w3m isn't exactly a 
> major browser, but I don't see any good reason for having to make that 
> choice.

As far as I'm aware, the behaviour you describe for w3m matches what all 
the UAs do.

I'm not sure that this usage of  is one that the spec today considers 
valid. Wouldn't  be the better way to do this?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] The truth about Nokias claims

[Ian Hickson]

On Fri, 14 Dec 2007, Christoph P�per wrote:
> 
> PS: What format for animated truecolor (alpha-channeled) bitmap images 
> should HTML5 recommend ('should') or require ('must')? ;)

Are there any formats worth talking about other than APNG here? Do we need 
to explicitly talk about APNG here? Seems like we can just leave this one 
undefined, and let the issue resolve itself, as has been done for all 
other  formats so far.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Application deployment

[Robert O'Callahan]

On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer <[EMAIL PROTECTED]> wrote:

> Caching is on a full URL basis, of course.  Once that is decided, then yes,
> I think that pre-cached items for a given URL are in the general cache for
> that site.
>

A site that uses this feature is likely to be fragile. It will have to have
z.html both in the archive and available directly from the server, in case
z.html is requested before the load of the archive has finished. And if
those copies ever get out of sync you're in very big trouble, because
depending on the context, either the archive version or the direct version
is likely to consistently win the load race, so just occasionally some
clients will get the wrong version. This seems like a highly error-prone
design.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

[whatwg] HTML 5 : Misconceptions Documented

[Garrett Smith]

I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of "programming by coincidence."
These reflect very poorly on html5.

The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default

Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the "elements" HTMLCollection an "array"

(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.

(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named "watch". It is a bad practice and I see this influence in the
popular libraries.

(3) There is no specification for a special [[Get]] for the "elements"
HTMLCollection as a shortcut to "namedItem", either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call "push" et c directly on that NodeList object (see the
"dojo.NodeList" for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.

// WRONG
document.forms[0].qty,

The "elements" property is what the example should use:-

// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get

This avoids ambiguity when having a form that has an element named "name",
for example. It becomes ambiguous as to whether the "form.name" refers to
the element or the form's "name" attribute. Problems could also arise with
"action", "length", "toString", "elements".

-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {

// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
  if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
  } else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
  }
}

And further down:-

// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;

if (myControl.value == '[EMAIL PROTECTED]') {
  myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:

var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;

  if (qv.valueMissing) {
// Value required but not filled in.
  } else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
  }
}

var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
  addr.setCustomValidity(addErrInvalidMsg);
}

[whatwg] Fake Code

[Garrett Smith]

Examples should work.

Citation from:
http://www.whatwg.org/specs/web-apps/current-work/#outlines


The following JavaScript function shows how the tree walk could be
implemented. The root argument is the root of the tree to walk, and
the enter and exit arguments are callbacks that are called with the
nodes as they are entered and exited. [ECMA262]

function (root, enter, exit) {
  var node = root;
  start: do while (node) {
enter(node);
if (node.firstChild) {
  node = node.firstChild;
  continue start;
}
while (node) {
  exit(node);
  if (node.nextSibling) {
node = node.nextSibling;
continue start;
  }
  if (node == root)
node = null;
  else
node = node.parentNode;
}
  }
}


This code cannot be interpreted in a compliant implementation of
EcmaScript. It has more syntax errors than I can count. It is unclear
what the author thinks this code will do. If its intent were clearer,
and the syntax errors fewer, it might be possible for me to help out
by fixing them. The above code is not even close to ECMA262.

Examples should not contain errors.

Garrett