Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 1:50 PM, Tim Streater t...@clothears.org.uk wrote: On 24 Jun 2015 at 20:15, Peter Kasting pkast...@google.com wrote: 1.66 = 1.0.0.66 1.256 = 1.0.1.0 1.2.66 = 1.2.0.66 1.256.66 = invalid This makes no sense at all. https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02#section-2.1.1 explains why Quoth the text Meanwhile, a very popular implementation of IP networking went off in its own direction. 4.2BSD introduced a function inet_aton(), whose job was to interpret character strings as IP addresses. It interpreted both of the syntaxes mentioned in [MTP] (see above): a single number giving the entire 32-bit address, and dot-separated octet values. It also interpreted two intermediate syntaxes: octet- dot-octet-dot-16bits, intended for class B addresses, and octet- dot-24bits, intended for class A addresses. It also allowed some flexibility in how the individual numeric parts were specified: it allowed octal and hexadecimal in addition to decimal, distinguishing these radices by using the C language syntax involving a prefix 0 or 0x, and allowed the numbers to be arbitrarily long. The 4.2BSD inet_aton() has been widely copied and imitated, and so is a de facto standard for the textual representation of IPv4 addresses. Nevertheless, these alternative syntaxes have now fallen out of use (if they ever had significant use). The only practical use that they now see is for deliberate obfuscation of addresses: giving an IPv4 address as a single 32-bit decimal number is favoured among people wishing to conceal the true location that is encoded in a URL. All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable.
[whatwg] Examples where HTML5 is not multicore-ready
Hi everyone, I would like this thread to be a collection of parallel algorithms that should run faster as the number of cores increase, but in HTML5 (using Web Workers) will actually run slower as the number of cores increase. If there are significant and substantial examples of parallel algorithms that actually run slower on more expensive multi-core machines, this would be an embarrassing result that should be addressed sooner rather than later. I am mostly interested in realworld examples, but some synthetic examples could also be interesting. Realworld example #1: Sorting an array of large objects by a key that is contained within the objects. Realworld example #2: Particle systems. To understand why this is a good example, read: http://software.intel.com/sites/billboard/archive/ticker-tape.php Particle systems are often used in games and other graphics applications. (If anyone wants to run benchmarks, here is a starting point: http://www.ryanheise.com/html5/particles.html) Realworld example #3: http://www.picnet.com.au/blogs/Guido/post/2010/02/18/Html-Web-Worker-Woes-Data-Analysis-not-an-Option.aspx Guido provides an interesting example that is not game related, and also provides a synthetic demonstration. Realworld example #4: Game artificial intelligence that needs to analyse large data structures. Synthetic example #1: for (var i = 0; i 1; i++) array[i] = i; Synthetic example #2 Guido's example from above. (Although many realworld examples also follow this pattern) For anyone who would like to contribute to these examples, here is how to go about finding similar examples: The kinds of examples that are likely to slow down rather than speed up as more cores are added are those with a high memory access to cpu usage ratio. Of these, there are two kinds: 1. Those that require heavy write access. 2. Those that mainly rely on readonly access. Sorting and particle systems are both examples of the first kind, and can potentially have a high memory access to cpu usage ratio. An example of the second kind is a game artifical intelligence which needs to analyse the entire game state without necessarily changing it. (Beware: although the AI will not modify this memory, this is not readonly memory. Being game state, it will surely be updated by the physics engine.) This thread is a follow-up to a recent thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027229.html -- Ryan Heise
Re: [whatwg] Web Workers
Drew Wilson wrote: Rather than trying to shoehorn concurrent functionality into Javascript (where many implementations don't support multi-threaded access down at the VM level anyway, so the obstacles to implementation seem fairly large) it seems like a better option is to use a different language entirely. While I would ideally prefer to develop web games in any language of my choosing, this seems to be the worse option in practice. It is important to consider that many developers and browser vendors see value in adopting standards. Javascript currently is that standard, and is the only web programming language supported by IPhone, Android and Desktop browsers. It would seem a worthwhile pursuit to improve the standard in spite of any technical obstacles, not only because engineers love technical obstacles, but also because part of the technical obstacle is to rework the DOM to be threadsafe. The DOM, if my understanding is correct, is not part of the Javascript implentation itself, and so any other scripting language that we hope to use in place of Javascript will also limit us in terms of its threading capabilities and interaction with the DOM until the DOM is made threadsafe. There is currently no way for a program to find out how many cores are present in the host system. Not sure if any conclusions were drawn - I think we may have kept this open as an option for v2 of the spec. Thanks, that is good news to hear. Boris Zbarsky wrote: On 7/21/10 4:11 PM, Ryan Heise wrote: Note that things might have been different had Javascript been a purely functional language. If this were the case, then there would be much safer and more efficient alternatives to making whole copies of data that could be implemented under the hood. Why does this require JS to be purely functional? There's already work happening in this direction, though obviously arbitrary object graphs are hard due to the mutability. If we eliminate mutability (e.g. sealing the objects in the relevant graph), then the memory could in fact be shared instead of copied, right? Yes, but this is not the whole story. Before I go on, let me quickly suggest something that may help with functional-style VM optimisations in the future, if there is a decision to pursue this. C# has the ability to distinguish between structs which represent values, and classes which represent references. If Javascript introduced similar syntax, then the problem of dealing with arbitrary object graphs could be made easier. Along similar lines, other syntax can also be added to the language to declare certain objects as immutable, and certain functions as being bing pure (lacking side effects). This can be used by the VM to do various functional-style optimisations in addition to sharing read-only memory. But in relation to the main point, the whole story is that these data heavy algorithms very rarely have merely readonly requirements on memory, UNLESS you go to the extreme and support functional-style programming in its entirety. Take, for example, a sorting algorithm. In the imperative style of programming, any implementation, even parrallel, will need to not only do many read operations, but also many write operations. It is not unless you completely rework your code into a purely functional style that it will be possible to implement a sorting algorithm using immutable data structures, and the efficiency will be terrible unless the VM also does heavy optimisations in light of the functional style of programming being used. Even still, it is well known that as far as sorting algorithms and other algorithms involving heavy data manipulation is concerned, the functional implementation (even optimised) will be nowhere near the performance of the imperative implementation with in-place update. For all of the reasons above, I would like to see something like threads in Javascript. Note that some current JS engines support this (though not in a web context at the moment). Note also that said engines are removing said support for various reasons (performance penalties are a large part of it). Clearly, it has been shown possible to implement threads efficiently in other languages, and so I do wonder how the decision processes of those VM developers might be affected if the spec where changed to mandate threads. As a final thought, I would like to say that it is actually possible to detect deadlock conditions at runtime and immediately throw an exception rather than simply hang the web browser. At what performance cost in the typical case, though? A cheap way is to rule out the possibility to acquire locks in a circular order. The performance cost will really be negligible. Rather than allowing the programmer to arbitrarily create locks, the API could provide a means to obtain a reference to (as distinct from aquire!) locks from a system-defined sequence of locks. As distinct from this, Java-like synchronized
[whatwg] Web Workers
for performance reasons. We will want to make use of it. For all of the reasons above, I would like to see something like threads in Javascript. Yes, threads give rise to race conditions and deadlocks, but this seems to be in line with Javascript's apparent philosophy of doing very little static error checking, and letting things just happen at runtime (e.g. nonexistent static type system). In other words, this may be simply a case of: yes, javascript allows runtime errors to happen. Is not allowing deadlocks important enough that we should make it impossible for a certain class of algorithms to exploit multi-core CPUs? As a final thought, I would like to say that it is actually possible to detect deadlock conditions at runtime and immediately throw an exception rather than simply hang the web browser. This, in my mind, makes deadlocks as good a user experience as any other sort of runtime error. Before I sign off, there is one more feature which (correct me if I'm wrong) is lacking from the current specification. There is currently no way for a program to find out how many cores are present in the host system. Without this, there is no way to know how many Web Workers to create for an algorithm that could easily be parallelised to any number of Web Workers / threads. Even, say, a parallel quicksort should not just create a new thread for each recursive invocation, as deep as it goes. For efficiency, this thread creation should stop as soon as enough threads have been created to match the number of physical cores. After this point, each core should handle its load by reverting to a single-threaded quicksort. -- Ryan Heise
[whatwg] Request to reconsider input minlength=
Greetings,
I saw HTML5 was put into last call, and I wanted to add my request to
reconsider adding input minlength= to HTML5. With some searching,
I found the following threads on the topic:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-February/005892.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011661.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016881.html
From these threads, I've seen the main reasons not to add the
attribute are:
* Lack of use cases
* input pattern= / can do the same job
* Unclear how user agents should implement the UI
* It's not compelling enough to balloon the spec
I recently completed a JavaScript form validation implementation using
HTML5 attributes and similar DOM methods (form.checkValidity(),
input.checkValidity() and input.setCustomValidity()). This API was
perfect, with the exception of missing minlength=.
Use Case
Our username and password fields require a minimum of four characters.
These fields have a simple pattern validation as well. I initially set
up the inputs as:
input required pattern=[a-z0-9]{4,} maxlength=20 /
This performs the desired validation correctly, but the problem comes
when reporting the validation error to the user.
validity.patternMismatch is semantically different than
validity.tooShort
In order to correctly report the error to the user, I would have to do
a second check of the value to figure out the problem. The only way to
determine that the error was caused by too few characters as opposed
to invalid characters would be to parse the pattern= attribute in
order to determine a minimum length required by the RegExp. Yuck. If
the value was too long, this job would be handled by maxlength=. I
added a minlength= attribute.
The final result:
input required pattern=[a-z0-9]+ minlength=4 maxlength=20 /
Is more readable, provides a validation task I believe to be quite
common without requiring knowledge of regular expressions.
Michael Fortin asked this question:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011683.html
Should an
input with minlength smaller than it's value be filled with padding
characters? Before or after the value? And what happens to those
characters as you type?
My answer: the UI should not be altered due to the presence of
minlength until validating the input value. There's no need to pad the
value or prevent deletion of characters.
Although I lack formal numbers, pretty much every password field I've
seen on the Internet requires a minimum number of characters, as do
most usernames.
The only legitimate argument against minlength= is that there is no
room for it in the spec, and I personally disagree with that assessment.
Cheers,
--
Ryan Cannon
http://ryancannon.com/
Re: [whatwg] Ogg content on the Web
On Dec 12, 2007, at 6:23 AM, David Gerard wrote: FWIW, Wikipedia and Wikimedia Commons only allow unencumbered formats on the site. Video MUST be Ogg Theora. Compressed audio better be Ogg. wikipedia.org is something like #8 in the world at present, so this is set to be a significant content repository actually used by people. A video tag which can be relied upon to support the format in at least Firefox would be enormously helpful to us and our readers. So far we have had zero patent trolls come calling. I wonder why that is. Because the Wikimedia Foundation doesn't have much money. Patent trolls are opportunistic, not idealistic. -ryan
[whatwg] *AGAINST* Removal of ogg from spec
After wasting what seemed like an eternity reading what can only be described as pure and unabridged dribble from Nokia. Before I continue to write this responce I would just like to thank Nokia for wasting 20mins of my life. I must express my disappointment that w3c is caving to pressure to remove an essentially free codec from the specification that was at best a recommendation, after all it said *should* not *must*, as to the preferred codec. In fact while we are here, supporting the removal of things beneficial to the end user, perhaps with HTML5 we should recommend that the html code be compiled so that users cannot read it as that would benefit a few minority companies that have done clever things with js/html/css and want to hide those things as trade secrets/IP. Maybe Nokia would be as good as to point out which codec is better? wmv? divx? mov? My argument in favour of a free codec is that all browsers could ship with it, without fear of being sued, this would allow users to watch/listen to clips/movies/music out of the box without scouring the Internet for codec XYZ for a once off use. That is not to say that the use of OGG should be explicit, of course anyone should be able to choose which codec they use to display their clips but for people just beginning (and even experts) it would be nice to have a single codec that is an implied standard. This way they don't have to worry will xyz be able to watch my funny 5min clip as they know that IE, FF, (er.. whats that mac browser called again?), etc will play ogg out of the box (so to speak). A good question that jumps to mind though is who are Apple / Nokia to tell anyone what should be a web standard, surely 2 companies that (in the scheme of things) aren't even that big (I will concede that Nokia are the market leaders in phones, but Apple are 2nd to who?? oh yes MS??), I would also point of that of the two companies opposing this one (apple) isn't known for its interoperability (propriety hardware/software, DRM locked music downloads that only play on apple products). Really if *anyone* should have any sway here (and I personally think that no 1 or 2 companies should) it should be Google lets face it they are the largest power on the Internet whether you love em/hate em/dont know who they are.. Another is what is Nokia thinking? (what am I on about you ask.. read on my children) Nokia build phones (yea I am dead smart), phones are only just getting to the point that they are decent enough to browse the web on but (yes i said but) there is no standard in place for them and lets be honest here, if a phone user comes across a divx clip its safe to say they won't be able to watch it.. Why? well phones generally aren't know for their ability to download new plug-ins (eg codecs). Now say we imply that ogg should be the default/standard for web AV (audio/visual) then all phones come with it built in and Nokia don't have to pay anyone royalties to use it, and mister end user (the guy that usually gets shafted by DRM and other incompatibilities) can browse and watch ogg clips on all the HTML5 compliant pages till his little heart is content. So we must ask ourselves why would Nokia want to get rid of a standard (that's not even set in stone) that is likely to mean they have to pay out more money per unit (thereby pushing prices of end user appliances up)? Sounds like they know something we don't (no I am not a conspiracy theorist/paranoid nutter), I just find it strange that a company that stands to lose profit margin would take such a stance.. Well thats my word count for the next month or so.. and a case of RSI to go with it.. I just hope that others here believe that these are vaild points and wont stand for companies forcing bad decisions upon the rest of us. -- Regards, Ryan McLean
[whatwg] void elements vs. content model = empty
So, I was just trying to check my blog for HTML5 conformance [1] and ran into a conformance problem that I had trouble sorting out. The conformance checker said: 1. Fatal Error: End tag param seen even though the element is an empty element. Line 121, column 73 in resource http://theryanking.com/blog/ so, I went to http://www.whatwg.org/specs/web-apps/current-work/ #param to see what the restrictions on param are. In that section it says: Content model: Empty. which brought up the question what's 'empty' mean?. In my mind, it could either be no content allowed or must be a void element (ie, no end tag). It took me awhile to realize that empty content was the same thing as a void element (it is, right?), which then helped be figure out that param couldn't have an end tag. It'd be nice if we could make this clearer in the spec– even though the language and html serialization are two different things, for the sake of authors it'd be nice to have pointers between the two. Also, if there's a difference between content=empty and 'void elements' it deserves an explanation. -ryan 1. http://hsivonen.iki.fi/validator/?doc=http%3A%2F%2Ftheryanking.com% 2Fblog%2Fparser=html5
Re: [whatwg] Attribute for holding private data for scripting
On Apr 9, 2007, at 10:27 AM, Maciej Stachowiak wrote: On Apr 8, 2007, at 11:12 AM, Henri Sivonen wrote: At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK suggests having an attribute for storing private data for scripts. Currently, one can invent an attribute and it will work for scripts. However, it will look ugly for conformance checking. Since this is essentially a conformance definition issue as browsers would not be required to implement anything new (assuming a new reflecting attribute on HTMLElement is deemed unnecessary), adding an attribute for script-private data would be rather easy. I think it would be worthwhile to add an attribute for script- private data to common attributes, so that scripters who need one and want to be conforming don't need to abuse e.g. title. The class attribute can already be used for script-private data. I think the time script authors go for made-up attributes is when they need a set of key-value pairs. Class is not so great for that, but I'm not sure any new attribute would be either, unless it provided some sort of built-in key-value parsing. If you want structured data in this attribute, why not just use JSON? -ryan
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Mar 7, 2007, at 7:09 AM, Michael(tm) Smith wrote: ... Amen. It's really amusing to see people continuing to trot out matter-of-fact statements dismissing XHTML. Those statements seem to fall into two basic types that can be paraphrased as either: - The only people who author documents in XHTML are naive developers/designers who do it just because they have been mislead into thinking that it's the cool/right thing to do. - The only people who user/serve-up XHTML are pedants who are out of touch with browser/implementation realities. It seems to me that those who make such statements either: - are unaware of any useful things that can be done with documents other than just displaying them in browsers -- or about how having those as well-formed XML can potentially make it easier to process them - have an agenda that makes them (consciously or unconsciously) want to dissuade others from using XHTML/XML (and XSLT, etc.) and to instead use alternatives (whatever alternatives they happen to personally be promoting) Or they realize that even those who (1) know what they're doing and (2) care, still get things wrong: http://validator.w3.org/check?uri=http%3A//people.w3.org/mike/ -ryan PS - my homepage is invalid, too: http://validator.w3.org/check? uri=http%3A//theryanking.com/blog/
Re: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser]
Guido, Thanks for supporting the effort. It looks like Mike already took the initiative to put something together. I look forward to meeting you at the event. Best, rs -Original Message- From: Grassel Guido (Nokia-NRC/Helsinki) [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 1:12 AM To: Ryan Sarver; [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser] Ryan, I support a more interactive session in addition to the big hall conference sessions. Subject could be something like: Web applications access to local resources - technical, security and usability challenges. Please give it a try by contacting the chair Ed Dunkin (mailto: [EMAIL PROTECTED]) [1]. Mention me as a supporter if you like. [1] http://xtech.expectnation.com/event/1/public/content/about Cheers - Guido On 2/26/07 8:53 PM, ext Ryan Sarver [EMAIL PROTECTED] wrote: Guido, Sounds like a pertinent session -- I'm really looking forward to this conference now. Do you know who I should contact to see about a BoF session or something similar around Geolocation? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 2:49 AM To: Ryan Sarver; [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: RE: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser] Mik, Ryan, all, I agree , this is a topic worth discussing in some form at Xtech (and why not already start on this list). My Xtech talk [1] provides some more motivation why controlled access from a Web App to local resources would be very useful, but also poses a significant thread if the security is not handled in a technically correct and usable way. [1] http://xtech.expectnation.com/event/1/public/schedule/detail/210 Regards - Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Ryan Sarver Sent: 23 February, 2007 22:10 To: Michael(tm) Smith Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser] Mike, XTech hadn't been on my radar, but after checking it out I will definitely be in attendance. I would be happy to join in on a panel or host a BoF if you think that would help. Let me know rs -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 2:41 AM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: XTech 2007 and web-app access to device GPS [was: Geolocation in the browser] Ryan Sarver [EMAIL PROTECTED], 2007-02-21 15:31 -0500: I am the Dir of Product Development at Skyhook Wireless where we have a Wi-Fi Positioning System - think GPS, but software-only and uses Wireless APs instead of satellites. We have been working on developing a plugin for Firefox that gives a website access to the user's location via javascript. User's can control access to this information at the domain level in much the same way they control cookies and popups. We have been successful in exposing it through the Javascript DOM and wanted to start talking with standards bodies about coming up with a standard implementation to make location-aware browsing common functionality at the browser level. Are you planning to attend XTech 2007 in Paris? I ask because I've had a session on the XTech program that relates in part to enabling web-app access to locating-sensing features on devices: Web-app access to sensors on mobile devices, May 15 at 2pm http://xtech.expectnation.com/event/1/public/schedule/detail/195 It's part of the Ubiquitous Web Day that Dave Raggett is chairing there. http://xtech.expectnation.com/event/1/public/schedule/topic/7 Anyway, I've been really interested in getting related discussion going on some mailing lists prior to that (which is what you've already done here :) and in making the actual session an interactive one with a lot of participation from the audience, and in having as much further discussion around it at the conference as we can manage. I've already been talking with a few others, and I think we can manage to get a good number of interested people to show up, so if you can make it to XTech for that, I think it'll be a good opportunity to start to talk face-to-face with others and share ideas about this. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] Geolocation in the browser
Mike, sounds good to me. Where should we create the list? I was going to setup a wiki page capturing the progress so far and giving the document a home and giving us a place to point to during our discussions. Let me know how you think we should handle the setup of a new list. rs -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 5:45 AM To: Ryan Sarver Cc: Dave Raggett; whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser Ryan Sarver [EMAIL PROTECTED], 2007-02-23 15:32 -0500: Dave, Thanks for following up -- I echo your thoughts exactly. It's great to see so much momentum and support within W3 already. I would be very interested in the upcoming workshop -- let me know when the call for papers opens up. From your point of view, what should the next steps be for documenting this and getting the ball rolling in terms of working towards standardization? Maybe we could set up separate mailing list for specific discussion about it? --Mike
Re: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser]
Guido, Sounds like a pertinent session -- I'm really looking forward to this conference now. Do you know who I should contact to see about a BoF session or something similar around Geolocation? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 2:49 AM To: Ryan Sarver; [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: RE: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser] Mik, Ryan, all, I agree , this is a topic worth discussing in some form at Xtech (and why not already start on this list). My Xtech talk [1] provides some more motivation why controlled access from a Web App to local resources would be very useful, but also poses a significant thread if the security is not handled in a technically correct and usable way. [1] http://xtech.expectnation.com/event/1/public/schedule/detail/210 Regards - Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Ryan Sarver Sent: 23 February, 2007 22:10 To: Michael(tm) Smith Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] XTech 2007 and web-app access to device GPS [was:Geolocation in the browser] Mike, XTech hadn't been on my radar, but after checking it out I will definitely be in attendance. I would be happy to join in on a panel or host a BoF if you think that would help. Let me know rs -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 2:41 AM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: XTech 2007 and web-app access to device GPS [was: Geolocation in the browser] Ryan Sarver [EMAIL PROTECTED], 2007-02-21 15:31 -0500: I am the Dir of Product Development at Skyhook Wireless where we have a Wi-Fi Positioning System - think GPS, but software-only and uses Wireless APs instead of satellites. We have been working on developing a plugin for Firefox that gives a website access to the user's location via javascript. User's can control access to this information at the domain level in much the same way they control cookies and popups. We have been successful in exposing it through the Javascript DOM and wanted to start talking with standards bodies about coming up with a standard implementation to make location-aware browsing common functionality at the browser level. Are you planning to attend XTech 2007 in Paris? I ask because I've had a session on the XTech program that relates in part to enabling web-app access to locating-sensing features on devices: Web-app access to sensors on mobile devices, May 15 at 2pm http://xtech.expectnation.com/event/1/public/schedule/detail/195 It's part of the Ubiquitous Web Day that Dave Raggett is chairing there. http://xtech.expectnation.com/event/1/public/schedule/topic/7 Anyway, I've been really interested in getting related discussion going on some mailing lists prior to that (which is what you've already done here :) and in making the actual session an interactive one with a lot of participation from the audience, and in having as much further discussion around it at the conference as we can manage. I've already been talking with a few others, and I think we can manage to get a good number of interested people to show up, so if you can make it to XTech for that, I think it'll be a good opportunity to start to talk face-to-face with others and share ideas about this. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] Geolocation in the browser
Kornel, I agree with you on the idea of not always using lat/lon as the returned data -- this is how we have it implemented in the upcoming version of Loki to test it out. The inherent problem with this model is that reliance on a reverse-geocoding service to provide that kind of information. If we want to allow existing GPS and NMEA-supporting devices to play in this world, we would need a reverse geocoding service to supplement the lat/lon. Its interesting to think about, but I don't know if its feasible on a broad level. As for your recommendation on the DOM api, I really like it: navigator.getGeolocation(); Your use cases and implementation also make sense. -Original Message- From: Kornel Lesinski [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 6:00 PM To: Ryan Sarver Cc: whatwg Subject: Re: [whatwg] Geolocation in the browser On Wed, 21 Feb 2007 20:31:11 -, Ryan Sarver [EMAIL PROTECTED] wrote: var location = window.getLocation(); For some applications location given in format other than lat/long may be more useful and less privacy-sensitive. For example name of the city might be good enough if you order a cab from a nationwide company. Postcode would be easiest way to integrate location API with existing services (especially via userjs/greasemonkey, where using location-postcode database may be difficult). Additionally city/postcode information may be provided to desktop browsers by the user (for example Opera collects that information already). Also different applications may be satisfied with different precision of location (searching for nearest airport vs nearest starbucks :) There's also privacy problem with giving too precise location and usability problem with asking for user's permission every time. My proposal is: use navigator.getGeolocation instead of window.getLocation to avoid conflicts with existing functions (window object is a global namespace in JS) and to avoid confusion with window.location object. navigator.getGeolocation() would return location with best precision allowed by default (without asking user every time). If user set in preferences that every page can get location with 10km precision, that would be returned. navigator.getGeolocation(100) would request location that has precision of 100m or better. If user's default allowed precision is lower than the specified one, browser would ask for permission. Browser would be allowed to return location with lower precision than requested (if it doesn't have information precise enough or because user decided so). The function would return an object, which could be queried about various aspects of the location - name of the city, postcode, but also precision of location given (so applications would know if user is really exactly in the middle of the city or if browser only knows the city name). -- regards, Kornel Lesiński
Re: [whatwg] XTech 2007 and web-app access to device GPS [was: Geolocation in the browser]
Mike, XTech hadn't been on my radar, but after checking it out I will definitely be in attendance. I would be happy to join in on a panel or host a BoF if you think that would help. Let me know rs -Original Message- From: Michael(tm) Smith [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 2:41 AM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: XTech 2007 and web-app access to device GPS [was: Geolocation in the browser] Ryan Sarver [EMAIL PROTECTED], 2007-02-21 15:31 -0500: I am the Dir of Product Development at Skyhook Wireless where we have a Wi-Fi Positioning System - think GPS, but software-only and uses Wireless APs instead of satellites. We have been working on developing a plugin for Firefox that gives a website access to the user's location via javascript. User's can control access to this information at the domain level in much the same way they control cookies and popups. We have been successful in exposing it through the Javascript DOM and wanted to start talking with standards bodies about coming up with a standard implementation to make location-aware browsing common functionality at the browser level. Are you planning to attend XTech 2007 in Paris? I ask because I've had a session on the XTech program that relates in part to enabling web-app access to locating-sensing features on devices: Web-app access to sensors on mobile devices, May 15 at 2pm http://xtech.expectnation.com/event/1/public/schedule/detail/195 It's part of the Ubiquitous Web Day that Dave Raggett is chairing there. http://xtech.expectnation.com/event/1/public/schedule/topic/7 Anyway, I've been really interested in getting related discussion going on some mailing lists prior to that (which is what you've already done here :) and in making the actual session an interactive one with a lot of participation from the audience, and in having as much further discussion around it at the conference as we can manage. I've already been talking with a few others, and I think we can manage to get a good number of interested people to show up, so if you can make it to XTech for that, I think it'll be a good opportunity to start to talk face-to-face with others and share ideas about this. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] Geolocation in the browser
Dave, Thanks for following up -- I echo your thoughts exactly. It's great to see so much momentum and support within W3 already. I would be very interested in the upcoming workshop -- let me know when the call for papers opens up. From your point of view, what should the next steps be for documenting this and getting the ball rolling in terms of working towards standardization? -Original Message- From: Dave Raggett [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 9:02 AM To: Ryan Sarver Cc: whatwg@lists.whatwg.org; [EMAIL PROTECTED] Subject: Re: [whatwg] Geolocation in the browser On Wed, 21 Feb 2007, Ryan Sarver wrote: Robert, I hear you ... the idea is really two fold -- the first part is to standardize how web applications access the location information, regardless of how it is determined. The second is to offer a standard way of different location acquiring technologies -- GPS, Wifi positioning, geocoding an user-entered address, etc -- to deliver location to the browser. In this case I am proposing using the NMEA standard as it is well documented and would allow for compatibility with existing GPS devices. Following on from Michael Smith's email on proosed W3C work in this area, I thought it might be helpful to provide a litte context. There is a great deal of interest in location based web applications and the challenge is how to expose this to browsers in a way that is independent of how the location is determined. Web applications may need control over what format the information is provided, and how often it is updated when the device is moving. There are obviously lots of security concerns over location and this is part of a broader context of giving web applications richer access to device capabilities. A common approach is to ask the user for permission each time the application is run. That raises usability concerns, such as is the user able to discern whether the application is bona fide website or whether it is a phishing site masquerading as a bona fide website. This is a real problem for desktop browsers and is likely to be an even greater challenge on the smaller displays on mobile devices. Walled gardens provide a partial solution, but don't scale to the Internet as a whole. W3C's April 2006 workshop on transpency and usability of web authentication looked at some of the issues, see: http://www.w3.org/2005/Security/usability-ws/report We are now planning a further workshop for June 5-6 in Dublin, Ireland to follow up with a broader look at the issues involved in declative models of distributed web applications. A public call for papers will be issued in the near future. An brief outline is given at: http://www.w3.org/2006/10/uwa-charter.html#workshops Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] Geolocation in the browser
One of the other options we have is to reverse-geocode the lat/lon and then return different levels of granularity based on that information 42.351036, -71.049378 = 332 Congress St, Boston, MA 02210 So sites like fandango that would only require a zipcode, we would only need to provide them a zipcode. The biggest problem with this implementation is that it requires an additional service on top of standard GPS. We have it built into our service, but adding it on top of GPS becomes a hurdle. We have also found that most users don't actually worry too much about the specificity of the location depending on the use-case. Most of the time they are more worried about the binary allow/deny of their location. I think it makes sense as a first revision to just piggyback on NMEA and just do a straight pass through of that information, with some possibly fuzzying logic within the browser. -Original Message- From: Gervase Markham [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 5:53 AM To: Ryan Sarver Cc: Henri Sivonen; whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser Ryan Sarver wrote: There are obvious privacy concerns -- I feel they can be alleviated with the proper level of control for the user. Currently in our prototypes, the browser prompts the user for each request, which they can allow or deny and then remember that preference for subsequent requests from that domain. What type of privacy control are you envisioning? I actually think it's easier to design a UI for this than many other things we might ask the user about. Explaining the impact of setting a cookie is rather hard. However, one example of the UI could be: The website skyhookwireless.com wants to know where you are. Firefox thinks you are [ Home: XX Heene Road, Enfield, London |V] Tell skyhookwireless.com: (o) Nothing ( ) To the nearest kilometre ( ) To the nearest 100m ( ) As precisely as possible [ OK ] Gerv
Re: [whatwg] Geolocation in the browser
Gerv, this is great feedback. I agree that it's important to think of fixed devices also being able to produce location information, especially without needing any type of location-sensing hardware or software. In terms of user's being able to give different addresses, I feel that is the job of the app itself. The browser should provide the location of the UA based on the user's privacy settings, and then it would be up to the app as to how they use it and give the user options on how to change or use that location. I think this is simple enough as instantiating a form with your current location, but letting users change that for subsequent requests. Or in the case of Yahoo Local, the drop down could have the following options: Your Current Location, Home, Work, etc Re: granularity - I agree that's a simple and functional way of fuzzying location. Thanks guys for all the great feedback :) keep it coming -Original Message- From: Gervase Markham [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 10:08 AM To: Ryan Sarver Cc: whatwg@lists.whatwg.org; Henri Sivonen Subject: Re: [whatwg] Geolocation in the browser Ryan Sarver wrote: The biggest problem with this implementation is that it requires an additional service on top of standard GPS. I wasn't envisaging any geocoding services. In my example, the address would be one the user had entered, and (assuming the machine has GPS at all) the browser had remembered as being at particular GPS coordinates. For desktop machines which never move, the browser may well have geocoded a typed-in address once and stored the lat/long to give to websites. If the machine has GPS, the default option in the dropdown might be Here: lat, long. But there would be other options. I think it's important that the user be able to give a location other than his current one - for example, if he's at work, but looking for the closest pizza restaurant to his home. The granularity setting is for privacy; I was imagining that the browser would round the actual value to the nearest whatever was appropriate, in order to introduce the necessary degree of uncertainty. Gerv
Re: [whatwg] Geolocation in the browser
Since I am a newbie in this regard, what do you think about passing something like User-Geolocation in the header of the request so that the server has access to the information as well? Obviously this is subject to some settings and privacy control on the UA, but it would allow the server to process the initial page content based on the user's current location. Thoughts? -Original Message- From: David Latapie [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 3:56 PM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote: - would it make sense to also expose it in the request headers? This way the server receives it on the first request as opposed to through the client after the initial page request User-Geolocation: 43.338018, -71.817930 Surely you've heard of ICBM (meta name=ICBM content=46.025507, 14.300186 /) Could elaborate on what you like and dislike on this? -- /david_latapie U+0F00 http://blog.empyree.org/en (English) http://blog.empyree.org/fr (Français) http://blog.empyree.org/sl (Slovensko)
[whatwg] Geolocation in the browser
Hey guys. I have been watching the list for a bit and thought it was time for me to jump in here and kick off a discussion on geolocation-aware browsing. I tried to search through the archives to see if the discussion had come up before and didn't find anything, so please forgive me if it has. I am the Dir of Product Development at Skyhook Wireless where we have a Wi-Fi Positioning System - think GPS, but software-only and uses Wireless APs instead of satellites. We have been working on developing a plugin for Firefox that gives a website access to the user's location via javascript. User's can control access to this information at the domain level in much the same way they control cookies and popups. We have been successful in exposing it through the Javascript DOM and wanted to start talking with standards bodies about coming up with a standard implementation to make location-aware browsing common functionality at the browser level. I was hoping to kick off a discussion around possible implementations and get the community's thoughts on the topic. Location could be exposed through a standard Javascript object/interface var location = window.getLocation(); - would it make sense to also expose it in the request headers? This way the server receives it on the first request as opposed to through the client after the initial page request User-Geolocation: 43.338018, -71.817930 What are people's thoughts on location in the browser? Is the window object the right object to attach to? Im interested to hear everyone's thoughts... Best, Ryan
Re: [whatwg] Geolocation in the browser
David, The ICBM standard is for geotagging the actual content whereas we are talking about a standard that lets the content know the location of the User or device so that the website can be location-aware. I want to use as much of the existing standards, but have more questions about where it should exist in ecosystem and how servers and webpages would expect to see it and use it. -Original Message- From: David Latapie [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 3:56 PM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote: - would it make sense to also expose it in the request headers? This way the server receives it on the first request as opposed to through the client after the initial page request User-Geolocation: 43.338018, -71.817930 Surely you've heard of ICBM (meta name=ICBM content=46.025507, 14.300186 /) Could elaborate on what you like and dislike on this? -- /david_latapie U+0F00 http://blog.empyree.org/en (English) http://blog.empyree.org/fr (Français) http://blog.empyree.org/sl (Slovensko)
Re: [whatwg] Geolocation in the browser
There are obvious privacy concerns -- I feel they can be alleviated with the proper level of control for the user. Currently in our prototypes, the browser prompts the user for each request, which they can allow or deny and then remember that preference for subsequent requests from that domain. What type of privacy control are you envisioning? As for a user-interface problem, its not much different than the allowing / blocking of popups on a per-domain basis. There are definitely existing standards to piggy-back ontop of in terms of UI controls and dialogs. -Original Message- From: Henri Sivonen [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 4:24 PM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser On Feb 21, 2007, at 22:31, Ryan Sarver wrote: What are people's thoughts on location in the browser? My first thought is that it is a privacy problem. And per-site configurability of the exposure of location data is a user interface problem. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Geolocation in the browser
That's a good point. I think you're right that the navigator object might make more sense: // Example var location = navigator.getLocation() alert(location.latitude+', '+location.longitude); thoughts? From: Steve Runyon [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 4:27 PM To: Ryan Sarver Subject: Re: [whatwg] Geolocation in the browser You couldn't use window.location because that's already used: the location object represents information about the URL of any currently open window or of a specific frame (Danny Goodman, JavaScript Bible 4e, p 486). How about the navigator object? On 2/21/07, Ryan Sarver [EMAIL PROTECTED] wrote: David, The ICBM standard is for geotagging the actual content whereas we are talking about a standard that lets the content know the location of the User or device so that the website can be location-aware. I want to use as much of the existing standards, but have more questions about where it should exist in ecosystem and how servers and webpages would expect to see it and use it. -Original Message- From: David Latapie [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 3:56 PM To: Ryan Sarver Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote: - would it make sense to also expose it in the request headers? This way the server receives it on the first request as opposed to through the client after the initial page request User-Geolocation: 43.338018, -71.817930 Surely you've heard of ICBM (meta name=ICBM content=46.025507, 14.300186 /) Could elaborate on what you like and dislike on this? -- /david_latapie U+0F00 http://blog.empyree.org/en (English) http://blog.empyree.org/fr (Français) http://blog.empyree.org/sl (Slovensko)
Re: [whatwg] Geolocation in the browser
Robert, I hear you ... the idea is really two fold -- the first part is to standardize how web applications access the location information, regardless of how it is determined. The second is to offer a standard way of different location acquiring technologies -- GPS, Wifi positioning, geocoding an user-entered address, etc -- to deliver location to the browser. In this case I am proposing using the NMEA standard as it is well documented and would allow for compatibility with existing GPS devices. I agree, there are very few GPS-enabled laptops - in fact the only one I know if us a UMPC - but there are a lot of Bluetooth capable laptops and Bluetooth antennas to provide the location. There are also solutions like ours at Skyhook that are software-only and would allow people to immediately begin to provide their location to the browser via a simple download. This would all obviously be configurable in the UA... -Original Message- From: Robert Accettura [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 8:29 PM To: Ryan Sarver Cc: Steve Runyon; whatwg@lists.whatwg.org Subject: Re: [whatwg] Geolocation in the browser Ryan Sarver wrote: Steve, good points… It’s also important to remember that this functionality would be an opt-in system – unlike your cell phone :) The prototype that we are working on would allow the browser to point to a COM port where it could find a GPS device or any NMEA-compatible device or software. It would then read the NMEA stream over the COM port and use that to deliver the user’s location to the website via the DOM. Our software positions you based on WiFi triangulation and can emulate a GPS device by streaming NMEA over a virtual COM port so that the user wouldn’t need to have a dedicated GPS antennae. I'd think a more practical approach would be to allow for a user-entered location, and let GPS override should the user have a GPS capable device. There are many good reasons to to have geolocation (statistical, custom content, etc.), but few GPS capable devices. I think more content providers would consider this to be a usable source of data if the UA had fallbacks (GPS, OS, preference in UA). -- Robert Accettura [EMAIL PROTECTED]
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
On Dec 11, 2006, at 6:25 PM, Ian Hickson wrote: On Mon, 11 Dec 2006, Michel Fortin wrote: And since profiles can now be applied on individual elements, there's no real need to keep the redundant vcard class name since it could easily be implied by the profile being specified on that element: div profile=hcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div How is that? It's one step away from: div class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div ...which would work just as well, and has the added advantage that it is compatible with how hCard is used today. Indeed. Michel's proposal is equivalent to your example, Ian. I think there's a middle way here that would work and maps to current practice. In our design of microformats, we make sure to do 2 things: 1. Use the same class name to mean the same thing, no matter what context. So, 'fn' is always a 'formatted name', no matter what microformat you're working with. 2. In the case of structured microformats (more than one value), we use a very rare term as a root class name. In the case of hCard, the root class name is 'vcard', which is rarely used in the wild for anything other than hCard. This greatly reduces the probability of collisions. Now, if I were to register the class name 'vcard' for use with hCard, would I really need to register all of it's child properties, like 'given-name' or 'family-name'? I don't think I should, because those only make sense when contained within an element with a class name of 'vcard'. We have a flat namespace, but it's disambiguated by context. So, here's a possible middle way: Keep profiles, but ditch the profile attribute. Instead of registering class names, register *root* class names and map them to XMDP profile URLs and documents[1]. I believe this is essentially equivalent to today's practice, though better organized. This means that community efforts like microformats.org can go ahead without interruption and that individual publishers can register their own root class names. For example, yahoo could register 'yahoo- com' then use this on all of their pages: body class=yahoo-com ... /body The first question is likely, what if yahoo wants to use hCard? Well, there's already plans to add the ability for one XMDP document to refer to another (this reminds me that I need to bug Tantek about that :D). So, Yahoo's XMDP document could point at the hCard XMDP document in order to make use of it on their website. -ryan 1. http://www.gmpg.org/xmdp/
Re: [whatwg] foreign attributes Re: several messages about XML syntax and HTML5
On Dec 4, 2006, at 11:04 PM, Elias Torres wrote: If you can read in the uF wiki [1] there's really not much guidance on how to parse one or all of them. There is more documentation than you suggest. See [1], which documents how to parse hcards. Much of the hCard parsing guideline apply more generally (extracting those common bits is on my todo list). Also, please note that we have a suite of test cases. The stable and agreed upon ones are here [2] and you can see work in progress in our mercurial repository [3]. -ryan 1. http://microformats.org/wiki/hcard-parsing 2. http://microformats.org/tests/ 3. http://hg.microformats.org/tests/
Re: [whatwg] foreign attributes Re: several messages about XML syntax and HTML5
On Dec 5, 2006, at 2:11 PM, Elias Torres wrote: There's plenty of documentation/code/test cases for *specific* microformats but no general rules for let's say additional fields in an hCard. Let me know if I'm missing any other documentation or overall principle in microformats. You're not missing anything. There is no documentation for additional fields in an hCard. There is no extensibility mechanism for individual microformats because it's not necessary. If you want to create a new vocabulary to use along with hCard, just start using it in your markup. If it becomes popular enough, you might be able to get it added to hCard (if it ever in the future diverges from a 1:1 mapping from vCard). -ryan ryan king wrote: On Dec 4, 2006, at 11:04 PM, Elias Torres wrote: If you can read in the uF wiki [1] there's really not much guidance on how to parse one or all of them. There is more documentation than you suggest. See [1], which documents how to parse hcards. Much of the hCard parsing guideline apply more generally (extracting those common bits is on my todo list). Also, please note that we have a suite of test cases. The stable and agreed upon ones are here [2] and you can see work in progress in our mercurial repository [3]. -ryan 1. http://microformats.org/wiki/hcard-parsing 2. http://microformats.org/tests/ 3. http://hg.microformats.org/tests/
Re: [whatwg] hash Attribute
On Nov 8, 2006, at 8:28 AM, Ian Hickson wrote: Given the various mechanisms that already exist to do this, it seems like adding yet another one would be a bad idea. I concur. If people are already using these technologies, we could learn from their usage and find ways to improve the technology. If they aren't being used widely, it would be wise to question whether there is demand for this functionality. -ryan
Re: [whatwg] Google research into web authoring techniques
On Jan 25, 2006, at 12:45 PM, Ian Hickson wrote: Google recently published some (not-very-scientific) research which people on this list will probably find interesting: http://code.google.com/webstats/index.html I plan to use this data to guide the development of HTML5. In particular, we probably need a copyright element. Would http://microformats.org/wiki/rel-license be helpful here? -ryan
[whatwg] Re: Web Forms 2.0
Greetings, In attempting to write a javascript implementation of Web Forms 2.0 attributes, I came across a stumbling block. At times, form validation requires a not pattern result, i.e. if a certain pattern matches the element value, the validation engine should return an error. The best real-world example of this type of implementation would be a form field with an initial value that must be changed in order to be processed as valid. I would suggest an attribute name notPattern, implemented as a reverse of the pattern attribute. e.g.: input type=text required=required notPattern=First Name\s* value=First Name / I hope it is not too late in this versions timeframe to bring such functionality in, as it seems impossible right now. -- Ryan Cannon Wordslinger, Webwright http://RyanCannon.com
