Re: [whatwg] Changing punctuation value of input element in telephone state
On 04/07/2010 03:49 AM, Mikko Rantalainen wrote: And nowadays you will see stuff like this: +358 (012) 1234 567 This contains the area code for Finland +358 in addition to the Finnish local distance number. However, there's a catch! When dialing, you must press +358121234567 because the first zero of area code is dropped if there's a country code. As a result, it's not safe to blindly drop the parenthesis from user inputted phone number. This is the case in the UK too. While in the US phone users tend to realise that the 1 on the front of the number is the national dialling prefix, in the UK the 0 that signals national dialling is always quoted as part of the dialling code, and phone users who don't use international numbers frequently don't realize that it's not strictly part of the telephone number. A common notation for UK numbers with an international prefix is: +44 (0)1206 123456 ...which, just as in your Finnish example, is either dialled as +441206123456 or as 01206123456 (were + stands in for your country's international dialling prefix.). Dialling +4401206123456 doesn't work. So with all that said, I don't think dropping punctuation is an adequate solution. Cellphones I've had both the US and the UK seem to be able to recognize the local conventions and normalize them to the correct form for number recognition, so perhaps browsers could adopt the same appraoch but this assumes that they would be able to detect what geographical area they are being used in and have support for various international numbering schemes, which seems like a big burden to put on a browser when dealing with telephone numbers is not its core concern.
Re: [whatwg] Window id - a proposal to leverage session usage in web application
Sebastian Hennebrueder wrote: thank you for the feedback. I hope that I see your point correctly. You are right, that for JavaScript based applications this can easily be solved with a sessionStorage. All technologies around GoogleWebToolkit, Dojo, Echo etc which hold the state in the client and make use of a stateless server side application can use the session storage to distinguish browser windows. But there are a lot of web technologies which hold the state on the server using the browser session. Technologies like Ruby on Rails, JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them. Those technologies can not make a simple use of the session storage. They are only aware of the browser session which is a common space of all browser windows. The windows id let them split the session in a per browser window scope. Originally, when playing with the window id concept, I simulated a window id by storing it in a session storage and adding it with the help of JavaScript as parameter to all links and as hidden field to all forms. It works to some extend but it pollutes the URL and is likely to cause problems with bookmarking and there is a use case where it fails. If you open a link in a new windows. In that case the first request is sending the wrong windows id. The server-side session management you describe is usually implemented via cookies, which as you note are scoped to a particular site and do not consider a particular window. Cookies and sessionStorage are conceptually similar in that both of them are mechanisms to allow a site to store data on the client. sessionStorage sets the scope of this data to be a (site, window) tuple rather than just site. So it seems like your use-case could also be addressed by providing an interface to sessionStorage that uses HTTP headers, allowing the server to use sessionStorage in the same way that cookies are used, without requiring client-side script and thus requiring the data to be set via an HTML page. To emulate the server-side session mechanisms you describe, you'd simply use a single sessionStorage value containing a session id which gets set in response to any request that does not provide it.
Re: [whatwg] URN or protocol attribute
Brett Zamir wrote: Hi, Internet Explorer has an attribute on anchor elements for URNs: http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx This has not caught on in other browsers, though I believe it could be a very powerful feature once the feature was supported with a UI that handled URNs (as with adding support for custom protocols). Imagine, for example, to take a link like: a href=http://www.amazon.com/...(shortened) urn=isbn:9210020251United Nations charter/a [snip details] I like what this proposal achieves, but I'm not sure it's the right solution. Here's an attempt at stating what problem you're trying to solve without any specific implementation: (please correct me if I misunderstood) * Provide a means to link to or operate on a particular artifact without necessarily requiring that the artifact be retrieved from a specific location. * Provide graceful fallback to user-agents which do not have any specialized handling for a particular artifact. This is different to simply linking to a different URL scheme (for example, linking a mailto: URL in order to begin an email message without knowing the user's preferred email provider) because it provides a fallback behavior for situations where there is no handler available for a particular artifact. == Example Use-cases == * View a particular book, movie or other such product without favoring a particular vendor. * View a map of the location for particular address or directions to that address without favoring a particular maps provider. * View a Spanish translation of some web document without favoring a particular translation provider. * Share a link/photo/etc with friends without favoring a particular publishing platform. (i.e. generalizing the Tweet This, Share on Facebook, class of links) == Prior Art == === Android OS Intents === The Android OS has a mechanism called Intents[1] which allow one application to describe an operation it needs have performed without nominating a particular other application to perform it. Intents are described in detail here: http://developer.android.com/guide/topics/intents/intents-filters.html An intent that does not identify a particular application consists of the following properties: * Action: a verb describing what needs to be done. For example, view, edit, choose, share, call. * Object: the URI of a particular thing that the action is to be done to. This is not specified for actions that apply only to a class of object, such as choose. * Object Type: the MIME type of the Object, or if no particular Object is selected a concrete MIME type or wildcard MIME type (e.g. image/*) describing the class of object that the action relates to. A process called Intent Resolution is used to translate an abstract intent like the above into an explicit intent which nominates a particular handler. Often when applications use intents a UI is displayed which allows a user to choose one of several available applications that can perform the action. For example, the built-in photo gallery application provides a Share command on a photo. By default, this can be handled by application such as the email client and the MMS application, but other applications can declare their support for intents of this type thus allowing plug-in functionality such as sharing a photo on Facebook. === Internet Explorer urn Attribute === Internet Explorer supports a non-standard attribute on the A element called urn, which accepts an URN identifying some resource. It is described in detail here: http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx It is not apparent that this attribute causes any behavior in the browser itself. It is possible that this is exposed to browser extensions in some way to allow them to overload the behavior of a link which identifies a particular class of resource. It does not seem that this attribute has achieved wide author adoption nor wide application support. --- Please reply with any other use cases and prior art you have. I'm particularly interested to see whether Android's (verb, object) tuple is actually required or whether the single object as afforded by your proposal -- and by the existing design of registering handlers for particular URL schemes and MIME types -- is sufficient for the use-cases at hand.
Re: [whatwg] Canvas - Exception on arc with negative radius
Dirk Schulze wrote: Another example is: http://blahbleh.com/molecools.php?name=1,2% 20dimethylcyclopropane If you turn the molecule a bit, the circles disappear with a INDEX_SIZE_ERR exception. Isn't it better to just ignore the arc and go on with the drawing, like Firefox does? And perhaps the same for arcTo? Assuming that we desire a do what I mean approach, it seems sane to me for a negative radius to be normalized to a positive radius with the same magnitude. It goes from being the distance from the center to the edge to being the distance from the center to the opposite edge. You might also like to visualize this as drawing the back of the circle.
Re: [whatwg] Persistent SharedWorkers
Drew Wilson wrote: - Permissions: Installing a persistent worker is essentially giving a web application a near-permanent footprint on your PC - we need explicit permission from the user, and we need some mechanism in the user agent to revoke this permission. There are a number of examples of similar permission-granting user flows (ActiveX installation, plugin install, gears) which we could use as a model for our grant/revoke permission UI. I think it'd be great if these things could behave in almost all respects like an extension or plugin that's been installed by other means. For Firefox it'd show up in the Add-ons dialog, for example. As a user, I don't really want to care which mechanism a site is using to install its extension, so having them all listed together regardless of whether they're NSAPI plugins, Gecko extensions or persistant workers would be nice. In some ways, it seems like effectively what you're trying to achieve is a standardized approach to Gecko extensions or Browser Helper Objects or whatever, hopefully also associated with some kind of permissions model that constrain what the extension is allowed to do in the browser to a greater extent than allowed by traditional extensions.
Re: [whatwg] Warnings for non-applicable properties
Ian Hickson wrote: On Mon, 10 Nov 2008, Paul Arzul wrote: is it unfortunate that the html4 stylesheet is only informative? perhaps html5 could then consider giving us a normative default user agent stylesheet - or at least a normative version with only display properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. Could that arguably be considered to be a machine-generated user stylesheet? I tend to think of the settings my browser has for choosing default fonts and so forth to be functionally equivalent to me writing a user stylesheet that contains the same settings. This would allow the HTML spec to normatively require browsers to use a particular default stylesheet (or, indeed, act as if they've done so) while still allowing for user-specific alterations of various kinds. (I believe that Mozilla is already implemented as above, more or less.)
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Toby A Inkster wrote: Calogero Alex Baldacchino wrote: The concern is about every kind of metadata with respect to their possible uses; but, while it's been stated that Microforamts (for instance) don't require any purticular support by UAs (thus they're backward compatible), RDFa would be a completely new feature, thus html5 specification should say what UAs are espected to do with such new attributes. RDFa doesn't require any special support beyond the special support that is required for Microformats. i.e. nothing. User agents are free to ignore the RDFa attributes. In that sense, RDFa already works in pretty much every existing browser, even going back to dinosaurs like Mosaic and UdiWWW. Agents are of course free to offer more than that. Look at what they do with Microformats: Firefox for instance offers an API to handle Microformats embedded on a page; Internet Explorer offers its Web Slices feature. If it is true that RDFa can work today with no ill-effect in downlevel user-agents, what's currently blocking its implementation? Concern for validation? It seems to me that many HTML extensions are implemented first and specified later[1], so perhaps it would be in the interests of RDFa proponents to get some implementations out there and get RDFa adopted, at which point it will hopefully seem a much more useful proposition for inclusion in HTML5. In the short term the RDFa community can presumably provide a specialized HTML5 + RDFa validator for adopters to use until RDFa is incorporated into the core spec and tools. It would seem that it's much easier to get into the spec when your feature is proven to be useful by real-world adoption. [1] canvas, keygen, frames and script are examples of this phenomenon.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Ian Hickson wrote: The question we should be discussing is not should it work? (because it already does), but rather, should it validate? No, the question is what problem are we solving?. Talking about RDFa, RDF, eRDF, Microformats, and so forth doesn't answer this question. The question should it validate is the question do we want to solve the problem and is this the right solution, which is a question we can't answer without actually knowing what the problem is. So far, all I really know is that the problem is apparently obvious. My understanding of the use-case, based on discussions so far, is: - Allow authors to embed annotations in HTML documents such that RDF triples can be unambiguously extracted from human-readable data without duplicating the data, and thus ensuring that the machine-readable data and the human-readable data remain in sync. The disconnect you're facing is that the proposers of RDFa consider the ability to encode RDF triples to be a goal, while you consider RDF triples to be a solution to a (as-yet-undetermined) higher-level problem. They take RDF as a given, while you do not. They have already solved some problems with RDF and wish only to adapt this generalized solution to work in HTML, while you wish to re-solve all of these problems from the ground up. Would you agree with this analysis? If this is accurate, then it's difficult to see how continued discussion on this topic can be productive.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Ian Hickson wrote: They have already solved some problems with RDF and wish only to adapt this generalized solution to work in HTML, while you wish to re-solve all of these problems from the ground up. I don't necessarily wish to resolve the problems -- if they have existing good solutions, I'm all in favour of reusing them. I just want to know what those problems are that we're solving, so that we can make sure that the solutions we're adopting are in fact solving the problems we want to solve. It would be irresponsible to add features without knowing why. I would assume that our resident proponents are already satisfied that their higher-level problem have been solved, and this is why they're frustrated that you won't just let them map their existing solutions into HTML all in one fell swoop. I'm not sure I'd put myself into the RDF proponent bucket, but I do know one use-case of RDF that I've encountered frequently so I'll post it as a starting point. The FOAF schema for RDF[0] addresses the problem of making personal profile data machine-readable along with some of the relationships between people. From the outside looking in, it seems that the goal they set themselves was to make machine-readable the sort of information you find on a social networking site. One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. Google Social Graph API[1] apparently makes use of FOAF (when serialized as XML) as one of the sources of data so that given a URL that represents a person it can return a list of URLs that represent friends of that person. The Google Profiles application[2] makes use of the output of the Social Graph API to suggest URLs that a user might want to list on his profile page, so the user only needs to fill in a couple of URLs by hand. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. There is a number of existing solutions for this: * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc * The vCard format * The hCard microformat * The PortableContacts protocol[3] * Natural Language Processing of HTML documents - Allow software agents to determine who a person lists as their friends given a page that represents that person. Again, there are competing solutions: * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc * The XFN microformat[4] * The PortableContacts protocol[3] * Natural Language Processing of HTML documents --- Assuming that the above is a convincing problem domain, now let's add in the following requirement: - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Now our solution list is reduced to (assuming we consider both requirements together): * FOAF in RDF serialized as RDFa or eRDF * The hCard microformat + the XFN microformat * Natural Language Processing of HTML documents All three of the above options address the use-cases as I stated them -- the Social Graph API apparently uses all three if you're willing to consider a MySpace-specific screen-scraper as Natural Language Processing -- so what would be the advantages of the first solution? * Existing RDF-based systems can use an off-the-shelf RDFa or eRDF parser and get the same data model (RDF triples of FOAF predicates) that they were already getting from the XML and Turtle RDF serializations, reducing the amount of additional work that must be done to consume this format. * FOAF has an extensive vocabulary that's based on fields that have been observed on social networking sites, while hCard is built on vCard which has a more constrained scope intended for the sort of entries you'd expect to find in an address book. * FOAF has been adopted -- usually in the RDF-XML serialization -- by some number of social networking sites (e.g. LiveJournal) so they are presumably already somewhat familiar with the FOAF vocabulary and may therefore be able to adopt it more easily in the RDFa or eRDF serializations. Though there are of course also some disadvantages: * Some sites are already publishing XFN and/or hCard so consuming software would need to continue to support these in addition to FOAF-in-HTML-somehow, which is more work than supporting only XFN and hCard. (In other words, XFN/hCard already work today) * RDFa requires extensions to the HTML language, while XFN, hCard and NLP do
Re: [whatwg] keygen
Maciej Stachowiak wrote: In the case of Safari, we store the generated private key in the Keychain, and sites using keygen typically respond with a signed certificate, which is downloaded and automatically added to the Keychain. Depending on the valid purposes of the key, users can then do the following automatically: 1) Browse to SSL sites that require client-side certificates for authentication, in Safari. [snip] In case it's useful, an example of the above use-case is http://www.myopenid.com/ , which is an OpenID provider that can use SSL client certs for authentication. The client certs are initially issued using keygen. I personally use it in Opera and Firefox, and they act in a similar way to what you describe for Safari.
Re: [whatwg] Modal dialogs in HTML5
Philipp Serafin wrote: timeless schrieb: On Thu, Dec 25, 2008 at 8:29 PM, Philipp Serafin phil...@gmail.com wrote: Well, you could still phrase it something along the lines of The size of a popup document's viewport SHOULD be calculated using the CSS shrink wrap algorithm... etc etc. as an embedder of a browser for a small device, i do *not* want such a requirement Hence why it would be a SHOULD and not a MUST. RFC 2119: This word [...] mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item [...] If the spec author knows the valid reasons, though, I would argue that it's better for interop to just spell out the situations where the requirement doesn't apply, rather than assume that implementors will ignore a particular requirement.
Re: [whatwg] Embedding images within editable content
Tab Atkins Jr. wrote: On Mon, Dec 22, 2008 at 2:53 AM, Shital Shah syte...@yahoo.com wrote: I'm wondering if there are any ideas being discussed to add an ability so users can embed images in editable areas. [snip] I'm confused about what you're asking. All decent WYSIWYG editors *do* allow users to insert images, and often other media. You can see the image right in the display next to all the text while you're editting it. I don't know what the original poster was asking about, but one issue I've encountered in this area is that users want to embed images from their own local drives rather than having to separately upload them to the server first. Unfortunately, the in-browser editors often make it look like this is going to work; users manage to get embedded images with file:// URLs that seem to work for that user but obviously will not work for any other user. However, I'm not sure what the solution is here. If contentEditable was a real form widget you could imagine it supporting a multipart/form-data upload of all of its contained images, or something. However, as long as client-side code is manually shifting the data to and from real widgets it's not clear how to do this since you can't just create a file-upload control with the filename pre-populated and submit it transparently.
Re: [whatwg] Embedding images within editable content
Tab Atkins Jr. wrote: On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins m...@degeneration.co.uk wrote: However, I'm not sure what the solution is here. If contentEditable was a real form widget you could imagine it supporting a multipart/form-data upload of all of its contained images, or something. However, as long as client-side code is manually shifting the data to and from real widgets it's not clear how to do this since you can't just create a file-upload control with the filename pre-populated and submit it transparently. You can't create a file input with the filename pre-filled for obvious security reasons, but you *can* still do some clever stuff here. In order to add a picture you'll probably need them to go through a file dialog anyway to select the picture, and you can make this *actually* be the file dialog of a hidden file input. You can then move this input around in the DOM without clearing its value, and submit it transparently. It's a bit hacky, but hey, web security is Serious Business. This is indeed the solution I employed in a webapp I developed some time ago. The main irritation with it was that I needed to submit the image to the server before it could be displayed in the WYSIWYG view, which required considerable hoop-jumping to put the image in a transient location that would eventually be cleaned up if the user didn't actually end up using the image on the page, or didn't save the page at all. It also didn't work in the copy-paste case, though admittedly in that situation we usually just ended up linking to off-site images rather than file: URLs, since the copy-pasting was from other websites. In an ideal world, the content and all embedded media would be submitted together in the ultimate form submission. One approach would be to use multipart/form-data and have the browser act as if the images were in file upload form widgets, and another approach suggested by another poster was to include the image using a data: URL. In both cases I would still want to do some server-side work after submission to extract the images and store them separately, but at least the user experience matches the expectation that the image is part of the document. Of course, neither of these approaches have particularly great fallback behavior. The data: URL approach looks the most promising, but apps that are not written with that in mind will presumably end up serving the content with data: URLs and confusing downlevel browsers. At least it'll do something sensible in modern browsers, though, while still making the images available for extraction server-side if desired.
Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
timeless wrote: On Fri, Dec 12, 2008 at 10:01 PM, Martin Atkins m...@degeneration.co.uk wrote: I think this makes a good case for not allowing any site to create browser-modal UI. Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? sure given many years and lots of rearchitecture. i suspect chrome and ie8 are closest. anyone else who runs javascript in process is almost certainly stuck. An alternative from Opera: The confirm dialog is whole-browser-modal, but it has a checkbox captioned Stop executing scripts on this page which allows you to forcefully kill off a script that's repeatedly displaying dialogs as in the example that prompted this message.
Re: [whatwg] salvaging work while navigating away from a web app -- onunload=confirm('save before quitting?')
Bil Corry wrote: Here's a fun one, I made this as a demo to show how a website could trap a user forever: http://www.corry.biz/neverleave.lasso I haven't tried it in any browsers lately, but a quick test with IE7 shows it still is effective (for it at least). I think this makes a good case for not allowing any site to create browser-modal UI. Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? In particular, the close tab and close window features, ideally along with things such as Back, Forward and Home should still be available. This does of course create some tricky interactions where onbeforeunload is concerned. If I try to close the browser/tab and the page uses onbeforeunload to create a confirmation prompt, how does this interact with the confirmation prompt only being tab-modal? Here's a strawman (which I'm sure has some subtleties I've not considered): When the user navigates away from the page, fire onbeforeunload. However, if the user navigates away from the page WHILE THE ONBEFOREUNLOAD EVENT IS BEING HANDLED kill off the onbeforeunload handler and do whatever the user asked for. A browser could potentially display some hard-coded (i.e. not site-overridable) UI here letting the user know that there's a page that's in the middle of shutting down and giving the option to kill it much like what happens when an application blocks Shutdown in Microsoft Windows. (though ideally without the confusing auto-timeout thing)
Re: [whatwg] When closing the browser
Ian Hickson wrote: On Fri, 12 Dec 2008, Bil Corry wrote: Or maybe it'd be better if non-persistent cookies are removed once the user no longer has an open tab to the site, instead of using a JavaScript-based solution. This could be done now; I recommend bringing this up with browser vendors as a feature request. I'm not sure this is as easy as it first appears. For example, consider the following case: * I have a single tab on site1 and I have a session cookie with them. * I navigate from a page on site1 to site2 and site2 replaces site1 in my single tab. * I navigate from site2 back to site1. Have I now lost my session cookie? This scenario is particularly important for technologies that use redirects to exchange data between domains, such as OpenID. Many OpenID implementations (for better or worse) use session cookies to retain state while they do the OpenID transaction, which involves redirecting the user away from your site to a URL on the provider's domain. If implemented exactly as stated, the session cookie would presumably be deleted during the OpenID transaction and the original site will break.
Re: [whatwg] Thoughts on video accessibility
Silvia Pfeiffer wrote: Take this as an example: video src=http://example.com/video.ogv; controls text category=CC lang=en type=text/x-srt src=caption.srt/text text category=SUB lang=de type=application/ttaf+xml src=german.dfxp/text text category=SUB lang=jp type=application/smil src=japanese.smil/text text category=SUB lang=fr type=text/x-srt src=translation_webservice/fr/caption.srt/text /video Could this combining of resources be achieved instead with SMIL or some other existing format? If there is already a format for doing this then I think HTML should avoid re-inventing it unless HTML's version is better in some way. On the other hand, if what is invented for HTML is indeed better in some way, it's likely to also be valuable outside of HTML, for example in situations where SMIL is used today. (For example, loading a video and its subtitles directly into a standalone player without needing to manually load both streams.) What are the advantages of doing this directly in HTML rather than having the src attribute point at some sort of compound media document?
Re: [whatwg] Thoughts on video accessibility
Silvia Pfeiffer wrote: I'm interested to hear people's opinions on these ideas. I agree with Ralph and think having a simple, explicit mechanism at the html level is worthwhile - and very open and explicit to a web author. Having a redirection through a ROE-type file on the server is more opaque, but maybe more consistent with existing similar approaches as taken by RealNetworks in rm files and WindowsMedia files in asx files. This (having a separate document that references other streams) is what I was thinking of. I guess which is more natural depends on who is doing the assembling. If it is the HTML author that takes the individual pieces and links them together then doing it in the HTML is probably easiest. My concern is that if the only thing linking the various streams together is the HTML document then the streams are less useful outside of a web browser context. If there is a separate resource containing the description of how to assemble the result from multiple resources then this resource will be useful to non-browser video playback clients. If an existing format is used then it can be linked to as fallback for users of downlevel browsers and will hopefully open in a standalone video player. If the only linking information is in the HTML document then the best you can do as fallback is link to the video stream, requiring the user to go find the text streams and load them manually.
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: On Wed, 26 Nov 2008, Philip Taylor wrote: If I'm not misunderstanding things, there is a new attack scenario: I post a comment on someone's blog, saying a href=/restricted-access.php?xsshole=form action=http://hacker.example.com/capture name=logininput name=usernameinput name=password/formcrawl me!/a Hm, this is indeed a problem. [snip] Is there anyone who can volunteer to edit this section as a separate spec? I guess I'll remove this section. I may be forgetting missing some use-cases here (I don't recall what exactly motivated this custom auth scheme) but there may still be value in a cut-down version of this scheme: WWW-Authenticate: HTML which means (roughly) The HTML document in the body contains something that, when displayed in a web browser, will allow the user to log in. Browsers can then use this authentication scheme in preference to Basic or Digest when multiple schemes are offered for a particular resource, and servers can simultaneously offer forms-based authentication and other authentication schemes at the same endpoint: HTTP/1.1 401 Unauthorized Content-type: text/html WWW-Authenticate: HTML WWW-Authenticate: Basic realm=my neat site form action=/login method=POST ... /form Software that is not a browser (for some suitable definition of browser -- something along the lines of user-agent where form-based auth is the norm?) can choose to use Basic authentication here. The backward-compatibility story here is bad as long as one of the offered authentication schemes is known to a downlevel browser. Per my basic research posted earlier, other, as-yet-unsupported schemes can be offered and the body will be rendered as desired except in Opera. I guess that this could be generalized to: WWW-Authenticate: Body meaning merely the body contains something that will allow the user to log in. Browsers could presumably in this case take into account the Content-type when deciding whether to prefer this scheme over the other schemes offered, for example choosing Body over Basic only when Content-type is text/html. I concede that once you generalize it in this way it becomes even less relevant to the HTML spec than it was to begin with, though I'm not sure where else to propose such a thing, and in practice as long as websites are primarily HTML login forms presumably will be as well.
Re: [whatwg] Solving the login/logout problem in HTML
Asbjørn Ulsberg wrote: [Request 1] GET /administration/ HTTP/1.1 [Response 1] HTTP/1.1 401 Unauthorized WWW-Authenticate: HTML realm=Administration !DOCTYPE html html form action=/login input name=username input type=password name=password input type=submit /form /html [Request 2] POST /login HTTP/1.1 username=adminpassword=secret [Response 2] HTTP/1.1 302 Found Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration Location: /administration/ [Request 3] GET /administration/ HTTP/1.1 Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration [Response 3] HTTP/1.1 200 OK !DOCTYPE html html ... h1Welcome!/h1 /html The twist here is that it is up to the server to provide the authentication token and through the 'Authorization' header, give the client a way to authorize future requests. Your auth token here seems to me to be equivalent to a session cookie. If you change the Authorization header in Response 2 to Set-Cookie (and make some syntactic adjustments) then this doesn't require any changes to how deployed apps handle sessions today.
Re: [whatwg] Solving the login/logout problem in HTML
Julian Reschke wrote: You can already handle the case of content that's available unauthenticated, but would potentially differ in case of being authenticated by adding Vary: Authorization to a response. According to section 14.8 of the HTTP 1.1 specification, the presence of the Authorization header field implies that the response varies by Authorization: When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: [some exceptions in the presence of cache-control directives] My understanding of this is that Vary: Authorization is effectively implied for all HTTP responses.
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: It seems to me that the first limitation of form authentication could be removed by inventing a new WWW-Authenticate challenge that means reply to the form in the page. I have now specified such a value in HTML5 (since it is specific to entity bodies that contain HTML forms): challenge = HTML [ form ] form = form = form-name form-name = quoted-string (There's no credentials value for this scheme, since the login is done as a POST to a login script and then the server sets proprietary login information, like a cookie using Set-Cookie.) So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. This idea has promise, but is it compatible with existing browsers? The case where the only challenge included is HTML is probably okay, since browsers will at this point likely determine that they don't support any of the given schemes and just display the entity body. The only concern in this case is browser-provided default error pages for the 401 response, which can hopefully be suppressed in much the same way as sites suppress IE's default 404 error page by padding the response to take it above a certain filesize. More bothersome is this case: HTTP/1.1 401 Unauthorized ... WWW-Authenticate: HTML form=login WWW-Authenticate: Basic realm=... Will existing browsers see Basic there and use that in preference to displaying the error page? I suspect the answer is it depends. I recall that some browsers only use Basic if it appears first, or perhaps only ever use the first in the list, which would be great for the use case of supporting at the same endpoint HTML auth for browsers and some other mechanism for non-browser agents that can't render HTML. (For example, a Microformats parser may be able to parse HTML and extract data but not have a way to present usable forms to the user.) There's also one more case to consider. Many sites react to an unauthed request by *redirecting* to the login page. Maybe: HTTP/1.1 302 Found Location: /login.php WWW-Authenticate: HTML form=login Where in this case the form is assumed to be in the body of the resource at /login.php, not in the response body. UI-wise I'm imagining that browsers would auto-focus, highlight or otherwise make available easily the nominated form once rendered. Is that what you were imagining?
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hallvord R M Steen wrote: I've built two-three websites that use content/language negotiation and I now consider it an architectural mistake to rely on negotiation because the URLs no longer uniquely identify the variants I in many scenarios need to identify. It's OK-ish to do it as a pure format choice where the server and UA just agree on using the PNG or GIF version for an IMG tag. For links *users* (and FWIW search engines, validators and other agents) may interact with it's however a big mistake to move away from one URL per variant of a resource. In light of my content negotiation experiments and experience I'd say an Access attribute in HTML would be harmful to the usability of URLs. As a URL user (web browsing human, HTML author, linker, bookmarker, E-mail-with-links author) I often want to be sure about what variant of a resource I link to. To be explicit about this across scenarios requires explicit URLs with language and type information. Agreed. I think the assumptions underlying content negotation are flawed, and thus the mechanism itself is flawed and causes confusion and inconvenience when used in practice. The sentiment underlying this proposal seems to be that HTTP content negotation would work fine if only the pesky browsers would support it, but I think there are deeper-rooted problems than simply a lack of browser support. I think a better solution is to publish the HTML version with attributed hyperlinks, like this: link rel=alternate type=application/pdf href=document.pdf or, if you prefer: a href=document.pdf rel=alternate type=application/pdf PDF Version /a This way clients can discover the alternative representations, but the alternative representations are all directly addressable so you can link to a specific representation. This approach is used in practice successfully today to make available Atom representations of HTML pages across the web. Atom feeds are arguably the best example of a successful completely-RESTful API that we have today, so this approach is proven to work. In future, once IETF has finished specifying this, it may also be possible to do this in the HTTP response headers for non-HTML resources: Link: document.pdf; rel=alternate, type=application/pdf (or something similar) ...and some other document formats such as Atom already provide equivalent linking constructs that you can use today.
Re: [whatwg] fixing the authentication problem
Eduard Pascual wrote: Not similar at all: for unencrypted connections, you have the don't bother me again option, in the form of an obvious checkbox; while with self-signed certificates you are warned continuously; with the only option to install the certificate on your system to trust it (which is a non-trivial task; out of the reach for most average users; still annoying even for web professionals; and, to top it up, you need to do it on a site-by-site basis). There is some sense in this requirement to store the cert. It allows the browser to warn you if the cert changes later, which is what would happen if an attacker managed to intercept your connection. If you don't store the cert, one self-signed cert is the same as the next. This is similar to the SSH model; the first time you connect, you're expected to manually check by some means that you're connecting to the right server. On subsequent connections, you won't be bothered unless the key changes. I'll concede that in most cases no-one actually verifies the key in the first connection case, but at least this requires an attacker to intercept your *first* connection from a particular client, rather than just any connection. The UI for this is a bit overboard in today's browsers, but I think the general principle is sound.
Re: [whatwg] The sizes= attribute for rel=icon
Ian Hickson wrote: In general I agree that attributes are not a scarce resource, but if you need to add use-specific attributes to a supposedly-generic element I think that indicates that the generic element is inappropriate for the use-case. I disagree. Look at input, for instance. I wouldn't have designed input as it is either. It seems arbitrary (and initially, confusing) to me that most form elements share one element but then a random handful have their own custom elements. (I guess you might argue, though, that textarea and button ought to be input types rather than the other way around.) I don't know what link rel type uses disabled, but I would have had the same objection to that. rel=stylesheet. Without wishing to take this thread off on a tangent (in other words, feel free not to address this here except as relates to the discussion at hand) I wonder what use-case motivated that attribute that couldn't have been satisfied by merely removing the LINK element from the DOM. Or, if you wish to attack it from the other direction, why a generic solution for causing browsers to temporarily ignore *any* HTML element (a use case for which might be pop-up dialogs that are hidden at certain points) wasn't more appropriate. Also, I note that the spec as it currently stands defines disabled only as a property of the HTMLLinkElement and not as an attribute of the LINK element. I don't know if this was intentional. Of course, I could very well make the same objection about a type-specific property on a class being better implemented by creating a new class. (In other words, I don't find the disabled attribute on LINK to be a compelling argument for overloading elements either.) Finally, what is the process for contributors to the RelExtensions page to include extension attributes? They can't. Given that you obviously consider it useful for third-parties to be able to introduce new rel values without changing the HTML5 spec, and that you also obviously consider it useful for certain rel values to carry additional attributes, I find it likely that some of these third-parties will also find it useful to introduce additional attributes. Would you not agree? link rel=icon type=image/gif; width=24, height=24 href=... This doesn't really work because we would need to add parameters to types we might not yet know. It also results in potentially complicated parsing rules, which I don't think people would get right. (See the comments I made for media queries.) Presumably this would be defined (if at all) for everything under image/, just as charset is defined for everything under text/. (In theory, at least.) Getting the relevant RFCs changed would likely be non-trivial. (Though we should probably look into it, actually, to fix text/*.) Given that (for now, at least) these type attributes would be of little use outside of HTML, could HTML not define them itself? Sure, it's a bit of a layering violation, but I would put it in the same boat as modifying MathML/SVG so that it works inside HTML: you just reference the bits of the other spec that suit you, and make your own exceptions, right? (loud objections from the MathML guys notwithstanding, of course. The MIME type RFC isn't authored by a W3C working group, so they won't find it so easy to complain!) On Fri, 9 May 2008, Kornel Lesinski wrote: I did a quick test with a bunch of random favicons: * Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide Leopard's monsterous 300KB icons) and displays last icon loaded, * Firefox 3b5 picks last icon regardless of attributes. It loads all icons when I reload page after restoring session. * WebKit nightly and Fluid pick last icon that has type attribute (even if type is bogus), or just last if none have type. [snip] I'm afraid that this could cause trouble (every visitor downloading icon that's 20–300 times larger than typical favicon). Why not use rel=application-icon or rel=appicon? I don't understand the question. I don't know exactly what Kornel was asking, but this seems to be a backward-compatibility concern. When given the following: link rel=icon sizes=16x16 ... / link rel=icon sizes=512x512 ... / ...current Opera will download both, which is suboptimal however you look at it. Current Firefox, though, will presumably download the 512x512 version in preference to the 16x16 one even though its icon slot is (usually) 16x16 pixels. I guess this concern would be solved (aside from Opera's behavior) if the spec were to say that a 16x16 icon, if specified, should be the last one listed for compatibility with legacy browsers. (Also, a 9.5 beta tester should probably inform Opera of that issue if they aren't already aware of it.)
Re: [whatwg] The iframe element and sandboxing ideas
Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: [snip list] Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox. One alternative would be to use a different element name so that fallback content can be provided for legacy browsers. In the short term, this is likely to be something like this: sandbox src=/comments/blah iframe src=/comments/blah?do-security-filtering=1/iframe /sandbox Once a large percentage of browsers support sandbox authors can start to be less accommodating with their fallback content, either by filtering out HTML tags entirely (which I'd assume is easier than just filtering out script) or at the extreme just setting the fallback content to be Your browser is not supported. This comment does not address seamless, which seems to be orthogonal and can thus be equally applied to both sandbox and iframe as currently specified.
Re: [whatwg] link rel=icon width= height=aRe:
Ian Hickson wrote: Using media queries for this is serious overkill. I can easily imagine uses for this that are from code that doesn't have a media queries implementation available, and this isn't something that implementors are going to implement media queries for. We need a solution that is easy to adopt from the implementation point of view. Fair enough. That isn't to say that media queries shouldn't be allowed, though, and if people use them then they should work, if the UA supports them. Would it not be better to explitly say that media queries are not appropriate for this, for interoperability? I don't really agree with the premise that we somehow need to be frugal with attributes. We should use them when they are appropriate. Sure, we shouldn't waste them, but they're not a resource in scarce supply or that has some insane cost to them. Note that we already have a DOM attribute on link that is specific to one rel type, namely disabled. In fact, generic attributes are a pain in the neck. Consider title, whose behaviour changes radically if we're talking about rel=stylesheet versus something else. In general I agree that attributes are not a scarce resource, but if you need to add use-specific attributes to a supposedly-generic element I think that indicates that the generic element is inappropriate for the use-case. I don't know what link rel type uses disabled, but I would have had the same objection to that. If the meaning of title is something different for stylesheets than for other link rel types then that was an inappropriate use of that attribute as well. It's too late to change it now, but that's no reason to continue overloading generic elements/attributes with special cases. link is also interesting in that unlike input type=... rel can contain several values. Is it conforming to use width and height attributes on a link element that contains both icon and a another, non-icon keyword? What about a rel=icon ... width=... height=... ? Finally, what is the process for contributors to the RelExtensions page to include extension attributes? link rel=icon type=image/gif; width=24, height=24 href=... This doesn't really work because we would need to add parameters to types we might not yet know. It also results in potentially complicated parsing rules, which I don't think people would get right. (See the comments I made for media queries.) Presumably this would be defined (if at all) for everything under image/, just as charset is defined for everything under text/. (In theory, at least.)
Re: [whatwg] link rel=icon width= height=
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. link type=image/png;q=1.0 media=all and (min-color:8) link type=image/jpeg;q=0.8 media=all and (min-color:8) Could this be said about size as well? link type=image/png 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. When I shrink my browser window down so that its viewport is 16x16px (assuming that it'd let me do such a thing) it's quite happy to apply a stylesheet with the above media query. It seems, therefore, that the width and height constraints relate to the rendering viewport and not to the device. The only leap of faith I see here is that when rel=stylesheet we're talking about the width of the source document's viewport -- because stylesheets don't have a viewport of their own -- but in the icon case we'd be describing the *icon* viewport i.e. the box into which the icon will be rendered. device-width and device-height seem to be more like what you're describing, though I'm not sure why you'd ever want to use these since browsers rarely inhabit the entire physical display even on mobile devices.
Re: [whatwg] link rel=icon width= height=
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 link 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: link rel=icon type=image/gif; width=24, height=24 href=... 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] link rel=icon width= height=
Lachlan Hunt wrote: Charles Iliya Krempeaux wrote: link rel=enclosure type=image/xxx width=640 height=480 compressioning=lossy coloring=truecolor href=A.xxx link rel=enclosure type=image/xxx width=1280 height=960 compressioning=lossy coloring=truecolor href=A.xxx link rel=enclosure type=image/xxx width=2560 height=1920 compressioning=lossy coloring=truecolor href=A.xxx ... could become... link rel=enclosure type=image/xxx metadata=size:640x480, 1280x960, 2560x1920; compressioning:lossy; coloring:truecolor; href=A.xxx For color, you are reinventing Media Queries. For compression, you are basically reinventing q values for MIME types. link type=image/png;q=1.0 media=all and (min-color:8) link type=image/jpeg;q=0.8 media=all and (min-color:8) Could this be said about size as well? link type=image/png media=all and (max-width:16px and max-height:16px) 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] postMessage feedback
Jeff Walden wrote: Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. On the other hand, if there is no particular reason why it is better for it to be on the document object, it seems sensible to me to be consistent with what already exists. (I'm not saying that there *is* no particular reason, but I don't know what it would be.)
Re: [whatwg] Element borders as resizable handles
Greg Houston wrote: While on the topic of borders, it would also be nice if there was a CSS property for their alignment, outside as is the current default, and inside. Pushing my luck, I would like to see the same options for the strokes in the canvas element with the addition of center which is the current default. CSS border-align: inside; border-align: outside; I'm not sure what effect you're intending these values to have, but have you looked at the CSS outline property? Does that achieve what you are intending? I suspect that this request would be better sent to the W3C CSS Working Group, anyway.
Re: [whatwg] ALT and equivalent representation
Shannon wrote: The ONLY business justification I have for using alt tags is that a w3c valid site REQUIRES them and this may increase the sites Google rank (which is just speculation really). If you take the requirement out to use them on every image in a valid site then you take away much of my argument for using them at all. In many juristictions, a company can face legal action if its website is not accessible per some standard or set of standards. This is the business justifaction I usually use; here in the UK, the Disability Discrimination Act[1] is the relevant reference. [1]http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/uk-website-legal-requirements.shtml
Re: [whatwg] Some video questions
Charles wrote: Maciej, But I think the premise of the question misses the point of the video element. I may very well be completely missing the point. I'll be satisfied if someone tells me that video is not intended to be the preferred way to embed video on web pages, in which case I'll quietly return to my corner. I may be misinterpreting your tone, but from reading this discussion it seems that you're deliberately being difficult. Of course video is the preferred way to embed video on web pages in HTML5. It seems that you are either inadvertently or deliberately misunderstanding the stack of components that implement audio and video playback in browsers. * The Quicktime browser plugin is a video player. * The Windows Media browser plugin is a video player. * The Totem Movie Player browser plugin is a video player. * YouTube's /player2.swf is a video player. * The video player used on channel9.msdn.com is a video player. * A browser's implementation of video is a video player. None of the above things are videos. They are used to play videos. None of the above things are media frameworks, either: * Quicktime's browser plugin is a front-end for the Quicktime media framework. * Windows Media browser plugin is a front-end for Microsoft's DirectShow media framework. * Totem Movie Player plugin is a front-end for either gstreamer or xine, which are both media frameworks. * YouTube's player is a front-end implemented in Flash to the media framework built in to the flash plugin. * The video player used on channel9.msdn.com is a front-end implemented in Silverlight to Silverlight's video API. (which I suspect uses DirectShow when running on on Windows.) * video is a front-end to a media framework or some media frameworks of the browser implementor's choice. It is up to the page author to decide which video player they wish to use. Currently, many authors create their own players in Flash or they use someone else's player written in Flash. video is an alternative to a video player implemented in Flash, and an alternative to embedding the Windows Media browser plugin. It is designed to embed video, not video players implemented in other technologies. But in Safari, video = QuickTime. Is that not a player-centric rather than a content-centric design? Please be careful to qualify QuickTime when you refer to it. It's perhaps partially Apple's fault for calling everything by the same name, but it's important to keep in mind the difference between: * The QuickTime player, which is an application users can run. * The QuickTime browser plugin, which is a browser plugin similar to the QuickTime player. * The QuickTime framework, which is an API provided by MacOS for video playback, which is used by QuickTime player and is also used by iTunes, Safari, and I imagine many other MacOS applications. (I'm not a Mac user, so I hope you'll excuse the lack of an extensive list of examples.) The same distinction exists in Windows. Windows Media Player, WinAmp, Media Player Classic and several other applications are all front-ends to DirectShow, which is the Windows equivalent of the QuickTime framework. Likewise, there are several Gtk+ and GNOME applications that use gstreamer. Neither QuickTime the framework, DirectShow nor gstreamer are video players. They are frameworks on which players are built. One thing that QuickTime the framework, DirectShow and gstreamer all have in common is that all of the media decoding is done via pluggable modules, so any of these frameworks can, assuming a suitable module is installed, play any video format. (assuming that we define video to mean a non-interactive sequence of images optionally synchronised with some audio.) The HTML5 spec doesn't say you must implement video with Quicktime, it simply describes the behavior of a video element and how it interacts with the page it's embedded in. It's up to the browser vendor to decide how best to achieve the behavior that the specification requires. I believe that it is correct to say that in the version of Safari under discussion, the video element is implemented using the QuickTime framework. However, you don't need to care about this. All you need to care about is what video codecs it supports. The HTML5 spec should ultimately require at least one video format that will be available in all compliant implementations, which Apple is likely to implement by simply supplying a Quicktime module that can decode that format. It is an accepted open issue with the HTML5 spec that there is not currently at least one standard video format required. You remarked in an earlier thread that you think YouTube ought to be able to embed their player via video. Here lies the confusion: video doesn't embed players, it embeds video. What we want isn't this:[1] video src=/player2.swf but rather something like: video src=/videos/Z73xtJN6IdA.flv That is, they would
Re: [whatwg] HTML5 Edit Link Relation
James M Snell wrote: This is just off the top of my head so I'm certain that there are probably reasons why this wouldn't work, but could we not do something like, link rel=edit put delete patch href=http://example.org/foo; / Edit indicates the purpose of the link, put, delete and patch indicate methods (in addition to GET). That doesn't tell you what sort of stuff you are allowed to PUT to that URL, though. I'm not sure that HTML is really the place to tell you that it expects an Atom entry, but without it knowing that it supports PUT is not that useful either. However, I guess one could argue that there should be something that acts as the opposite of the type attribute: rather than the type that should result when you GET, instead indicate the type that you should PUT. Probably too tricky to be worth it, though: it'd probably need all of the capabilities of the HTTP Accept header to be useful, and it's questionable whether that much detail should be defined externally of the resource itself. (I guess that discovering this sort of thing is what the OPTIONS method is for?)
Re: [whatwg] Web forms 2, input type suggestions
Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. type=address Indicates that the input should represent an address, the user agent may aid by displaying data from a GPS or use an online map etc. I have a little more trouble with this idea, for a number of reasons: * Address formats vary from region to region. * Sites usually want items like the postal code, state, county or town separated from the street address for various reasons. This is not catered for by your proposal. * To do anything special for this field beyond just displaying a big text box some sort of external data source is required, but it is not at all obvious what that data source would be or what a good UI for this field type might be. type=location Same as above but instead of sending an address string it would send latitude/longitude information, this (as opposed to the above) would send a well-formed string. Perhaps coordinates/geocoordinates or something else would be a more suitable name for the latter. I have similar reservations about this one, but at least there is a more obvious UI: mobile devices with built in GPS recievers could concievably provide an option to fill in the current coordinates. However, I'm not sure that submitting geographic coordinates is a common enough case to warrant an input type of its own. Part of me wants to generalize it to be type=2dvector and type=3dvector, which can then represent any 2D or 3D coordinates. I'm not really sure what a UA would do to such a field that would be any more useful than two or three type=text elements, though.
Re: [whatwg] Proposal: Allow block content inside label element
Brad Fults wrote: Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], the label element is defined as having inline content. When using the implicit form control association pattern described in the HTML 4 spec (e.g. a form control inside of the label element instead of or in addition to using the |for| attribute), this becomes a problem. Specifically, if one tries to place a textarea element inside of a label element, modern browsers will insert the textarea as a later sibling to the label in the DOM instead of as a child. This seems to be due to the fact that the textarea is a block element and that label can't contain it according to the spec. Some software that I'm responsible for frequently wraps label elements around div elements, purely because current versions of IE will not apply display:inline-block to inline elements. While I guess that is using a deviation from the HTML spec in order to compensate for a deviation from the CSS spec[1], it's still something I'm not going to be able to stop doing without a large amount of work. For this reason, I certainly wouldn't mind label allowing block-level children. Both Opera 9 and IE6 (the only browsers I have handy to test right now) already support DIV as a child of LABEL correctly, per Hixie's DOM viewer.[2] [1] A part of the CSS spec that Microsoft pioneered, but still... [2] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Clabel%3E%3Cdiv%3Edsfgdsfgsdfgsdf%3C/div%3E%3C/label%3E
Re: [whatwg] classList.toggle()
Maciej Stachowiak wrote: How about about adding a toggle() operation to classList? Adds the token if not present, removes it if present. This would be useful for script code that dynamically manipulates classes to cause style changes. It's been my experience that toggles are troublesome. In order for a call to toggle() to be successful -- where by successful I mean that it makes the change you intended -- you need to know the state ahead of time. If you have two distinct scripts toggling the same value, they're going to get out of step and think they're turning on when they're turning off. Or did you have a use-case in mind where it doesn't matter what the end result is as long as it's not what it was before?
Re: [whatwg] Script, style and backwards compatibility
Simon Pieters wrote: This could thus also imply: * Don't disallow lang= in XHTML5 * Don't disallow base href in XHTML5. * Don't disallow meta charset in XHTML5 (it doesn't do any good, but doesn't harm either). When using these, though, generic XML tools (i.e., those that aren't XHTML-aware) won't see these elements. This doesn't really matter much for the first and third, but for xml:base it can have a practical effect on how the document is processed in the presence of embedded XML fragments from other vocabularies. And if you aren't going to use generic XML tools or embed fragments from other vocabularies, why would you use XHTML rather than plain old HTML?
Re: [whatwg] include element
Christian Schmidt wrote: In practice, the result effect is often achieved by wrapping your include file in a document.write() and including this using script a script src= However, this makes it harder to write these includes by hand (you have to escape certain characters, ' \ \n \r \t), and debugging also gets more difficult. This last point made me think of a related issue: When you use the above technique, the included script runs in the security context of the including page, and this technique therefore requires complete trust of the included document. Would documents included via include run in the security context of the including page, as with the script technique, or would they run in the context of the included document, as with iframes? Personally I favor the latter, but I wonder if this impact's anyone's use-cases?.
Re: [whatwg] HTTP's Referer and Set-Cookie2 headers
Nicholas Shanks wrote: May I suggest that you also allow the DOM referrer attribute to match a HTTP Referrer header if one is present, and fall back to the Referer header otherwise. This provides for HTML 5 compliant UAs to be forwards compatible with a potential future HTTP spec that fixes the typo. I think it would be the responsibility of that hypothetical future HTTP spec to describe backwards-compatibility requirements. Having everything that depends on HTTP have language about handling a possible future extension of HTTP that doesn't even exist is likely to result in lots of conflicting requirements. Or is there actually a new version of HTTP under discussion somewhere that I've missed?
Re: [whatwg] Conformance for Mail clients (and maybe other WYSIWYGeditors)
Kristof Zelechovski wrote: I think the correct fallback for a photograph for its own sake is alt=(Use a browser that supports graphic images to view). That is basically what happens if you omit the alt attribute altogether. My graphical browsers (when I turn off images) write Image in place of the image to alert me that there was one there. Presumably aural browsers do something similar, telling the user that there is an image present at this position in the document. Also, your text is not particularly useful to someone with limited or no vision. It might as well say alt=(Use eyes that work properly to view this image) I expect that the browser-generated placeholder is more useful in almost all cases.
Re: [whatwg] WF2: Non-validating submit buttons
Anne van Kesteren wrote: On Wed, 04 Apr 2007 14:05:44 +0200, Christian Schmidt [EMAIL PROTECTED] wrote: It would be useful to be able to mark certain submit buttons as non-validating. There appears to be at least some demand for such a feature, and so far there has been no negative responses. What is the next step? Providing some compelling usecases. I thought we'd already done that. Here's a quick summary of the use-cases presented so far, though of course whether or not they are compelling is up to the reader to decide: * For cancel buttons where the server-side app just throws the submitted form data away, it's pointless to validate it client-side. * Allowing the user to submit an unfinished form to the server to be saved for later completion. * A preview button that allows the user to see the results of what has been completed so far without completing the entire form. * Buttons that trigger round-trips to the server to alter the form in some way. Of these, the first and last are the ones that I find most compelling as they are two things that are done in the wild on the web today that are broken — or at least made a lot more tricky — by the use of Web Forms client-side declarative validation.
Re: [whatwg] Default (informal) Style Sheet
Kempen, E.J.F. van wrote:
What exactly are you looking for? Defining that 'normal' text is black by
default and links are blue-ish? Because that's done already, most default
styles are uniformly, but maybe informally, defined.
One example that springs to mind is that the default CSS rules for
unordered and ordered lists differ between browsers. Some implement the
bullets with padding and list-style, while others use margins and
god-knows-what. I can't really remember anymore. I've just learned that
the way to get rid of the bullets across all popular browsers is:
ul, ul li {
margin: 0;
padding: 0;
list-style: none;
}
If you don't set both margin and padding, you'll see inconsistent results.
(Though perhaps this has been fixed in more recent times. I've been
doing the above as an idiom for years.)
Re: [whatwg] on codecs in a 'video' tag.
Maciej Stachowiak wrote: We think your reasons are strong and worthy of respect. That is why we are not trying to force our codec preference on you, but rather propose to leave this issue open. We ask you to respect our reasons as well, rather than trying to force us to go along with your codec preference. If there is no baseline codec in the specification, I firmly believe that one of the following will happen: * Everyone will end up implementing whatever Microsoft implements. * Microsoft won't implement video anyway, so no-one will use it. In practice, everyone's just mimicking whatever Microsoft does. At least when they violate the spec they can be called on it; if what they do is allowable by the spec, then everyone will have to copy it or they'll have a useless browser.
Re: [whatwg] Apple Proposal for Timed Media Elements
Maciej Stachowiak wrote: I think audio can use almost the exact same APIs for most things as video. This has the nice side benefit that new Audio() can just make an audio element and provide all the relevant useful API. To me, the distinction between the audio element and the Audio object is that the former has a place in the document where that audio content logically belongs, while the former is more of a global trigger for web application sound effects. audio could, for example, be rendered in-line with surrounding text in an aural browser. A visual browser would presumably provide some kind of representation in the document of the audio which the user can interact with. In other words, audio should be like img for sound. Of course, what the visual representation of audio should be is not an easy decision. It's even harder than video, because there's no inherent visual content to overlay a UI on top of.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Maciej Stachowiak wrote: - Even if all browsers end up supporting Ogg Theora/Vorbis, these are not the best-compression codecs available. So a large-scale video content provider that wants to save on bandwidth may wish to provide H.264/AAC content to those browsers that can handle it, even if all browsers could handle a lower-quality codec as well. - Many mobile devices cannot practically implement decoding in software, and rely on custom hardware which can handle only a fixed set of codecs. While hardware decoders for H.264 are widely available, I don't think there are any for Ogg Theora. Even in cases where the CPU in theory has the power to do some software decoding, this will be a much bigger battery drain than hardware decoding. So you really want the ability to serve the right codec to such devices. So while your average blogger may only upload media content in one codec, larger scale video service providers may want to take advantage of codec-based selection. This seems like a problem that can be solved by content negotiation. Content negotiation has the advantage that it doesn't potentially add extra requests to find the right representation: the browser just says here's what I support and the server does the best it can, or returns an explicit I don't have anything for you message. (Not Acceptable) However, as others have pointed out, MIME types only represent the container format and not the codecs inside, so content negotiation would need to be extended to somehow allow audio and video codecs to be presented in addition to container formats. Note that this problem applies when doing object-style fallback on the video element too, as you need to specify something in the type=... attribute to avoid the browser having to request every representation in turn to reject it.
Re: [whatwg] Full screen for the video element
Gervase Markham wrote: Simon Pieters wrote: Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, otherwise the author could hijack the user's screen and no way to get out of it (e.g. as soon as the user tries to exit fullscreen, the script goes back to fullscreen). Indeed. But it would be good to have an event which triggers when the user chooses to go full screen, so the page can e.g. hide headers and borders. (Or perhaps the onresize() event on the body already does that?). Hmm. Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! For the purposes of having video take up the entire space on my monitor, the page doesn't need to be any the wiser... it can go on thinking I'm viewing it in the little box on their site. An interesting point to note, though, is that this sort of full-screen switch effectively allows the user to bypass any overlaid ads/captions/UI that the site may provide.
Re: [whatwg] video, object, Timed Media Elements -- Part I SMIL
ddailey wrote: On Thu, 22 Mar 2007 13:03:24, Anne van Kesteren wrote 1. why not just include SMIL as a part of HTML, much in the same way that it is integrated with SVG? It is an existing W3C reco. Reasons for not using t:video were that it was 1) complicated and 2) not used. Thanks Anne... Is there some easy way to resurrect prior discussions of this from the archives somewhere? I would like to try to understand the reasoning here. SMIL doesn't seem complicated to me -- declarative animation is rather charming and the complicatedness is cognitively less demanding than scripting. Its popularity will probably be synergized by rather dramatic increases in use of SVG. SMIL solves problems far greater than the current aim of video, which is a much more modest goal of just being able to embed video interoperably in an HTML document. If you want to do all that fun SMIL stuff, then why not just use SVG? It already does it all. video for the simple use cases and SVG+SMIL for the complicated ones doesn't seem too bad a compromise to me.
Re: [whatwg] Full screen for the video element
Arve Bersvendsen wrote: Note that 'fullscreen' and 'fullscreen' are two different things: 1. A fullscreen mode on desktop should typically be a paged media, applying any 'projection' style sheets to the page 2. The fullscreen mode on Sony Ericsson P990i, M600i and a number of other UIQ phones still apply 'handheld' if existent, or 'screen' if so set in the user's preferences. The 'fullscreen' mode on these devices just happens to use all of your viewport, but it is not 'fullscreen' in the sense you'd think. As an Opera user I realise that this is already implemented and deployed, but I do think that taking projection to mean fullscreen is a bit of an abuse of that media type. If I press F11 in my browser, my 17 monitor doesn't suddenly turn into a projector. When I think of full screen I generally mean make the page take up the whole screen -- hide the browser chrome, not turn this web page into a slide-show. Not that Opera's feature isn't useful: I'd just prefer it were called Projection Mode and not Full Screen to avoid this very confusion that you've called out in your message. Too late now though, I guess!
Re: [whatwg] Full screen for the video element
Gervase Markham wrote: My assertion is that the idea of going to full screen (i.e. removing all chrome and allowing the content to take up as much space as possible) is a fairly common browser thing. Of course, those with a wider experience of browser implementations than I may well tell me I'm wrong. I very rarely want to view web pages full-screen, but I almost always watch video full-screen. I want a browser to allow me to scale the video over the entire screen without the site having to explicitly support it.
Re: [whatwg] Web Forsm 2.0 possible omissions
[EMAIL PROTECTED] wrote: 2) Auto tabbing for a 4 digit code: input type=text filter=\d autotab=4/ A more general request would be an ability to display one value but have a different one behind the scenes. Obviously when the user edits it they would expose the internal value, much like in an spreadsheet when you switch a field containing a formula from view mode to edit mode.
Re: [whatwg] video element feedback
Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. imageimage/* videovideo/* application application/* audioaudio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. What do you imagine application being used for? The application type category is pretty-much just miscellaneous.
Re: [whatwg] Video proposals
Vladimir Vukicevic wrote: If providing content in non-Theora formats is important, the client should list the supported video formats in the Accept header, and the server can send back the right thing. [snip] Though as has been pointed out by someone else earlier in the thread, the MIME types are attached to the container formats rather than the codecs. Seeing video/quicktime doesn't tell you what codec is used inside, and likewise video/x-msvideo. Perhaps something like an Accept-codec: header (though preferably something more generic than that) is needed: Accept-codec: audio/mp3, video/theora, audio/vorbis
Re: [whatwg] video element feedback
Ian Hickson wrote: A large portion of the feedback concerned the way that the current spec doesn't have any features for native browser-provided UI. I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. If we want to have this implemented well, we need to focus the browser vendors' concentration on specific features. Since it is easier to implement first an API then a native UI, rather than first a native UI and then an API, the API has to come first. Similarly, because authors can make a UI with an API but can't sanely make an API with a native UI, providing an API provides authors with more options. If LiveJournal on YouTube or some other site wanted to allow authors to embed video without requiring the authors to have to deal with JavaScript, they could create a page that contained just the video and video playback UI, with the video URI being taken out of the query parameters of the page, and then could give people markup that embedded the video using an iframe, as in: iframe src=http://video.example.com/video.html?src=http://example.net/v193;/iframe This would be a safe mechanism, and would be relatively easy to set up. (It doesn't even require server-side support.) I must disagree with the focus on the comparatively complicated case (video as part of a web application) vs. the more obvious case of I just want to embed a video in my web page. If I want to embed an image in my page or blog, I just upload it somewhere and write: img src=pretty.png If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Currently I do not routinely post video in my blog nor on any of my web pages because it is non-trivial to offer it in a portable manner. Your proposed solution is still too much work for the casual author: unless some other website is prepared to help me, I have to not only upload the video but also prepare a second page containing some script and markup to implement a user-interface. (And incidentally, LiveJournal doesn't allow iframes to be used either. I'm not sure if that's a LiveJournal peculiarity or a common thing in hosted weblog systems.) Please reconsider what you are focusing on as the simple case. I'd argue that these services like Google Video and YouTube have come about largely *because* embedding video on a web page is such a pain right now. If it were just a matter of uploading the video somewhere and linking to it, authors would be able to do this themselves in most cases without the assistance of sites like YouTube, much as right now most authors don't need a website to help them present static images. I won't disagree that specifying a full user interface to be provided along with the video element is a non-trivial task, but providing just a simple UI with a play/pause button and nothing else would, I expect, pacify most people after native UI for now. Browser vendors would be free to innovate their provided UIs much as Internet Explorer and Mozilla have with their image toolbars. I maintain, therefore, that the following two things should be catered for by the spec in addition to what's already there: * By default, browsers are expected to provide at minimum a play/pause toggle button which does not interfere with the size of the movie. (This implies that it must be some kind of overlay, ensuring that the size given by the page author is the size that the video will actually play.) * An attribute is provided to disable the default buttons so that apps providing their own branded UI don't end up with confusing interfaces. I'd be interested to hear what is so difficult about the above. Browsers already do much more complicated things than this.
Re: [whatwg] Attribute proposal: video autostart
Alexey Feldgendler wrote: Automatic behavior in HTML has been traditionally expressed through scripting. It's not hard to write a one-line script which automatically starts playback, but solutions based on scripting are easier to circumvent on the user side (and it's good). -1 for |autoplay|. It's been my experience that annoyances based on attributes and elements are far easier to tame than those using script. For example, it was trivial to remove the effects of target=_blank on links, but harder to tame window.open. Modern UA's block calls to that function altogether, causing many scripts to fall over because they expect window.open to always succeed. I'd say in the general case it's far easier to block declarative instructions (elements, attributes) in a useful way than it is to block imperative instructions (JavaScript statements), because it's much easier to reason about what the author was trying to achieve in the former case.
Re: [whatwg] Comments on the video element
Mihai Sucan wrote: For Youtube, a site which provides bloggers an easy way to integrate videos, this would prove even ... hard. Here's the simple code users have to copy/paste: object width=425 height=350 param name=movie value=http://www.youtube.com/v/id;/param param name=wmode value=transparent/param embed src=http://www.youtube.com/v/id; type=application/x-shockwave-flash wmode=transparent width=425 height=350/embed /object Switching to the video element, would require a script element, and technically, for the developers at Youtube, this would mean a lot more work. They script must be carefully coded so that it doesn't break the myriad of blog systems, etc. Blogs don't even allow scripts to be run (last time I heard). Say Youtube wants to do this, users themselves would no longer like this. What? Am I going to put a potentially risky script within my site? This comment has reminded me about LiveJournal... LiveJournal traditionally barred all SCRIPT and OBJECT elements (and various other, similar elements) in all user-supplied content because it would allow users to run arbitrary code in LiveJournal's security context. More recently, LiveJournal has made an exception for OBJECT elements that match certain predefined patterns, such as the above YouTube code. They even attempt to massage the code to prevent auto-play. Having a completely declarative (i.e. no scripting required) video element would, I'm sure, be very useful to LiveJournal since they would be able to allow it as indiscriminately as they do img right now. However, if it requires any scripting to use it'll never work because LiveJournal absolutely cannot allow scripting. So allow me to offer this as another vote to video being, by default, a completely standalone element with browser-provided UI. By all means allow authors to override it if they want to do something neat.
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Asbjørn Ulsberg wrote: Improving on the legacy, proprietary DOM just isn't feasible, imo. Are there particular parts that overlap between IE's DOM and the standard DOM where IE's implementation is non-compliant? If not, why can't IE simply support both sets of methods at the same time? (In other words, add the standard DOM classes, methods and events while leaving in all of the proprietary stuff that people depend on.)
Re: [whatwg] base versus xml:base
Asbjørn Ulsberg wrote: If it is, then when looking at links inside head, relative URIs are resolved using a base of bar/foo/bar/ (taking [EMAIL PROTECTED]:base into account twice: once to resolve [EMAIL PROTECTED], which sets the document's base URI, and then relative to that base URI to resolve [EMAIL PROTECTED]'s). Hm, that sounds weird. I'd say once [EMAIL PROTECTED] is resolved (taking into account the parent xml:base URI), then that's final. Any xml:base's after base's presence will override the base, but I don't see a reason for applying xml:base twice. Since base is a special case element that magically affects all URI's in the document, I'd say it works like that even when combined with 'xml:base'. This kinda-cyclic definition is caused by the fact that the base element is defined as actually setting a property of the document as a whole. So let's imagine that there's in illusionary element enclosing the whole document, so that we can write this in terms of xml:base... So if we imagine that we've retrieved a document from http://example.com/: (document) xml:base=http://example.com/; html head xml:base=foo/ link href=bar.html / /head ... /html /(document) So here, that link ends up being http://example.com/foo/bar.html, because the xml:base on head is relative to the xml:base on the document. Now if we throw in an HTML base element: (document) xml:base=??? html head xml:base=foo/ base href=wibble/ / link href=bar.html / /head ... /html /(document) What is the document's xml:base set to now? the base element overrides the original document URL, making it http://example.com/foo/wibble/, but since the xml:base on the document is now http://example.com/foo/wibble/, the base href is now http://example.com/foo/wibble/foo/wibble/ and so on ad infinitum. So it seems to me that base href has to be a special case of some sort. I'm not sure what the special case should be. I think in this case I'd expect the notional xml:base on the document to be http://www.example.com/wibble/ and the URL in my link element to end up as http://www.example.com/wibble/foo/bar.html ... in other words, the base href has ignored xml:base entirely... the base href attribute is in effect acting as if it were the xml:base attribute on my imaginary (document) element, regardless of its actual position in the DOM.
Re: [whatwg] Fallback behavior
Maciej Stachowiak wrote: As far as I can tell, the current spec does not adequately define how fallback behavior works. Specifically, what should be done with fallback content when not falling back? Presumably it should be parsed into the DOM, but should not render - that's the de facto behavior. [snip] Also, object id=movie data=movie.ogg object id=movie data=movie.mov object id=movie data=movie.asf pBlah blah movie alternative text.../p /object /object /object If these things remain in the DOM, authors will presumably need to give them all distinct id values. Now if I want to access these things from script, such as to provide an alternative player UI, I need to somehow determine which one is actually being used in order to target it. If they're all in the DOM, I can't just rely on getElementById returning null for the unused cases. What's the solution in this case?
Re: [whatwg] several messages about HTML5
Benjamin Hawkes-Lewis wrote: James Graham wrote: Obviously I would love to be proven wrong but given the limited success in this field in the last decade, I'm not holding my breath. What actual attempts have been made in this field, that could be judged relative successes or failures? The best category of software to use for examples is that of WYSIWYG XML editors. These generally try to get users to specify semantics while simultaneously showing them the presentational result of those semantics and constraining them to some kind of schema. For example: http://xopus.com/ http://www.syntext.com/products/serna/ http://bitfluxeditor.org/ Whether they have been a successes or failures I'll leave for others to decide.
Re: [whatwg] X/HTML5 and DocBook
David Latapie wrote: Hello, I never used it, but a common complaint about DocBook is that there is too much tags. Now, considering how microformats seems to be the Next Big Thing™ (and we are talking quite a lot on this ML about this technology), could someone with a background in DocBook tell me (us) how X/HTML5+microformats differs from DocBook? Please remember I may have wrong ideas about DocBook (or about X/HTML5, for that matter). I believe the Simplified DocBook DTD was invented to address the concern that DocBook was too complicated. I've seen Simplified DocBook as an attempt to get an HTML-like simplicity while retaining the powerful structured nature of DocBook documents. HTML5 comes at this from the other perspective, to a certain extent: while Simplified DocBook scaled down DocBook to be more like HTML, HTML5 adds structure elements to HTML to make it a bit more like DocBook in many respects. Of course, that's not all HTML5 does. Many of HTML5's new features are not for documents at all, but rather for web applications.
Re: [whatwg] The m element
James Graham wrote: Leons Petrazickis wrote: They are marking the search terms with a highlighter. In an aural browser, would these terms be read differently? Perhaps. Does this transfer to mobile browsers? Very definitely. How would an auraul browser treak these terms differently? I can perhaps imagine some sort of generated content e.g. the foo mbar/m would be read the foo `begin mark` bar `end mark` but it's not entirely convincing. [snip] what useful features could a general purpose UA implement if this semantic information is made avaliable to it? The first thing I tend to do when I load up a Google Cache result is do an inline find for one of my search keywords or manually scan the page for the yellow text. Some keyboard shortcuts or on-screen buttons for skipping back and forth between highlights would be nice. I can't think of any use-cases for highlighting where this navigation aid *wouldn't* be useful. After all, the purpose of highlighting is to help your eyes locate important information more quickly; when you express it with markup, it can help your browser to help your eyes locate important information more quickly in a document that doesn't all fit on-screen at once. As for aural browsers, they too can implement the above navigation aid, but allow the user to have the surrounding context read as well so that it actually makes some sense, thus avoiding reading the entire document just to locate the highlighted text.
Re: [whatwg] The m element
Geoffrey Sneddon wrote: On 8 Feb 2007, at 15:23, Leons Petrazickis wrote: In the Western world, the standard for highlighting is a neon yellow background. I submit that a much better name for m is hi (hilite, highlite, highlight). People don't necessarily mark text much -- if anything, mark implies underlining, circling, and drawing arrows -- but they do highlight. In university, I often saw students perched with their notes and a highlighter, marking important sections. The semantic meaning is to draw attention for later review. In my eyes such an element is presentational – a more generic element, but one with semantic meaning, like m is far more relevant (although it may well be a good idea to suggest it be rendered as highlighted). The *meaning* is that the content is highlighted. The concept of highlighting something is not presentational. When I'm giving a speech, I can highlight a certain fact that my listeners might not have been aware of. (e.g. by saying Allow me to highlight the fact that...) highlight just means draw attention to, which is exactly what Google's cache highlighting is trying to do, and what a student highlighting passages in a book is trying to do. The highlighting has no effect on the content, it's just a navigation aid. While the presentation in graphical browsers would likely resemble that of paper — that is, a yellow background — an aural browser wouldn't draw attention to the mark as it is being read. It would hopefully instead allow a user to quickly skip between passages containing highlighted text much as sighted people do with their eyes as they scan over a page with highlighted text.
Re: [whatwg] Problems with DOMTokenString
Maciej Stachowiak wrote:
Alternative #2: leave the className an ordinary string, but add a new
readonly DOMClassList classList property with something like the
following interface:
interface DOMClassList {
void add(DOMString newClass);
void remove(DOMString removeClass);
bool has(DOMString possibleClass);
}
If you add DOMString index(unsigned i) and unsigned length, you would
also have the ability to enumerate the classes easily, which the API as
currently specced lacks. Because the classList property would be
readonly, there would be no question of whether two elements ever share
a DOMClassList.
Extending the DOMElement interface with a new, read-only property does
seem better to me than overloading the existing className property. I
like this approach, but I don't like the name DOMClassList.
If you leave it called DOMTokenString (or DOMTokenList, if you like)
then it can also be used for other strings of space-separated tokens:
interface HTMLLinkElement : HTMLElement {
// ... all of the existing stuff ...
readonly DOMTokenList relList;
readonly DOMTokenList revList;
readonly DOMTokenList mediaList;
}
Admittedly these are much less likely to be toggled at runtime in the
browser than the class, but it may be useful for scripts that search the
document for anchors with particular relationships, for example.
[whatwg] WF2: Non-validating submit buttons
It would be useful to be able to mark certain submit buttons as non-validating. Use case: lots of the forms generated by one of my web-apps have a Cancel button which simply causes the server to redirect the user back to wherever they came from. When I use the WF2 extensions to mark required fields, formats, etc the Cancel button won't submit until the form is completed correctly. This doesn't make much sense from a UI perspective. I propose a flag on the submit button elements (both INPUT and BUTTON TYPE=SUBMIT) which causes the browser not to run the usual validation procedure before submitting when that button is pressed. For example: input type=submit validate=no / I'm not fussed about the exact name/usage of the attribute, but it seems like a common enough case to warrant a declarative solution rather than a script one.
Re: [whatwg] xml:space
Anne van Kesteren wrote: xml:space can't affect the tree being formed as far as I know. It's not entirely clear to me what its use is anyway, except in SVG, where they defined it in a funny way to make it do something. Presumably its primary purpose is to act as a signal to generic XML tools — that don't have any special knowledge about XHTML — that they should not screw around with the whitespace inside PRE, etc. One obvious example of such a tool is an XML pretty-printer. While an HTML pretty-printer like HTML Tidy can have rules hard-coded into it, this is not true of a non-validating XML formatter unless it is specifically written for XHTML.
Re: [whatwg] blockquote cite and q cite
Benjamin Hawkes-Lewis wrote: What are you guys talking about? You've got this exactly backwards: you don't consult online services to find out ISBNs (although you can); you use ISBNs to find books on online services. So do you expect browsers to use an online service to look up information about a given referenced book? What online service should they use to do this, and what happens when that online service ceases to exist at some point in the future? I'm not sure what exactly you expect browsers to do with the ISBN you've entered. Certainly just displaying the bare ISBN onscreen with no other information isn't very user-friendly.
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
Mike Schinkel wrote: But you are assuming there is a downside to them for calling it foo-name vs. just name. There isn't; developers use conventions all the time. And if you read my proposal clearly, the prefix is only needed on a top-level element or to disambiguate. I'm not sure if you are actually proposing what I'm proposing or if you're just mentioning this in passing, but it seems to me a reasonable compromise to create a registry of *container* classes which can contain microformats or other extension stuff. Since these things only have to be used once, they can be a little bit obtuse to avoid conflicts with author-invented classnames. You just need to mention in some spec (which, in theory, doesn't even have to be the HTML5 spec, since class is just an list of opaque strings as far as HTML is concerned) that there will be a registry of container classes which will all have some common prefix and that within that container anything goes. Some arbitrary new microformat foo could then be assigned (for example) the prefix x-foo, into which it can plonk whatever it likes: div class=x-foo div class=cheeseCheddar/div /div You could even go so far as to specify that these prefix names will never contain a dash, so the owners of the x-foo prefix would be able to invent their own containers such as x-foo-giraffe without fear of a later registrant getting that as a container name. If any of the inner classnames conflict between schemas, they can be disambiguated in CSS and elsewhere using contextual selectors. Authors would then be discouraged (but probably not forbidden) from using the x- prefix (or whatever is selected) for their own made-up classnames.
Re: [whatwg] Inline SVG
Michel Fortin wrote: Le 8 déc. 2006 à 15:20, Leons Petrazickis a écrit : http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008444.html Unlike Michel Fortin's proposal for script type=image/svg+xml/script, I suggest that SVG included like this be rendered as an image in that exact spot. We may want to define a default height and width for all inline-xml.../inline-xml content. [snip] script is already parsed as text content by current browsers, so for current browsers that can't execute the script, it would be possible for an external JavaScript to parse the content, build, and insert the new elements into the DOM. Using script has the ultimate advantage that existing browsers will *already* ignore it, while for some new element legacy browsers will attempt to parse the contents as HTML and may end up displaying something unintended. It's unclear how you'd implement fallback behavior for script type=application/xml, though, since the only fallback for script is noscript, which is ignored if the browser supports scripting of any kind, regardless of type. This also raises an interesting question about how you'd embed an XML application that itself features a script element, since any /script ends the parsing of the script element regardless of nesting. (The HTML parser just sees the XML as an opaque block of text.)
Re: [whatwg] PaceEntryMediatype
Ian Hickson wrote: Then the browser wouldn't take these links and make them available in a list of feeds interface, which is the problem we are trying to solve. Why is it useful for a browser to make a list of a bunch of random feeds that have no relation to one another or to the current page? A list of feeds *for the current page* I can see a use for (that little orange RSS icon on my browser's toolbar), but for links to other feeds a list inside the page itself is perfectly adequate, especially if that link actually links to an HTML document that *itself* declares a the feed as a LINK. Currently the orange RSS icon means Subscribe to this page. This is a lot more useful (in my opinion) than it meaning subscribe to some random thing.
Re: [whatwg] several messages about XML syntax and HTML5
Sam Ruby wrote: [snip] HTML5 can do one better. Instead of handling presentational MathML as a special case, this support can be generalized. When a non-HTML element is encountered inside a HTML document, the parser could make one additional check: does this attribute have a xmlns attribute defined? If so, it can enter a consume foreign markup stage whereby these elements are simply placed into the resulting DOM. Such elements would therefore be made available to processors like JavaScript, which could enable some cool applications. [snip] Finally (whew!) unlike Microsoft's mis-advertised and undocumented XML data islands, theis architected HTML extension sytax would clearly and unabashedly be parsed by HTML5 parser rules for things like comments and attributes. [snip] An HTML parser relies on knowledge of the schema, so it's not easy to parse an arbitrary, unknown schema with an HTML parser. For example, HTML offers no syntactic way to differentiate between void elements like br and normal elements like div. The parser just knows that BR is void. Likewise, the content model of the script element is hardcoded into the parser; there's no way to discover it from the syntax alone. (I'll admit that there's no similar construct to the content model of script in XML, however, so this particular difference doesn't pose a problem.) In order to handle custom elements in HTML while still allowing them to appear in the DOM, you'd have to make some rules such as that no void elements are allowed. You'd have to write otherwise-void elements as, say, img/img in order to have them handled correctly by the parser. Even if you aren't constructing a DOM of these unknown elements, you need to be able to count opens and closes so that you can detect the end of the root custom element and resume normal parsing. Standard browsers would be advised to ignore extensions that they don't understand. Including any text, so we don't have a repeat of the table problem again. I'm sure you realise this, but there are already browsers out there that *don't* ignore extensions that they don't understand, so a mandate such as this would be meaningless.
Re: [whatwg] HTML5 Edit Link Relation (was: PaceEntryMediatype)
Robert Sayre wrote: link rel=edit type=application/atom+xml href=entry.xml / While type is useful for things which result in GET requests, while specifying several locally-relevant protocols I've run into the fact that it's not so hot for anything that requires the client to include an entity body in the request, or requires any other request protocol. What would be useful, though perhaps out of scope for HTML5, is a way to specify a *protocol*, rather than a response type, for a given link relation. Then you could specify that this is an AtomAPI endpoint, rather than that a GET request will return an atom+xml document.
Re: [whatwg] HTML syntax: shortcuts for 'id' and 'class' attributes
Andrew Fedoniouk wrote: | | p.myclass.../p is equivalent of | p class=myclass.../p | | | HTML5 is meant to be backwards compatible, so this is out of the question. And where do you see problems with backward compatibility? Or let's put this way: what would be a definition of backward compatibility in terms of HTML5? Anything specified in HTML5 must degrade gracefully in pre-HTML5 software. Unless at the very least current browsers parse p.myclass as p this proposal is unworkable under this constraint.
Re: [whatwg] Still beating the drawString() dead horse...
Stefan Haustein wrote: Hi, I have tried to sum up the requirements for CanvasRenderingContext2D.drawString() at http://rhino-canvas.sf.net/www/drawstring.html The page contains an API proposal based on the Font/TextStyle object approach that meets all those requirements, and also some motivation why I have implemented this approach and not one of the alternatives discussed here. Some comments: void drawString(in float x, in float y, in DOMString text); ... attribute DOMString verticalAlign; attribute DOMString textAlign; I'm guessing from the function signature that what is actually changing here is how the coordinates (x,y) relate to the rendered text. a textAlign of right will presumably cause the text to be drawn with the rightmost edge at x. However, it'd also be useful to be able to render formatted blocks of text, like this: void drawString(in float x1, in float y1, in float x2, in float y2, in DOMString text) ...which wrap text and would make a textAlign of justify meaningful. Suddenly a bunch more CSS properties become attractive (margins and letter spacing, for example) but I think line-height alone would do for now. Rendering formatted blocks of text seems to me to be such a common thing that the canvas API should support it natively. This does, of course, require more functions on TextStyle to measure the extent of a block of text. This could probably be confined to just the following: float getBlockHeight(in DOMString s, float width) I think that a good use-case for this would be replacing regular document elements with canvases, either using bare script or using XBL. You point out in your document that drawElement(e) is tricky, but for limited cases it would be nice to be able to obtain the computed style of the canvas element to use for rendering, so that the text can match the style of the surrounding document. This can be as simple as one method on the canvas context to fetch the computed style, which would presumably return null in a non-browser implementation of the API. CanvasTextStyle getInheritedStyle(); For example, this could be used to create some kind of visual effect (fancy headings?) or to render a graphical element from some XML namespace that isn't supported in browsers yet.
Re: [whatwg] Still beating the drawString() dead horse...
Stefan Haustein wrote: Everything beyond is a separate use case that should be discussed separately. I think the main problem here is that drawElement() was suggested as a kind of replacement for drawString(), but it is actually something completely different, that should be discussed separately. I agree. It would be nice to have both. In the worst case, browsers can implement drawString in terms of drawElement if having both is a concern to developers.
Re: [whatwg] Scoped tabindex proposal
Simon Pieters wrote: So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. The table might not be focusable, but it needs to be in the tab order in some sense in order to resolve that local tabindex=1 into a global tabindex. For example: a id=outside1 href=... tabindex=1.../a div tabindex=scoped id=container1 a id=inside1 href=... tabindex=1.../a /div div tabindex=scoped id=container2 a id=inside2 href=... tabindex=1.../a /div a id=outside2 href=... tabindex=2.../a What is the global tab order now? I could see arguments for either: #outside1 #inside1 #inside2 #outside2 (DOM order) or... #outside1 #outside2 #inside1 #inside2 (all of the explicit tabindexes first in index order, followed by everything else in DOM order) Now what if I want the elements of #container2 to be before those of #container1 in the tab order? Can I also give these DIVs a tabindex?
Re: [whatwg] Scoped tabindex proposal
Simon Pieters wrote: Then it would be better to drop the tabindex=scoped idea and instead define that any tabindex element is a scoping element, so you would use tabindex=1 on #container2 and tabindex=2 on #container1. I think this makes more sense than changing tabIndex to a DOMString, and it is more flexible. And, I guess, tabindex=0 would be roughly equivalent to your tabindex=scoped. Seems reasonable to me.
Re: [whatwg] Mathematics on HTML5
[originally sent privately by mistake; sorry Ian.] Ian Hickson wrote: On Wed, 7 Jun 2006, Mihai Sucan wrote: Yes, it's true authors don't generally jump on whatever comes new (that's the reason MathML is not as widely used as LaTeX). I would say MathML is not widely used because MathML doesn't work in HTML, personally. If we made MathML work in HTML, possibly with rules that make the syntax easier (by implying tags as I suggested earlier), then that might well change, especially given that one UA already has extensive and high-quality support for MathML. It seems to me that a good path would be to fix up CSS's shortcomings (which have been discussed at length in this thread) so that it is possible to specify math rendering with CSS. Then MathML only have to be implemented once as a CSS stylesheet and then that stylesheet could be shipped with all browsers or even just served alongside the content so it'd work for everyone. (browser incompatibilities notwithstanding) As a bonus, the fixes to CSS would probably end up being useful in a lot of other scenarios too. I agree that it'd be worthwhile to do tag implication though, which admittedly is not an option if MathML support is just a stylesheet.
Re: [whatwg] drawString?
Lars Schöning wrote: May I suggest the addition of a drawString method with parameters for font type, size and string. In order to achieve usability canvas really requires an equivalent prototype method, however the established prototype functions take immense amounts of clocktime and significantly (and unnessessarily) slow down the canvas. The current lack of standard in canvas makes it possible to include a drawString method before it is too late, thus adding new possibilities to the object. You can't really implement drawString as a single call, since there's no guarantee that the font you requested will be available so you need to be ready to deal with that eventuality. A process which might work is: * Make a request to prepare some text with an ordered list of preferred fonts, CSS-style. * Get back some kind of descriptor which allows you to discover various characteristics of the dimensions of the text as it will be rendered. * At some later point, ask the canvas to draw the descriptor at a given location. This allows for the browser to substitute other fonts while allowing the canvas-based app to adapt the display to the characteristics of the selected font.
[whatwg] Objects in external security contexts
Hi folks. I'm new here on the mailing list, but I've been following
progress with the various WHATWG specs for a while now.
The following proposal doesn't really have any relationship to any
particular specification currently being considered by WHATWG, but after
much consideration I decided that this was the best forum to propose it,
since it is certainly related to web applications.
My proposal is to allow client-side scripts to do something like this:
window.instantiateRemoteObject(
http://www.othersite.com/script;,
function (obj) {
// Do something with obj here
}
)
The idea here is that some script object gets instantiated based on the
code at that URL. The code is retrieved asynchronously and, once it has
been retrieved and compiled, passed into the callback function provided
in the form of an object.
The key thing here is that the remote object's code runs in the security
context of the remote site, not the calling site. The site which owns
the object has no direct access to the calling site's DOM. The calling
site has access only to the methods and properties explicitly exposed by
the remote site.
This allows two sites to exchange data client-side while ensuring that
each party can only access what the other party wishes to share.
The use-case that immediately springs to mind is Google's text ads.
Currently sites embed Google's ads by simply referencing a script file
on Google's server. This script then runs in the calling site's security
context, which gives Google complete access to the calling document's
DOM. This also means that Google mandates the presentation of the ads,
rather than the embedding site. Finally, it requires that parameters be
passed as global variables, which isn't very clean.
A better way, perhaps:
window.instantiateRemoteObject(
http://www.googlesyndication.com/pagead;,
function (adManager) {
var adbox = document.getElementById(adbox);
var adlist = adManager.getAdverts();
// Generate some stuff inside the adbox element
},
{
clientid: 4534523465243564,
channel: cheese
}
);
(the third parameter here is an arbitrary parameter to be passed to the
object somehow. Here I've used a JavaScript object containing some named
parameters.)
(NB. I'm ignoring the fact that Google probably *wants* to control the
presentation here; feel free to think of other use-cases where the
mighty buck isn't involved and people are just sharing data for its own
sake.)
It's also possible that certain de-facto standard interfaces would
emerge for doing a particular job, which several sites could then
implement and inter-operate with one another.
The important characteristics are:
* The remote object runs in its own global scope and can't do anything
at all to the DOM or other objects in the caller unless the caller
explicitly passes data to one of the methods or properties of the object.
* Likewise, the caller can't access anything in the remote object's
scope unless it's explicitly returned from a property or method of the
object. (This implies that the remote object can use private
functions/data by simply creating global variables in its own scope)
* The remote object can do anything that would normally be allowed of a
page on the remote site, such as use XMLHttpRequest to call back to its
own domain to fetch data.
* Each party makes data available explicitly. Nothing is available by
default.
A few details remain to be worked out:
* What should happen if the remote script cannot be retrieved, or can't
be executed for some other reason? The caller needs to be informed of
this case somehow.
* The specifics of how this remote object is described and how it is
instantiated remain to be seen. I'm open to suggestions.
This could be very useful when used in conjunction with XBL. For
example, imagine an XBL-powered news ticker that gets its news from an
exposed object on another site, which might itself fetch the news from
an RSS feed using XMLHttpRequest. Of course, the calling site doesn't
need to care where the data comes from as long as the API stays consistant.
In fact, I'd probably be inclined to use such a thing even with scripts
that live on the same site, since it keeps the code compartmentalised
nicely and avoids filling the global scope with loads of junk.
Comments, suggestions and other thoughts are welcome.
Cheers,
-Martin
