Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
On Wed, 12 Aug 2009, Sebastian Markb�ge wrote: The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. The spec requires them to all be set on all drag events, currently. I thought that this was clear too but apparently it's not clear that they should be set to something useful: https://bugzilla.mozilla.org/show_bug.cgi?id=505521 The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. I've added more text to clarify what it means in the case of the mouse not being used. Apparently it also needs to be clear that the properties SHOULD be set, if a pointing device IS being used. See above conversion on the Mozilla bug. I'd suggest you add something like If there is a relevant pointing device, the attributes should be set to relevant position values for all events in the sequence. - So that the intention is clear and don't have to rely on implicit interpretation. The spec says, of all DND events: the event [...] must have the context information set up [...] with [...] the mouse and key attributes set according to the state of the input devices as they would be for user interaction events. What more can I add? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, sections 3.1-4.7
On Wed, 12 Aug 2009, Aryeh Gregor wrote: On Wed, Aug 12, 2009 at 3:08 AM, Ian Hicksoni...@hixie.ch wrote: In 4.2.4: If the attribute is present, then the user agent must assume that the resource is of the given type. If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. Why must and not should? Perhaps the user agent has some good reason to think the attribute is wrong. Because otherwise we don't get interoperable behaviour. That kind of reasoning is how we ended up with the crazy content sniffing behaviour we have now, with its assorted security issues. Consider a search engine that can only index certain types of content. If a type attribute is provided on a link, and the type indicates a non-supported type of content, the search engine would be required to assume that the resource is not supported. So say it does this, but a major site emits incorrect type attributes for some links. The authors of the search engine spider become aware of this and are unable to persuade the authors of the site to change their markup. Should they have to still refrain from following the incorrectly marked-up links? They can follow the links (not following the links is a should not, not a must not). Once they follow the links, they must ignore the type= attribute and only take into account the MIME type provided by the server. Well, I guess I can answer my own question. If authors produce markup that's invalid, such that a user agent that followed the standard would not be able to process the markup correctly, and those authors are important enough that the implementers of the user agent can't afford to process their markup incorrectly, then the implementers would reasonably be expected to willfully violate the standard as much as is strictly necessary to serve their purposes. For Web browsers, this problem only occurs if at least one major browser violates the spec. Until one does, the browsers can just refuse to render the site -- since all the browsers will be doing the same thing, the site cannot legitimately blame the browers. The problem is that this is like the prisoner's dilemma -- as soon as one of the browsers break the rules and does something DWIMmy like this, we enter a spiral of despair where they have to reverse-engineer each other to make things work. This is how we ended up in this crazy state with MIMESNIFF and so on in the first place. The point of progress is to add progress bars. Right now people hack them in highly non-accessible ways using images and all kinds of crazy things. This lets them avoid that while also getting a platform-native look and feel. The point of meter is to make sure people don't abuse progress for showing meters. I see. I guess if you're using a screen reader or have images disabled, loading bars in some web apps would be completely absent. I haven't noticed many progress bars on the web, but I guess if I used web apps other than Gmail more then maybe I'd see the need for this better. Progress bars are starting to appear all over the place. Flash games have them all the time, for instance. They're an intrinsic part of Web applications, which were the original problem space of HTML5. Yeah, styling of complex widgets like progress bars and other widgets is somewhat dependent on us deploying a technology like XBL2. This is something that we need to resolve in general. Once we have more implementation experience, I expect we'll add some pseudo-elements and define how the CSS model applies. Hmm, okay. I don't think pretty much anyone will be using these elements until something like this is in place, though. And possibly not after that if it's not easy enough to use. (I notice Gmail doesn't appear to even use form buttons. Inspecting the Send button on this page shows a stack of several nested divs with various obscure classes and styles applied. And, indeed, it seems like that's so they could change the appearance.) Indeed. XBL2 would be a neat way of addressing this. If anyone has any other ideas, now would be a good time to suggest them. In 4.6.16: pTo make George eat an apple, select kbdkbdsampFile/samp/kbd|kbdsampEat Apple.../samp/kbd/kbd /p That seems excessively baroque. While it's a matter of taste, I guess, I think it would be better if the spec didn't go out of its way to encourage markup that's so excessively nested and unreadable for no apparent purpose. This is again basically aimed at the pedants who like to argue about exactly how to mark up particular semantics. You'd be amazed how often I'm asked how to mark up that kind of thing. I think that kbdFile | Eat Apple.../kbd or sampFile | Eat Apple.../samp would be a better recommendation in this case. I've added a
Re: [whatwg] the cite element
On Wed, 12 Aug 2009, Erik Vorhes wrote: On Wed, Aug 12, 2009 at 6:21 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 3 Aug 2009, Erik Vorhes wrote: On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote: Not all titles are citations, actually. For example, I've heard of the /Pirates of Penzance/, but I'm not citing it, just mentioning it in passing. No, that actually is a citation, whether you realize it or not. You are making reference to a musical and are therefore citing it, even in passing. Your definition of citation is far looser than my dictionary's (a quotation from or reference to). In fact your definition seems to be basically the same as HTML5's -- a title of a work. Unless you think that this should be valid use of cite: � pI picked up citemy favourite book/cite, and put it next to � citethe painting I got from my aunt/cite./p I don't think that those references to works should use cite. Doing so has zero benefit, as far as I can tell. No, No, NO. That is not what I mean at all. You again deliberately misrepresent what I am trying to convey, that cite should be for citations, not for a subset of citations. I'm really not deliberately misrepresenting anything, I'm trying to work out what you mean. It appears you are using the word citation in a different way than I am. I understand it to only mean mentions that make some reference to the contents of the source, such that mentioning something in passing is not a citation, but quoting from a source, or referencing statements made in that source, is a citation. I agree that if you think that citation means any arbitrary reference, whether in passing or otherwise, then HTML4's cite would be applicable in the cases you are suggesting. However, then the question is whether you think that cite should be applicable for the entire reference, or just the name of the source. In the former case (which appears to be what Wikipedia's templates are doing), I don't see why I picked up citemy favourite book/cite would be non-conforming. If we define HTML4's cite as being any arbitrary reference or mention to a source, but limiting it to only the name of the source, then as far as I can tell this is equivalent to saying it is for titles of works, which is HTML5's definition, except possibly if you argue that sources include people, in which case HTML4 is a superset of HTML5's definition. However, this is not my interpretation of what HTML4 says, and thus I find what HTML4 says to be a subset of what HTML5 says. I agree (and never suggested otherwise): those are in no way explicit citations, as there is nothing specific about them that would justify calling them citations. citePirates of Penzance/cite, however is an explicit reference to that work and therefore a citation, not just a title of the work. With the definition of citation that covers any arbitrary reference or mention, I don't see what the difference is between a citation and a title of a work. Why not? An orchestral arrangement is a work, and has a title -- the spec explicitly lists score, song, and opera as possible works, for instance. I've added legal case report to the list, to clarify that you can use cite to name such reports. So the definition of cite in HTML5 should currently be title of work or something that could be construed as a title where one doesn't exist in the explicit sense of 'title.' As far as I can tell, legal case reports do have titles, and those are what is being marked up here. But not people's names, even if they're the citation, because using cite for citations is silly. That's not the reason, no. The reason to avoid using it for people's names is that people's names are not usually typographically offset in the same way as titles, and that few people use the element in this way today, leading me to conclude that this is not a use case with enough support to warrant the element being defined in a way that includes people. We already have a number of other ways of marking up people's names, including the quite fine-grained vCard microdata vocabulary. For example, the following is valid HTML5 but wouldn't be valid HTML4, since it's not a citation or reference to another source, but merely something mentioned in passing: � pToday, as I was moving my copy of citeDreamer's Void/cite, I � hurt my back./p That's perfectly fine in HTML4. It's a citation, as I have explained previously, and there's nothing in the HTML4 spec that prohibits that use. Why are you misrepresenting the HTML4 spec? Your interpretation and mine differ. As far as I can tell, the above isn't a citation. Out of curiosity, would you consider the names in the following text to be citations? pToday I went to Mike's apartment and saw Shyam./p Would you say the following is a conforming use of cite in HTML4?: pToday I went to citeMike/cite's
Re: [whatwg] Remove addCueRange/removeCueRanges
On Thu, 13 Aug 2009, Philip Jägenstedt wrote: We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. I've commented out the cue range feature. On Thu, 13 Aug 2009, Dr. Markus Walther wrote: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) Just my 2c. There's not going to be a way to do subrange selection in this version of the API. It'll be one of the first things to come back, I expect. As was pointed out, there are many notes in the spec source of things to bring to the next version of the spec. If anyone wants to maintain an off-spec copy of these annotations, please feel free to do so. On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: I am actually hoping that we could attach callbacks to time-aligned text segments which makes the whole approach to cue ranges more generic. Hopefully I will have a demo of this within the next few weeks, so we can discuss further. I don't really think we want to tie callbacks of this nature to text -- in fact, the two are likely to be almost mutally exclusive features: you would need callbacks when you're not using timed text solutions, so that you can do your own. Another example would be keeping a slide show in sync with an audio track, where each slide has a cue range -- this has nothing to do with text tracks, and you wouldn't want to have to generate a fake text track file just to get the hooks to do this when all your data about slide timings is in script already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, sections 3.1-4.7
On Sun, Aug 16, 2009 at 6:52 AM, Ian Hicksoni...@hixie.ch wrote: They can follow the links (not following the links is a should not, not a must not). Once they follow the links, they must ignore the type= attribute and only take into account the MIME type provided by the server. I was assuming that they don't want to follow unnecessary links. For instance, their spiders can likely only make X requests per second to each domain (due to robots.txt or generic don't be a jerk policies), and if the spiders are forced to make a large number of useless requests then their indexing of any given site will be slowed down. I'm not clear on what it means that you must assume something, actually. An assumption, by definition, might be discarded at any point if more evidence comes in, so a required assumption sounds oxymoronic. Anyway, assumption is a state of knowledge rather than an actual action, so I can't figure out what the requirement means in practice. At this point the user agent seems to have only one choice to make: fetch the resource, or don't. Whether to fetch the resource is, as you point out, explicitly a should requirement. So what's the must assume requirement meant to add? Are there other decisions the user agent has to make before it has the resource available? For Web browsers, this problem only occurs if at least one major browser violates the spec. Until one does, the browsers can just refuse to render the site -- since all the browsers will be doing the same thing, the site cannot legitimately blame the browers. Unless the problem is non-obvious to authors but significant to some consumers (but not enough to make authors widely aware of it). My hypothetical scenario had authors providing an incorrect type= attribute. Perhaps all browsers supported both types anyway, so they retrieved the resource thinking it was type X, then determined it was type Y and processed it as that with no errors being raised. But then if one browser (or search engine, etc.) happens to support type Y but not type X, you get bugs. Another example that I think you yourself have mentioned in the past is Opera's mobile version. It deliberately mangles display in a nonstandard fashion to better fit on a small screen. Again, here the problem isn't obvious to most authors (since they didn't test on small screens), but the implementor is able to improve experience for a significant market of consumers if they ignore the standards. Probably a little (forms have been pretty successful despite a horrible styling story for over a decade) Because it's impossible to achieve the same functionality as forms -- dynamically building a GET request based on user input, or any POST request at all -- any other way without requiring JavaScript. (Which locks out some users, and is harder to write.) And until a few years ago, when XHR became widely supported, AFAIK it wasn't possible to permit POSTs (necessary for large amounts of input, for instance) even with JavaScript.
Re: [whatwg] the cite element
On 16/08/2009 12:21, Ian Hickson wrote: Italics is the right format for almost all titles of works. How are you measuring that? For example, chapters in collections and articles are works and have titles, and those titles aren't typically distinguished with italics, at least in English. Titles of works are commonly distinguished from surrounding text and italics is a common format for many titles of works would statements that would be hard to argue with. -- Benjamin Hawkes-Lewis
Re: [whatwg] SharedWorkers and the name parameter
That suggestion has also been floating around in some internal discussions. I'd have to objections to this approach either, although I'm not familiar enough with URL semantics to know if this is a valid use of URL fragments. -atw On Sat, Aug 15, 2009 at 5:29 PM, Jim Jewett jimjjew...@gmail.com wrote: Currently, SharedWorkers accept both a url parameter and a name parameter - the purpose is to let pages run multiple SharedWorkers using the same script resource without having to load separate resources from the server. [ request that name be scoped to the URL, rather than the entire origin, because not all parts of example.com can easily co-ordinate.] Would there be a problem with using URL fragments to distinguish the workers? Instead of: new SharedWorker(url.js, name); Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); The normal semantics of fragments should prevent the repeated server fetch. -jJ
Re: [whatwg] SharedWorkers and the name parameter
Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. I agree with you that this is a problem, and the same problem exists in WebStorage (storage areas are set up per origin). F ex, the sites http://www.google.com/calendar and http://www.google.com/reader, and every other site based off www.google.com will compete for the same keys in one big shared storage area. It seems lately everything is being based on having unique host names, and path is not being considered anymore, which I think it should. An alternative model would be to follow what cookies do with cookie.path, to allow the application itself decide on what URL should be used as the namespace root. Allowed values would be in the range from the bare host name (~origin) up to the file URL (per your suggestion). (Then if even Document.domain could be enhanced with something to allow subsetting on path it'd be great. But that has probably been discussed to death a long time ago ;-) Best regards Mike Wilson
Re: [whatwg] SharedWorkers and the name parameter
Tim Berners-Lee seems to think this could be a valid use of URI references. http://www.w3.org/DesignIssues/Fragment.htmlThe significance of the fragment identifier is a function of the MIME type of the object Are there any existing semantics defined for fragments on text/java-script objects? // the semantics we're discussing, the naming of a instance loaded script #name=foo // hand wavings at other semantics that could make sense, references to particular items defined in the script #function/global-function-name #var/global-var-name I'd have to objections to thisDid you mean to say i'd have no objectsion to this? On Sun, Aug 16, 2009 at 8:27 AM, Drew Wilson atwil...@google.com wrote: That suggestion has also been floating around in some internal discussions. I'd have to objections to this approach either, although I'm not familiar enough with URL semantics to know if this is a valid use of URL fragments. -atw On Sat, Aug 15, 2009 at 5:29 PM, Jim Jewett jimjjew...@gmail.com wrote: Currently, SharedWorkers accept both a url parameter and a name parameter - the purpose is to let pages run multiple SharedWorkers using the same script resource without having to load separate resources from the server. [ request that name be scoped to the URL, rather than the entire origin, because not all parts of example.com can easily co-ordinate.] Would there be a problem with using URL fragments to distinguish the workers? Instead of: new SharedWorker(url.js, name); Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); The normal semantics of fragments should prevent the repeated server fetch. -jJ
Re: [whatwg] SharedWorkers and the name parameter
On Sun, Aug 16, 2009 at 12:51 PM, Michael Nordman micha...@google.comwrote: I'd have to objections to this Did you mean to say i'd have no objectsion to this? Yes, I have *no* objections to either approach. Apparently the coffee hadn't quite hit my fingers yet. -atw
[whatwg] SharedWorkers and the name parameter
... Additionally, a typo in one page (i.e. invoking SharedWorker(mypagescript?, name) instead of SharedWorker(mypagescript, name) will keep all subsequent pages in that domain from loading a worker under that name so long as the original page resides in the page cache. In this case, if typo one is invoked after a correct one, an URL_MISMATCH_ERR will be thrown in SharedWorker constructor algorithm step 5.4.2. In the other hand, a 404 will terminate the algorithm and no SharedWorker is created and nothing will be add to global namespace. I think this example won't be a serious problem anyway, though I'm not sure will this cause other problem or not. Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); This remind me of something: From sec4.8.3, SharedWorker constructor algorithm step 5.4.2: If worker global scope's location attribute represents an absolute URL that is not *exactly equal* to the resulting absolute URL, then throw a URL_MISMATCH_ERR exception and abort all these steps. Seems the #name part will break this line and throw a URL_MISMATCH_ERR with the duplicated #name2 one. Shall we ignore minor difference between urls? e.g # fragments?
