[whatwg] fullscreen event?
Hello, I was thinking, maybe a fullscreen (and a normalscreen event or something like that) event would be useful? Also, a fullScreen property (which returns true or false) on the window would in that case be handy. Afaik, Mozilla already has such a property, only it doesn't work (it's always false, iirc). Regards, Martijn
Re: [whatwg] fullscreen event?
On 5/6/06, Dean Edwards <[EMAIL PROTECTED]> wrote: Martijn wrote: > I was thinking, maybe a fullscreen (and a normalscreen event or > something like that) event would be useful? > Also, a fullScreen property (which returns true or false) on the > window would in that case be handy. What do you have in mind? I know that the browser's chrome disappears but otherwise how is this different from a normal resize event? Hmm, yes, I guess it's not really that much different from a resize event. So, indeed a fullscreen event is probably not that useful. But I think a way of detecting when the browser is in fullscreen mode would be useful. Regards, Martijn -dean
Re: [whatwg] fullscreen event?
On 5/6/06, Dean Edwards <[EMAIL PROTECTED]> wrote: I'm not really against the idea but Ian likes use cases. ;-) Well, I guess the fullscreen option is used for presentations. So I guess you would want to change the layout of a page, or the behavior, for example. I see that Opera already has a css way of doing this with the @media projection rule. So that's not a very strong use case, I guess. Regards, Martijn -dean
Re: [whatwg] Canvas and DOM elements
On 5/5/06, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote: Having dedicated DOM element () for drawings looks a bit strange as a design decision. Logically any block DOM element can provide graphics. Ideally getContext method should have one more parameter - layer - background/content/foreground - so graphics could be mixed with the content of the element, drawn on top and/or below the content. Yeah, I think you make a good point here. Regards, Martijn Only as an example, Sciter allows to draw on any block element: http://terrainformatica.com/sciter/sciter.zip at http://terrainformatica.com/sciter/ Samples are in /samples/graphics/*.htm Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] fullscreen event?
On 5/11/06, Dean Edwards <[EMAIL PROTECTED]> wrote: On 11/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > My suggestion would be to have a renderingMode event (or something > like that) which in some way exposes a mediaList of the current > rendering modes (mostly just one). If you go to print preview mode for > example the event is dispatched and the mediaList contains 'print'. If > you go to projection mode it contains 'print' etc. > Sounds good to me. :-) Yeah, sounds good to me, too. I also would like to know which rendering mode the window is in, at a particular time, I guess a getRenderingMode methode or something. Wouldn't the onbeforeprint/onafterprint event handlers also fit in here, somehow? Something like onbeforerenderingmodechange/onafterrenderingmodechange? Regards, Martijn -dean
[whatwg] input type="country"?
There are times I have to select in which country I live in. Wouldn't a input type="country" widget be useful here? I couldn't find one on the web forms 2.0 spec, but something in that line is already there, then I'm sorry, and you can ignore this mail. Regards, Martijn
Re: [whatwg] input type="country"?
On 8/23/06, Arve Bersvendsen <[EMAIL PROTECTED]> wrote: On Wed, 23 Aug 2006 15:44:37 +0200, Martijn <[EMAIL PROTECTED]> wrote: > There are times I have to select in which country I live in. > Wouldn't a input type="country" widget be useful here? > I couldn't find one on the web forms 2.0 spec, but something in that > line is already there, then I'm sorry, and you can ignore this mail. Which countries we have in the world, and how they are named is a rather volatile property. Countries change name depending on the current rule(r), and as not-too-distant European history taught us, countries break up. The definition of what is a country varies depending on who you ask, so such a form control is hard to accomplish. Well, the browser should be able to keep up with the current list of countries, shouldn't it? It's not like it is something that is changing every minute. I'm sure there is an official list out there (United Nations?), with all the countries in the world. Regards, Martijn Arve Bersvendsen
Re: [whatwg] input type="country"?
On 8/23/06, David Håsäther <[EMAIL PROTECTED]> wrote: > Well, the browser should be able to keep up with the current list of > countries, shouldn't it? It's not like it is something that is > changing every minute. But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? That could happen nowadays also, that a country isn't listed in the select control. Indeed, I would think that the browser would keep up with a list of available countries. Regards, Martijn -- David Håsäther
Re: [whatwg] input type="country"?
On 8/23/06, James Graham <[EMAIL PROTECTED]> wrote:
Lachlan Hunt wrote:
> David Håsäther wrote:
>> But what if you use a browser with an old list, and your contry isn't
>> listed. Or are you proposing that browsers download a list every time?
>
> Many modern browsers already periodically check for updates. Such lists
> could be downloaded like any other update, as required.
But it seems like a rather onerous requirement to have in the spec for what
would be a very minor feature. Also, having an application that may display and
be expected to process different countries depending on the particular revision
of the particular browser being used seems like a poor idea from both a UI and
back-end point of view.
It's not something that would happen very often, and I don't think I
would encounter that problem at all.
The UI I get nowadays is already poor (webpages with a very long list
of countries in a select box), I would hope that a browser UI for
input type="country" would be better.
How useful would this type of control actually be? How often do people really
need to list every country in the world? The control would have no semantic
value beyond a since many more-specific country lists ("all the
countries in Europe", "all the countries we sell to") would still be implemented
as s.
It's not used as often as the request for an email or name for
example, but it is asked pretty often, I think.
Regards,
Martijn
--
"Eternity's a terrible thought. I mean, where's it all going to end?"
-- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] input type="country"?
On 8/23/06, David Håsäther <[EMAIL PROTECTED]> wrote: Yes, this is why it's probably not a good idea to use a select list for contries, since there is a possibility that your country is not on the list. You can have a select list and an input control at the same time, not? Regards, Martijn -- David Håsäther
Re: [whatwg] input type="country"?
On 8/23/06, Stewart Brodie <[EMAIL PROTECTED]> wrote: > > But what if you use a browser with an old list, and your contry isn't > > listed. Or are you proposing that browsers download a list every time? > > That could happen nowadays also, that a country isn't listed in the select > control. Indeed, I would think that the browser would keep up with a list > of available countries. Who would look after this list? The U.N.? Not all countries in the world are members of the U.N. In which languages will this list be maintained? What am I supposed to do if I'm not on an Internet-connected node? I would think the list is in the same language as the browser. I don't see a reason why you should be connected to the internet to be able to show the input type="country" widget (although for submitting forms it is often necessary). Yes, I know there are political problems, with a list of countries, so there is an issue there. Regards, Martijn This sort of 'official list of all possible answers' thing is already a very real problem for interacting with websites of less enlightened companies and organisations (primarily in the United States, but I've found a few in other countries as well, though). I'm asked to choose a country from the supplied list, but even though I've selected 'United Kingdom', the form still refuses to submit because it requires me to say which of the 50 U.S. states I'm in! -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] Persistent storage is critically flawed.
On 8/28/06, Jim Ley <[EMAIL PROTECTED]> wrote: On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote: > I accept tracking is inevitable but we > shouldn't be making it easier either. You have to remember that the WHAT-WG individual is a Google employee, a company that now relies on accurate tracking of details, so don't be surprised that any proposal makes tracking easier and harder to circumvent. Well, if the WHAT-WG individual wasn't a Google employee, but an employee from Microsoft or Mozilla or Opera or any random government, would that change the above text? I don't think so. So I don't think that text is implying much, otherwise than there aren't very much 'neutral' organizations involved in writing specifications for the web. It's probably a design requirement, of course like all WHAT-WG stuff, there is no explanation of the problems that are attempting to be solved with any of the stuff, so it's impossible to really know. From: http://www.whatwg.org/specs/web-apps/current-work/#introduction2 " The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time. Cookies don't really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing. " and: " The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the clientside for performance reasons. Again, cookies do not handle this case well, because they are transmitted with every request. " That seem to me two use cases of problems that are attempting to be solved, not? Regards, Martijn Jim.
Re: [whatwg] element?
On 12/15/06, Dean Edwards <[EMAIL PROTECTED]> wrote: Thoughts? In Mozilla's xbl the attribute inheritstyle="false" is used for that. Maybe an attribute would be more appropriate? I like the idea, because I have this problem also, once in a while. But how would you be able to style the elements in the widget? I guess you need to be able to insert a specific stylesheet for the widget itself. Regards, Martijn -dean -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg]
2007/2/20, Anne van Kesteren <[EMAIL PROTECTED]>: I think the parsing algorithm should take the prompt="" attribute of in account. It replaces the string of characters placed before the element with its contents. (In that case there will be no characters after the element.) Also, there is an action attribute, so I think it would be wise to include that one too, I don't think I see it mentioned at: http://www.whatwg.org/specs/web-apps/current-work/#isindex This: http://google.com";> alert(document.forms[0].action); alerts 'http://google.com' in IE7. Regards, Martijn
[whatwg]
Submission of an element is different compared to normal form submission with a text input element, only the value part is submitted. This parsing definition: http://www.whatwg.org/specs/web-apps/current-work/#isindex means that also should only submit the value part. And indeed, that is what IE7 seems to be doing. Mozilla even has a bug filed for this: https://bugzilla.mozilla.org/show_bug.cgi?id=93795 So I guess this needs to be mentioned somewhere in the web forms spec or something? Regards, Martijn
Re: [whatwg]
2007/2/21, David Latapie <[EMAIL PROTECTED]>: I never understood what is done for. Is it some kind of precursor of Google Sitemaps? http://en.wikipedia.org/wiki/HTML_element " … (deprecated) The :isindex element requires server side support for indexing documents. Visually presents a one-line text input for keyword entry. When submitted, the query string is appended to the current URL and the document is displayed with these keywords highlighted. Generally if the server supports this feature it will add the iisindex elements to documents without author intervention. " More info here: http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/isindex.html http://www.blooberry.com/indexdot/html/tagpages/i/isindex.htm Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/15, Magnus Kristiansen <[EMAIL PROTECTED]>: On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <[EMAIL PROTECTED]> wrote: > I'm not so sure it is a workaround though. > If you know that the event will bubble, you can make your handler > prevent bubbling. > > I don't think we should be adding two new events to a spec, when the > existing events can work in the way you want, albeit with a line more > code. If we did, we'd be forever adding very specialized events. You don't seem to understand the situation. Imagine there's a parent element and several child elements. Every time you mouse over a child element, a mouseover event triggers (and mouseout on the previous element). This event bubbles up until it reaches the parent element. An event handler on the parent can only prevent the events from bubbling event further (which is not relevant), not from reaching itself. To prevent it using bubble cancelling you would have to attach events stopping bubbling to every child element of the target. Not only is this an unreliable way of doing it, it also interferes with potential other elements which actually want bubbling. The other, more practical workaround is to look at each incoming event and check "did this one come bubbling up, or does it belong here". However, workarounds do not solve the problem itself. With mouseenter/leave, there is no bubbling. There is no need to attach handlers to arbitrary elements, and no need to manually check each incoming event to see if it's bubbling or direct. These events are linked to a significant enough use case. They are no more redundant than existing events like click (mousedown+mouseup) and keypress (keydown+keyup). Yeah, I sort of half remembered a situation where I really had a need for mousenter/mouseleave. I got in a similar situation as you describe. I too think mouseenter/mouseleave events would be a useful addition. Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay <[EMAIL PROTECTED]>: Well, the current W3C spec has relatedTarget specifically for these use cases, so again I fail to see why adding convenient shorthand for functionality is a good thing here. If we try to cover everyone's use cases with easy functionality, the spec is going to be huge with lots of overlapping functions and elements. To me this is simply a programming problem, which is easily solved to the use cases suggested, and also the inverse of actually wanting the bubble. Well, there more examples like that that, which are very successful, like .innerHTML. Regards, Martijn Gareth On 16 Mar 2007, at 03:41, Benjamin West wrote: > This is a pretty well known issue, and a constant stumbling block. > There are use cases for using the capture/bubble stuff[1]. However, > by far, the most common need is for simple one-off's, and the bubbling > really gets in the way. The issue is explained quite well on PPK's > site: > <http://www.quirksmode.org/js/events_order.html> > <http://www.quirksmode.org/js/events_mouse.html> <-- covers mouseenter > and mouseleave and why it's better (because it explains how tedious > the traditional model is first.) > > The bottom line is that introducing mouseenter and mouseleave will > reduce a lot of CPU cycles, and make authoring a lot easier. > > [1] http://decafbad.com/blog/2006/10/31/event-delegation-based- > dhtml-drag-and-drop > http://icant.co.uk/sandbox/eventdelegation/ > > -Ben -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay <[EMAIL PROTECTED]>: Is one of the objectives here not to repeat the same mistakes as in the past? What do you mean? Which mistakes? Regards, Martijn
Re: [whatwg] window.opener and security
2007/3/20, Hallvord R M Steen <[EMAIL PROTECTED]>:
On 20/03/07, timeless <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> >
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
> I believe you'll find that Gmail does not have this problem, because
> when it uses window.open, it opens a gmail page which then triggers a
> server side redirect, and that destroys the window.opener link.
This is incorrect. window.opener survives the redirect and still
points to the opener window.
javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))
I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.
Regards,
Martijn
[whatwg] Negative tabindex
According to: http://www.whatwg.org/specs/web-apps/current-work/#negative-tabindex " A negative integer specifies that the element should be removed from the tab order. If the element does normally take focus, it may still be focused using other means (e.g. it could be focused by a click). " That appears not to be true in IE7, see: click me This triggers the alert in IE7. So it seems to me the " If the element does normally take focus," should be removed. Regards, Martijn -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg] Infinite loopcount for audio and video
The marquee element uses the loop attribute: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/loop_1.asp where -1 means that it loops infinitely. Personally, I prefer that one the most. Regards, Martijn 2007/4/23, Stefan Haustein <[EMAIL PROTECTED]>: Hi, I think in loopcount="forever" the units do not match (no unit / time). I would prefer "Infinity" because it is a valid ECMAScript literal (=1/0). "Indefinite" (=0/0 ?) looks really strange... Best regards, Stefan Kristof Zelechovski wrote: > loopcount="forever"? It looks better than "Inf". > loopcount="-1"? Is a number, + a static constant for LOOPCOUNT_FOREVER in > the DOM. > Not that I consider the exact wording very important anyway. > Chris > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ddailey > Sent: Monday, April 23, 2007 9:33 PM > To: Elliotte Harold; WHAT WG List > Subject: Re: [whatwg] Infinite loopcount for audio and video > > Makes sense to me. If such a thing is not already spoken for why not aim > toward a little consistency with pre-existing implementations, like in SVG, > where it would be repeatCount="indefinite"? > > Not my favorite piece of nomenclature ever, but it's out there and has a > user-base already. > > David > - Original Message - > From: "Elliotte Harold" <[EMAIL PROTECTED]> > To: "WHAT WG List" <[EMAIL PROTECTED]> > Sent: Monday, April 23, 2007 3:20 PM > Subject: [whatwg] Infinite loopcount for audio and video > > > >> Is there a way to specify continuous looping for audio and video elements? >> > > >> e.g. something like >> >> > autoplay="autoplay" loopcount="Inf" /> >> >> If not, should there be? >> >> -- >> Elliotte Rusty Harold [EMAIL PROTECTED] >> Java I/O 2nd Edition Just Published! >> http://www.cafeaulait.org/books/javaio2/ >> http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ >> >> >> > > > -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg] Dashed strokes on
2007/5/17, Ian Hickson <[EMAIL PROTECTED]>: On Wed, 16 May 2007, David Flanagan wrote: > I believe that most of these issues can and should be left to the > implementation. If the implementation is allowed to choose whether or > not to draw shadows, then I think it is fine to allow the implementation > to choose the minor details of dash rendering. Whether to support something is different from how to support it. How to render shadows is defined. How to render dashes should also be defined. Is how to render shadows defined here? http://www.whatwg.org/specs/web-apps/current-work/#shadows0 So with that piece of text it is clear how to render shadows in canvas? Regards, Martijn
Re: [whatwg] fullscreen event?
2006/5/8, Arve Bersvendsen <[EMAIL PROTECTED]>: Opera applies stylesheets with 'media="projection"' when it goes in to fullscreen (projection) mode, so in one sense the resulting document is different. On the other hand, detecting this on resize is fairly trivially acheived by checking the style of some reference element. So 'media="projection"' == fullscreen mode? I also noticed there is no fullScreen property to detect whether the window is in full screen mode. Regards, Martijn
