Re: [whatwg]

[Maciej Stachowiak]

On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote:



I don't really prefer one to the other, just considering the  
possibilities we have at hand.


My current thinking is that you can go one of 2 ways.

#1: Pack everything into in  element.  (I.e., what you were  
suggesting.) Or...
#2: Expand everything into its own  element.  (I.e., what I  
was suggesting.)


My thinking is that... we're now considering adding width and height  
info (via one or two new attributes)... but I could see this  
progressing to adding other new attributes too (... perhaps in  
HTML5... or perhaps in version of HTML after that).


For example... if we have width and height now... well why not info  
about the number of bits used for the colors?!  Why not info about  
if the coloring is palleted or not?!  Or if the image format uses  
lossless compression or lossy compression?!  Or the size of the  
file?!  Etc


In practice, these things usually do not matter when using an icon in  
the user interface. But the sizes available do matter. I would not  
want to download a 512x512 icon for use as an iPhone homescreen icon  
(it's not anywhere near the right size) but it is irrelevant whether  
the compression is lossy or how colors are represented. I would prefer  
a multisize icon with a wide size range for Mac OS X or Windows Vista  
but not for Windows XP or most mobile platforms.





If we have this new attribute(s) available on the  element,  
then it is very likely going to be used for other things besides  
just icons.


You could use width and height for videos too.  What if video wants  
to be able to "declare" that the video has "closed captioning"  
embedded or not?!  Or what language the video file has audio for?!   
("hreflang" would almost work for that... if it let you specify more  
than one language.)  Or`what "ratings" that version of the video is?!



What I was getting at with this suggestion is that if we start  
adding the ability to specify all sorts of metadata about what's  
being linked to and go along the path of #1, then we likely need to  
create a kind of complex language to describe this.  (Something  
approaching the complexity of CSS.)  And perhaps that's complicating  
the  element too much.


Maybe it's simpler to (do #2 and) just create a  for each thing.


I'm not sure I understand this. Your proposal amounts to adding two  
new attributes to the  element, "width" and "height" (and  
possibly specifying a link of the same type to the same item multiple  
times). My proposal involves a single new attribute on , with  
essentially the same information conveyed in a more compact way. Why  
does my proposal lead to a CSS-like general-purpose metadata language,  
but yours does not?


Regards,
Maciej

Re: [whatwg]

[Charles Iliya Krempeaux]

Hello,

On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote:
>

[...]


>
> In practice, these things usually do not matter when using an icon in the
> user interface. But the sizes available do matter. I would not want to
> download a 512x512 icon for use as an iPhone homescreen icon (it's not
> anywhere near the right size) but it is irrelevant whether the compression
> is lossy or how colors are represented. I would prefer a multisize icon with
> a wide size range for Mac OS X or Windows Vista but not for Windows XP or
> most mobile platforms.



True... for an iPhone that might be the case.  Or even Mac OS X or Windows
Vista.  But it might become important in usages of this metadata beyond just
icons.

For example, consider a photo blogging example...









(The bottom  if the original image.  The 2 640x480 onews are scaled
version... one color and one grayscale.  And the top one is a thumbnail.)



>
>
> >
> > If we have this new attribute(s) available on the  element, then
> > it is very likely going to be used for other things besides just icons.
> >
> > You could use width and height for videos too.  What if video wants to
> > be able to "declare" that the video has "closed captioning" embedded or
> > not?!  Or what language the video file has audio for?!  ("hreflang" would
> > almost work for that... if it let you specify more than one language.)
> >  Or`what "ratings" that version of the video is?!
> >
> >
> > What I was getting at with this suggestion is that if we start adding
> > the ability to specify all sorts of metadata about what's being linked to
> > and go along the path of #1, then we likely need to create a kind of complex
> > language to describe this.  (Something approaching the complexity of CSS.)
> >  And perhaps that's complicating the  element too much.
> >
> > Maybe it's simpler to (do #2 and) just create a  for each thing.
> >
>
> I'm not sure I understand this. Your proposal amounts to adding two new
> attributes to the  element, "width" and "height" (and possibly
> specifying a link of the same type to the same item multiple times). My
> proposal involves a single new attribute on , with essentially the
> same information conveyed in a more compact way. Why does my proposal lead
> to a CSS-like general-purpose metadata language, but yours does not?
>

It leads to a CSS-like language only if we start adding more metadata in
there besides just the width and height.

For example, this...





... could become...



The "metadata" attribute is where you start to get a CSS-like language.
(Which seems to complicate the  element.)


See ya

-- 
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/

Vlog Razor... Vlogging News... http://vlograzor.com/

[whatwg] Focus, html vs body and the activeElement property

[Hans S . Tømmerholt]

Hello.

I'm reading this part:
http://www.whatwg.org/specs/web-apps/current-work/#focus

The intro states:
"When an element is focused, key events received by the document must be
targeted at that element. There is always an element focused; in the
absence of other elements being focused, the document's root element is
it."

Under "Focus management", I read:

"The activeElement attribute must return the element in the document that
has focus. If no element specifically has focus, this must return the body
element."

First: Isn't this a contradiction? The first paragraph states that there
is always an element focused. The second gives a case where this is not so.

Second: I presume the document's root is defined as html, but the
activeElement returns the body element. Why?

This seems to refer to the same issue:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012654.html
Searching through the archive I can't find a response, for example in  
Ian's "several messages" posts.


The spec also mentions "system focus" and seems to imply that this is
different from the focus of elements. But the term is not particularly
defined. I'm guessing this means that this is the page the user is
currently looking at, i.e. that the window containing the document has
focus? But then this line is confusing:

"The hasFocus attribute must return true if the document, one of its
nested browsing contexts, or any element in the document or its browsing
contexts currently has the system focus."

This seems to imply that an element inside a document can have system
focus. What does this mean?

--
Vennlig hilsen/best regards
Hans S. Tømmerholt
Developer, Web Applications, Opera Software ASA

Re: [whatwg]

[Maciej Stachowiak]

On Apr 30, 2008, at 12:41 AM, Charles Iliya Krempeaux wrote:


Hello,

On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote:

[...]


In practice, these things usually do not matter when using an icon  
in the user interface. But the sizes available do matter. I would  
not want to download a 512x512 icon for use as an iPhone homescreen  
icon (it's not anywhere near the right size) but it is irrelevant  
whether the compression is lossy or how colors are represented. I  
would prefer a multisize icon with a wide size range for Mac OS X or  
Windows Vista but not for Windows XP or most mobile platforms.



True... for an iPhone that might be the case.  Or even Mac OS X or  
Windows Vista.  But it might become important in usages of this  
metadata beyond just icons.


For example, consider a photo blogging example...

compressioning="lossless" coloring="paletted" href="A.png">


compressioning="lossless" coloring="truecolor" href="B.png">
compressioning="lossless" coloring="grayscale" href="C.png">


compressioning="lossy" coloring="truecolor" href="D.jpg">



(The bottom  if the original image.  The 2 640x480 onews are  
scaled version... one color and one grayscale.  And the top one is a  
thumbnail.)


Has anyone actually asked for this kind of functionality or is this a  
hypothetical use case? I don't think we should tie solving a real  
problem (the need to specify icons at different sizes and let the UA  
know these sizes) to an open-ended metadata annotation mechanism.


If we have this new attribute(s) available on the  element,  
then it is very likely going to be used for other things besides  
just icons.


You could use width and height for videos too.  What if video wants  
to be able to "declare" that the video has "closed captioning"  
embedded or not?!  Or what language the video file has audio for?!   
("hreflang" would almost work for that... if it let you specify more  
than one language.)  Or`what "ratings" that version of the video is?!



What I was getting at with this suggestion is that if we start  
adding the ability to specify all sorts of metadata about what's  
being linked to and go along the path of #1, then we likely need to  
create a kind of complex language to describe this.  (Something  
approaching the complexity of CSS.)  And perhaps that's complicating  
the  element too much.


Maybe it's simpler to (do #2 and) just create a  for each thing.

I'm not sure I understand this. Your proposal amounts to adding two  
new attributes to the  element, "width" and "height" (and  
possibly specifying a link of the same type to the same item  
multiple times). My proposal involves a single new attribute on  
, with essentially the same information conveyed in a more  
compact way. Why does my proposal lead to a CSS-like general-purpose  
metadata language, but yours does not?


It leads to a CSS-like language only if we start adding more  
metadata in there besides just the width and height.


For example, this...

compressioning="lossy" coloring="truecolor" href="A.xxx">
compressioning="lossy" coloring="truecolor" href="A.xxx">
compressioning="lossy" coloring="truecolor" href="A.xxx">


... could become...

href="A.xxx">


The "metadata" attribute is where you start to get a CSS-like  
language.  (Which seems to complicate the  element.)


I'm not in favor of a CSS-like metadata language or a metadata  
attribute. I don't think your suggested extra attributes are very  
useful either so I am not sure how it is relevant to discuss different  
syntax alternatives for them. That being said, this:





Does not introduce a CSS-like metadata language any more than your  
first alternative. So I still do not see your point.


Regards,
Maciej

Re: [whatwg]

[timeless]

On Wed, Apr 30, 2008 at 8:33 AM, Michael(tm) Smith <[EMAIL PROTECTED]> wrote:
>  I notice the docs for the "icons" param of the Gears createShortcut()
>  method describe four discrete sizes that all have the same height
>  and width ("An object containing one or more of these named
>  properties: 128x128, 48x48, 32x32, 16x16...").
>
>  So do UAs expect [EMAIL PROTECTED] icons to always have the same
>  height and width, and if so should the HTML5 spec make it clear
>  that their height and width should be the same?

i have an icons collection from when microb team did favicon work and
i distinctly recall one of the icons as being non square :)

http://www.linuxworld.com/favicon.ico

a quick recheck shows it's the only one. it's 50x51, which always
struck me as odd.

Re: [whatwg]

[Michael(tm) Smith]

timeless <[EMAIL PROTECTED]>, 2008-04-30 12:08 +0300:

> On Wed, Apr 30, 2008 at 8:33 AM, Michael(tm) Smith <[EMAIL PROTECTED]> wrote:
> >  So do UAs expect [EMAIL PROTECTED] icons to always have the same
> >  height and width, and if so should the HTML5 spec make it clear
> >  that their height and width should be the same?
> 
> i have an icons collection from when microb team did favicon work and
> i distinctly recall one of the icons as being non square :)
> 
> http://www.linuxworld.com/favicon.ico
> 
> a quick recheck shows it's the only one. it's 50x51, which always
> struck me as odd.

I'd suppose along with that and Maciej's example of the iPhone
59x60 icons, there are probably a few other examples and that
non-square icons are maybe not so uncommon after all.

Anyway, I guess I don't understand what the current (or expected)
behavior is for handling the general case of multiple
[EMAIL PROTECTED] instances within the same document, when the icons
can be of any arbitrary size (whether or not the size is given
explicitly as is being proposed).

I can understand the specific case like that of building a Gears
application and including link markup to provide a set of icons in
the particular dimensions that conform to the Gears Desktop API.

But especially if we were to add some means for dimensional markup
to link (height/width attribute, sizes attribute, or whatever),
and we want UAs to interoperably handle the case of multiple icons
of various sizes being present, I'd wonder if the spec should
describe what the behavior is meant to be.

In fact, since it's already possible to have multiple link icon
instances in arbitrary sizes (just without the sizes being given
explicitly in the markup), it seems like regardless of whether
some new means for dimensional markup does end up being added,
the expected behavior for the case of multiple link icons is
already something that the spec maybe should try to address (that
is, along with the case it already addresses of multiple instances
with different media attributes).

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/


smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg]

[Lachlan Hunt]

Charles Iliya Krempeaux wrote:





... could become...




For color, you are reinventing Media Queries. For compression, you are 
basically reinventing q values for MIME types.






--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg]

[Martin Atkins]

Ian Hickson wrote:

(With my rarely-used Google hat on:)

The Gears team has an API that allows authors to specify a set of icons:

   http://code.google.com/apis/gears/upcoming/api_desktop.html

They used a scripted API, but when I tried to get them to use a 
declarative API, they said that the main reason they used a scripted one 
is that the declarative options didn't have a way to specify dimensions.


This is a proposal to add "height" and "width" attributes to  
specifically for the case of rel=icon, so that authors can provide 
multiple icons and let the UA decide which to use based on their size 
(without having to download them all to find out which is best).


Opinions?



I recall that another group[1] in a similar situation were considering 
something like the following:




Presumably the above would be more the bailiwick of the MIME standard 
than the HTML standard, but this seems cleaner to me than adding some 
special-case attributes to the html LINK element.



[1] Sadly, I cannot remember which group it was at the moment.

Re: [whatwg]

[Martin Atkins]

Lachlan Hunt wrote:

Charles Iliya Krempeaux wrote:





... could become...




For color, you are reinventing Media Queries. For compression, you are 
basically reinventing q values for MIME types.








Could this be said about size as well?



Here I'm assuming that "the rendering surface of the output device" as 
referred to by Media Queries[1] section 5.1 is the rectangle of pixels 
that the icon is going to be rendered within, which I suppose is a 
slight deviation from the meaning when rel="stylesheet", but I find it 
to be intuitive.


[1] http://www.w3.org/TR/2007/CR-css3-mediaqueries-20070606

Re: [whatwg]

[Křištof Želechovski]

I am agaist using compound attributes like this; make it 16×16 if you
insist.
Best regards,
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
Sent: Wednesday, April 30, 2008 7:13 AM
To: Ian Hickson
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] 




Regards,
Maciej

[whatwg] scrollIntoView jarring?

[David Bolter]

I have a concern about "3.5.3 Scrolling elements into view":  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrollintoview


In addition to concerns expressed by Brad Fults 
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012655.html), 
I want to raise a concern about the behaviour of scrollIntoView. 
Specifically I would ask that:


1. scrollIntoView not do anything in the case that the element is 
already fully visible (possibly in the middle of the viewport), or
2. ensureElementIsVisible to be added as described by Daniel Glazman 
(http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)


My concern is that with the movement towards rich interactive web 
interfaces, we are going to be seeing complex widgets that will need to 
call such functions fairly often, which may lead to a jarring experience 
if the function always butts the element to the edge of the viewport. It 
would be a shame to jar users when unnecessary. I realize there is a 
(hairy) way to do this but it would be nice to have the convenience.


Aside: we would like to recommend authors call such a method when using 
ARIA's activedescendant (draft spec).


cheers,
David

Re: [whatwg]

[Brady Eidson]

Following this thread, I just decided to throw this out there to see  
if I'm way off base or not...


Since this is obviously a topic that has sparked a tad of passionate  
interest and there's not necessarily a clear solution that doesn't  
make  ugly, what are people's thoughts on adding a new  element  
for icon badging, one that would only be valid within the ?


~Brady

Re: [whatwg]

[Aaron Boodman]

On Wed, Apr 30, 2008 at 11:32 AM, Brady Eidson <[EMAIL PROTECTED]> wrote:
> Since this is obviously a topic that has sparked a tad of passionate
> interest and there's not necessarily a clear solution that doesn't make
>  ugly, what are people's thoughts on adding a new  element for icon
> badging, one that would only be valid within the ?

That would work for us, too.

- a

[whatwg] The origin of pages on the local file system

[Jeff Walden]

It was brought up during the latest postMessage patching in Mozilla that the 
HTML5-mandated origin for file: URIs groups all local file system pages into a single 
origin.  Pages are increasingly being used in application-like contexts, and if Java is 
any example, grouping all files into the same origin will eventually be problematic (if 
one even chooses to argue it isn't now).  (Firefox 3's postMessage will be intentionally 
non-conforming with respect to file: pages in that sending a message to a file: page will 
only work if you use "*" as the targetOrigin, in the interests of not having 
different security behaviors.)

Firefox 3 changes from an all-files-are-same-origin model to a contains-based model, 
roughly this in at least some cases: a file may load any file which is a sibling of 
it, and it may load any file which is a descendant of the file's parent directory.  
I'm certain I'm horribly mangling what actually happens in practice in at least some 
situations, based on what I've read of the security comparison functions, but this is 
at least a start at describing the behavior for specification.  The original bug was 
, but follow dependencies 
and read comments to see what sort of issues were actually encountered in practice 
and couldn't be ignored without breaking wide swathes of content.

Jeff

--
Life would be so much easier if humans had a natural affinity for remembering 
128-bit integers.

Re: [whatwg] scrollIntoView jarring?

[Peter Kasting]

On Wed, Apr 30, 2008 at 10:58 AM, David Bolter <[EMAIL PROTECTED]>
wrote:

> Specifically I would ask that:
>
> 1. scrollIntoView not do anything in the case that the element is already
> fully visible (possibly in the middle of the viewport), or
> 2. ensureElementIsVisible to be added as described by Daniel Glazman (
> http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)


I agree that this is a use case which scrollIntoView does not seem to solve
well.  I am not sure Daniel's proposal for ensureElementIsVisible is perfect
either, though it is clearly better.

I make no formal proposal, but the behavior I would typically want for some
kind of a call (perhaps in addition to those above, I don't know) would be:

   - If the element in question cannot be scrolled so as to make more of it
   appear in the viewport, do nothing.  (For when the element is completely
   visible, or is larger than the viewport and already taking up the whole
   viewport).
   - Otherwise, if the element is not larger than the viewport, scroll such
   that the element is centered* in the viewport (within the scrolling limits
   -- if the element is at the bottom of the page, it clearly can't be scrolled
   up to the middle of the viewport).
   - Otherwise, scroll the element such that the top of the element is
   aligned with the top of the viewport.

*Perhaps centered is the wrong choice.  Another suggestion would be to
scroll to a point 1/3 of the way from the top or bottom of the viewport,
nearer to whichever edge the element scrolled in from.  Also, perhaps the
UA's behavior should not be specified in this kind of detail?

PK

Re: [whatwg]

[Bonner, Matt (IPG)]

Brady Eidson wrote:

> what are people's thoughts on adding a new element for icon
> badging, one that would only be valid within the ?

Funny I wrote just that same question to the editor an hour ago.

Since someone else brought it up, now I'm just "adding to the
thought." :-)

The idea of an  tag that forks from  strikes me as 
analagous to the  tag forking from . Both new
tags seem to come from the need to have attributes more specific
to their contents than makes sense to load on the general tag.

Obviously, this brings "tag bloat" and yet more work for user
agent authors, so we'd want to hear from them...  But a separate
icon tag would permit unconstrained design of its attributes and
preserve the generality of .

best regards,
Matt
--
Matt Bonner
Hewlett-Packard Company

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson
Sent: Wednesday, April 30, 2008 11:32 AM
To: WHATWG Mailing List
Cc: Ian Hickson
Subject: Re: [whatwg] 

Following this thread, I just decided to throw this out there to see
if I'm way off base or not...

Since this is obviously a topic that has sparked a tad of passionate
interest and there's not necessarily a clear solution that doesn't
make  ugly, what are people's thoughts on adding a new  element
for icon badging, one that would only be valid within the ?

~Brady


smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg]

[Lachlan Hunt]

Martin Atkins wrote:

Lachlan Hunt wrote:
For color, you are reinventing Media Queries. For compression, you are 
basically reinventing q values for MIME types.






Could this be said about size as well?




No, because the media queries are related to the actual tech specs of 
the device, not the image.  I'm fairly sure there are no 16x16px screens 
in use, at least not for the web.  To get appropriate behaviour for what 
you're suggesting here would require redefining and special casing media 
queries.



--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] scrollIntoView jarring?

[David Bolter]

Peter Kasting wrote:
On Wed, Apr 30, 2008 at 10:58 AM, David Bolter 
<[EMAIL PROTECTED] > wrote:


Specifically I would ask that:

1. scrollIntoView not do anything in the case that the element is
already fully visible (possibly in the middle of the viewport), or
2. ensureElementIsVisible to be added as described by Daniel
Glazman
(http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)


I agree that this is a use case which scrollIntoView does not seem to 
solve well.  I am not sure Daniel's proposal for 
ensureElementIsVisible is perfect either, though it is clearly better.


I make no formal proposal, but the behavior I would typically want for 
some kind of a call (perhaps in addition to those above, I don't know) 
would be:


* If the element in question cannot be scrolled so as to make more
  of it appear in the viewport, do nothing.  (For when the element
  is completely visible, or is larger than the viewport and
  already taking up the whole viewport).
* Otherwise, if the element is not larger than the viewport,
  scroll such that the element is centered* in the viewport
  (within the scrolling limits -- if the element is at the bottom
  of the page, it clearly can't be scrolled up to the middle of
  the viewport).
* Otherwise, scroll the element such that the top of the element
  is aligned with the top of the viewport.

*Perhaps centered is the wrong choice.  Another suggestion would be to 
scroll to a point 1/3 of the way from the top or bottom of the 
viewport, nearer to whichever edge the element scrolled in from. 
 Also, perhaps the UA's behavior should not be specified in this kind 
of detail?


Peter,

Nice. I agree on all points, except maybe if larger than the viewport we 
might want to butt an element corner to a viewport corner (perhaps 
top-left for left-to-right languages), but I also wonder if that is too 
much detail.


cheers,
David

Re: [whatwg] The origin of pages on the local file system

[Ian Hickson]

On Wed, 30 Apr 2008, Jeff Walden wrote:
>
> It was brought up during the latest postMessage patching in Mozilla that 
> the HTML5-mandated origin for file: URIs groups all local file system 
> pages into a single origin.  Pages are increasingly being used in 
> application-like contexts, and if Java is any example, grouping all 
> files into the same origin will eventually be problematic (if one even 
> chooses to argue it isn't now). (Firefox 3's postMessage will be 
> intentionally non-conforming with respect to file: pages in that sending 
> a message to a file: page will only work if you use "*" as the 
> targetOrigin, in the interests of not having different security 
> behaviors.)
> 
> Firefox 3 changes from an all-files-are-same-origin model to a 
> contains-based model, roughly this in at least some cases: a file may 
> load any file which is a sibling of it, and it may load any file which 
> is a descendant of the file's parent directory.  I'm certain I'm 
> horribly mangling what actually happens in practice in at least some 
> situations, based on what I've read of the security comparison 
> functions, but this is at least a start at describing the behavior for 
> specification.  The original bug was 
> , but follow 
> dependencies and read comments to see what sort of issues were actually 
> encountered in practice and couldn't be ignored without breaking wide 
> swathes of content.

I've changed the spec to allow arbitrary behaviour for file://.

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

Re: [whatwg] Origin feedback

[Jonas Sicking]

On Thu, 24 Jan 2008, Adam Barth wrote:
The security origin of frames that begin life with the URL "about:blank" 
or "" differs in different browsers.  In Firefox and the trunk revision 
of WebKit, the principal for the frame is aliased to the principal of 
the frame's parent (or opener, if it is a top-level frame).  In IE7, the 
frame appears to copy the principal.


http://crypto.stanford.edu/~abarth/research/html5/empty-frame/

The frame's window.location.href property matches the parent/opener in 
Firefox, IE, and Safari:


http://crypto.stanford.edu/~abarth/research/html5/empty-frame/href.html


The aliasing behaviour seems really dodgy. I've specced the copying 
behaviour, which also matches Opera.


The reason you want to use aliasing is in a situation like this (file 
loaded from www.example.com) :



  
  
  
onload = function() {
  document.domain = "example.com";
  document.getElementById('f').contentDocument.write("hello world");
}
  
  


the document.domain call changes the outer documents principal. If there 
was no aliasing then the .write call would result in a security 
exception stating that content from "example.com" doesn't have access to 
"www.example.com".


Similarly (file loaded from www.example.com) :


  
  
onload = function() {
  xhr = new XMLHttpRequest();
  xhr.open("GET", "http://www.example.com/data.xml";, false);
  xhr.send(null);
  doc = xhr.responseXML;
  doc.documentElement;
  document.domain = "example.com";
  doc.documentElement;
}
  
  


Without the XHR document "aliasing" the principal of the main document, 
the first doc.documentElement call will succeed, but the second with 
throw a security error.


/ Jonas

Re: [whatwg]

[Ernest Cline]

-Original Message-
>From: Ian Hickson <[EMAIL PROTECTED]>
>Sent: Apr 29, 2008 9:52 PM
>To: [EMAIL PROTECTED]
>Subject: [whatwg] 
>
>
>(With my rarely-used Google hat on:)
>
>The Gears team has an API that allows authors to specify a set of icons:
>
>   http://code.google.com/apis/gears/upcoming/api_desktop.html
>
>They used a scripted API, but when I tried to get them to use a 
>declarative API, they said that the main reason they used a scripted one 
>is that the declarative options didn't have a way to specify dimensions.
>
>This is a proposal to add "height" and "width" attributes to  
>specifically for the case of rel=icon, so that authors can provide 
>multiple icons and let the UA decide which to use based on their size 
>(without having to download them all to find out which is best).
>
>Opinions?

Maybe I'm missing something obvious, but why wouldn't:

serve to mark width and height adequately?

It's even perfectly fine HTML 4 syntax.

Ernest Cline

Re: [whatwg]

[Maciej Stachowiak]

On Apr 30, 2008, at 11:32 AM, Brady Eidson wrote:

Following this thread, I just decided to throw this out there to see  
if I'm way off base or not...


Since this is obviously a topic that has sparked a tad of passionate  
interest and there's not necessarily a clear solution that doesn't  
make  ugly, what are people's thoughts on adding a new   
element for icon badging, one that would only be valid within the  
?


That would solve the use case, but since  is already  
defined, it seems more elegant to extend it with the needed information.


Regards,
Maciej

Re: [whatwg] scrollIntoView jarring?

[L. David Baron]

On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote:
> 1. scrollIntoView not do anything in the case that the element is already 
> fully visible (possibly in the middle of the viewport), or
> 2. ensureElementIsVisible to be added as described by Daniel Glazman 
> (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)

It seems like authors might actually want different options here for
different uses.  Aligning things with an edge of the viewport, or
with the edge of some other scrollable container, might be useful in
some cases, and just ensuring that it is visible might be useful in
others.

Mozilla has an internal function used to implement a number of
different scrolling APIs (including scrolling to named anchors) that
has a bunch of options:
 * scroll into view (no matter where)
 * scroll to align with a particular edge of the page
 * scroll only if it's not visible at all

I think in many cases these scrolling APIs are about making things
that authors can already do (using scrollTop, offsetTop,
offsetHeight, offsetParent, and similar properties) easier to do.
So I think the main questions to consider for these APIs are:

 * what capabilities do they provide that can't already be done?

 * what are the common uses of the existing features for scrolling
   things into view (perhaps adjusted by how hard it is to do the
   different possibilities)?

(It's also worth thinking about how all of these deal with nested
scrollable containers, and about how they deal with the interaction
of vertical and horizontal scrolling.  The existing text in
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrolling
doesn't seem to account for either.  But browsers actually do need
to handle these, and the spec should describe how.)

-David

-- 
L. David Baron http://dbaron.org/
Mozilla Corporation   http://www.mozilla.com/

Re: [whatwg] Origin feedback

[Ian Hickson]

On Wed, 30 Apr 2008, Jonas Sicking wrote:
> >
> > The aliasing behaviour seems really dodgy. I've specced the copying 
> > behaviour, which also matches Opera.
> 
> The reason you want to use aliasing is in a situation like this (file 
> loaded from www.example.com) :
> 
> 
>   
>   
>   
> onload = function() {
>   document.domain = "example.com";
>   document.getElementById('f').contentDocument.write("hello world");
> }
>   
>   
> 
> 
> the document.domain call changes the outer documents principal. If there 
> was no aliasing then the .write call would result in a security 
> exception stating that content from "example.com" doesn't have access to 
> "www.example.com".

Yes, you want a security exception there. That's what IE does, in fact. 
(Opera too.)


> Similarly (file loaded from www.example.com) :
> 
> 
>   
>   
> onload = function() {
>   xhr = new XMLHttpRequest();
>   xhr.open("GET", "http://www.example.com/data.xml";, false);
>   xhr.send(null);
>   doc = xhr.responseXML;
>   doc.documentElement;
>   document.domain = "example.com";
>   doc.documentElement;
> }
>   
>   
> 
> 
> Without the XHR document "aliasing" the principal of the main document, 
> the first doc.documentElement call will succeed, but the second with 
> throw a security error.

Agreed. I've made XHR documents track the origin of the document of the 
window that the XHR object was from, and made document.domain throw when 
called on such documents.

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

Re: [whatwg]

[Bjoern Hoehrmann]

* Lachlan Hunt wrote:
>Martin Atkins wrote:
>> Lachlan Hunt wrote:
>>> For color, you are reinventing Media Queries. For compression, you are 
>>> basically reinventing q values for MIME types.
>>>
>>> 
>>> 

You are using HTTP accept-parameters in a context where a media type
with optional parameters is expected; in other words, this is non-
compliant at the moment since there is no 'q' parameter for the type.

>> Could this be said about size as well?
>> 
>> >   media="all and (max-width:16px and max-height:16px)">
>
>No, because the media queries are related to the actual tech specs of 
>the device, not the image.  I'm fairly sure there are no 16x16px screens 
>in use, at least not for the web.  To get appropriate behaviour for what 
>you're suggesting here would require redefining and special casing media 
>queries.

If you read the definition of the media atteribute, you'll find that it
has a dual nature, specifically, it can describe "for which media the
document in question was designed". While this is not currently the case
for 'icon', it could easily be made so, and if, the above would mean the
icon was designed for a viewport or page box of at most 16x16px. If the
icon is rendered into a 16x16px viewport, well, I'd find that fitting.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] Origin feedback

[Jonas Sicking]

Ian Hickson wrote:

On Wed, 30 Apr 2008, Jonas Sicking wrote:
The aliasing behaviour seems really dodgy. I've specced the copying 
behaviour, which also matches Opera.
The reason you want to use aliasing is in a situation like this (file 
loaded from www.example.com) :



  
  
  
onload = function() {
  document.domain = "example.com";
  document.getElementById('f').contentDocument.write("hello world");
}
  
  


the document.domain call changes the outer documents principal. If there 
was no aliasing then the .write call would result in a security 
exception stating that content from "example.com" doesn't have access to 
"www.example.com".


Yes, you want a security exception there. That's what IE does, in fact. 
(Opera too.)


Why do you want that? That seems very counter intuitive to me (though 
unfortunately lots of document.domain behavior is).


/ Jonas

[whatwg] Any easy whatwg tutorial?

[[EMAIL PROTECTED]]

Hi all.

Could anyone illuminate me as to whether
there is any simple practicum on whatwg?

I mean, like in the old html days, is there
any really idiot proof (me) way to learn what
you all are doing? Other than the FAQ, etc
on your site?

Any books on the horizon, or already around?
thanks a lot.

dan

Re: [whatwg] scrollIntoView jarring?

[Jonas Sicking]

L. David Baron wrote:

On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote:
1. scrollIntoView not do anything in the case that the element is already 
fully visible (possibly in the middle of the viewport), or
2. ensureElementIsVisible to be added as described by Daniel Glazman 
(http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)


It seems like authors might actually want different options here for
different uses.  Aligning things with an edge of the viewport, or
with the edge of some other scrollable container, might be useful in
some cases, and just ensuring that it is visible might be useful in
others.

Mozilla has an internal function used to implement a number of
different scrolling APIs (including scrolling to named anchors) that
has a bunch of options:
 * scroll into view (no matter where)
 * scroll to align with a particular edge of the page
 * scroll only if it's not visible at all

I think in many cases these scrolling APIs are about making things
that authors can already do (using scrollTop, offsetTop,
offsetHeight, offsetParent, and similar properties) easier to do.
So I think the main questions to consider for these APIs are:

 * what capabilities do they provide that can't already be done?

 * what are the common uses of the existing features for scrolling
   things into view (perhaps adjusted by how hard it is to do the
   different possibilities)?



Another question is if the scrolling should be instant, or if smooth 
scrolling is allowed/desired.


/ Jonas

Re: [whatwg] scrollIntoView jarring?

[Garrett Smith]

On Wed, Apr 30, 2008 at 2:21 PM, L. David Baron <[EMAIL PROTECTED]> wrote:
> On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote:
>  > 1. scrollIntoView not do anything in the case that the element is already
>  > fully visible (possibly in the middle of the viewport), or
>  > 2. ensureElementIsVisible to be added as described by Daniel Glazman
>  > (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)
>
>  It seems like authors might actually want different options here for
>  different uses.  Aligning things with an edge of the viewport, or
>  with the edge of some other scrollable container, might be useful in
>  some cases, and just ensuring that it is visible might be useful in
>  others.
>
>  Mozilla has an internal function used to implement a number of
>  different scrolling APIs (including scrolling to named anchors) that
>  has a bunch of options:
>   * scroll into view (no matter where)
>   * scroll to align with a particular edge of the page
>   * scroll only if it's not visible at all
>
>  I think in many cases these scrolling APIs are about making things
>  that authors can already do (using scrollTop, offsetTop,
>  offsetHeight, offsetParent, and similar properties) easier to do.
>  So I think the main questions to consider for these APIs are:
>

The function can become considerably difficult with nested, scrolled containers.

>   * what capabilities do they provide that can't already be done?
>
>   * what are the common uses of the existing features for scrolling
>things into view (perhaps adjusted by how hard it is to do the
>different possibilities)?
>

There are three cases:
1) want to make sure the element is within viewable area
 a) partially
 b) completely
2) want to make sure element is is completely viewable
 a) at top of screen
 b) with least amount of scrolling

I have never been asked to scroll an element so that it is in the
middle of the screen. If the element were larger than the screen, that
would seem to be a bad U/X.

>  (It's also worth thinking about how all of these deal with nested
>  scrollable containers, and about how they deal with the interaction
>  of vertical and horizontal scrolling.  The existing text in
>  
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrolling
>  doesn't seem to account for either.  But browsers actually do need
>  to handle these, and the spec should describe how.)

Browsers nested, scrolled elements inconsistently with each other.

Having scrollIntoView([top]) will scroll a nested element into view.
It seems to have the effect of passing [top] up the tree, recursively.





scrollIntoView





blah blah balh
blah blah balh
blah blah balh
blah blah balh
blah blah balh

yea



var a = document.getElementById("a");

scrollIntoView(false)
scrollIntoView(true)



Firefox seems to have an internal check for isElementInView, because
calling scrollIntoView(false) after scrollIntoView(true) does nothing.
e.g. "scroll only if it's not visible at all"

This is probably due to the common problem I see:
1) IE has a sort-of useful property that works as desired in some
cases (main path-OK)
2) Mozilla copies it in a little different way (alternate path different)

This is a process issue. It is not confined to scrollIntoView. There
should be a test case for  [insert_feature_here], to demonstrate the
current behavior + any new desired behavior.

SOmeone could even faux-implement it by writing
HTMLElement.prototype.ensureElementIsViewable = function([whatever]) {
};

(ensureElementIsVisible is not a good name because 'visible' means
something specifically different in the context of dynamic browser
scripting.)

Other things like scroll speed would seem to be enhancements that
could be considered later.

-G

>
>  -David

Re: [whatwg] scrollIntoView jarring?

[Neil Deakin]

Firefox seems to have an internal check for isElementInView, because
calling scrollIntoView(false) after scrollIntoView(true) does nothing.
e.g. "scroll only if it's not visible at all"

  

Firefox 2 uses:

scrollIntoView(true)
 scroll the element and its containers vertically such that the element 
is aligned along the top edge

scrollIntoView(false)
 scroll the element and its containers vertically such that the element 
is fully visible, if possible. If it is already fully visible, don't 
scroll at all. This is like an ensureElementIsVisible type function.


Horizontally, the ensureElementIsVisible behaviour is always used.

Firefox 3 changed the vertical behaviour to be compatible with IE, 
although I personally think the Firefox 2 behaviour is more useful.

Re: [whatwg] Any easy whatwg tutorial?

[Ian Hickson]

On Wed, 30 Apr 2008, [EMAIL PROTECTED] wrote:
> 
> Could anyone illuminate me as to whether there is any simple practicum 
> on whatwg?
> 
> I mean, like in the old html days, is there any really idiot proof (me) 
> way to learn what you all are doing? Other than the FAQ, etc on your 
> site?
> 
> Any books on the horizon, or already around? thanks a lot.

http://www.whatwg.org/ lists all the available resources we have.

There have been some presentations, which might help:

   http://wiki.whatwg.org/wiki/HTML5_Presentations

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

Re: [whatwg] Any easy whatwg tutorial?

[ddailey]

There is also Anne Van Kesteren's "HTML 5 Differences from HTML 4" at 
http://www.w3.org/html/wg/html5/diff/ . It is probably mentioned from 
somewhere within the site Hixie mentions, but provides a quick glance at 
some of the major differences between the old and the emerging standards. 
The WhatWG and the W3C HTMLWG have largely overlapping concerns, and the 
editor's draft (I think it is safe to claim) represents at least a major 
part of the intersection of those concerns.


David

- Original Message - 
From: "Ian Hickson" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, April 30, 2008 7:35 PM
Subject: Re: [whatwg] Any easy whatwg tutorial?



On Wed, 30 Apr 2008, [EMAIL PROTECTED] wrote:


Could anyone illuminate me as to whether there is any simple practicum
on whatwg?

I mean, like in the old html days, is there any really idiot proof (me)
way to learn what you all are doing? Other than the FAQ, etc on your
site?

Any books on the horizon, or already around? thanks a lot.


http://www.whatwg.org/ lists all the available resources we have.

There have been some presentations, which might help:

  http://wiki.whatwg.org/wiki/HTML5_Presentations

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