Re: [whatwg] Spec comments, sections 3.1-4.7
On Sun, 16 Aug 2009, Aryeh Gregor wrote: 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? Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. 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. I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? 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. People use forms now, still, despite this situation having changed. -- 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 Thu, Aug 27, 2009 at 7:48 PM, Ian Hicksoni...@hixie.ch wrote: Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. That seems very speculative. Does any UA actually do anything like this, with links or anything else? I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? No, I just thought this particular requirement should be should instead of must. Or should be dropped entirely, since it seems very vague to me and I'm not clear what real-world scenario it addresses. But it doesn't really matter and isn't worth spending time arguing over if you don't agree.
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, 27 Aug 2009, Aryeh Gregor wrote: On Thu, Aug 27, 2009 at 7:48 PM, Ian Hicksoni...@hixie.ch wrote: Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. That seems very speculative. Does any UA actually do anything like this, with links or anything else? Opera has a UI to show a list of links. But even if nobody had any UI like this, I'm not sure it really matters. The point is that the type= attribute is to be considered authoritative until the server can provide the real type. I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? No, I just thought this particular requirement should be should instead of must. I don't see what reason a tool would have to ignore this requirement. The one requirement that might be ignored (namely, not downloading the resource if the type isn't supported) _is_ a should. Or should be dropped entirely, since it seems very vague to me and I'm not clear what real-world scenario it addresses. Without it, I don't really see what the type= attribute would do. -- 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] 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] Spec comments, sections 3.1-4.7
Tab Atkins Jr. writes: On Wed, Aug 12, 2009 at 7:43 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: I haven't noticed many progress bars on the web You see them a lot more in the indeterminate form, as a 'spinner' image or the like. ... I suspect, though, that there are a lot of places you currently don't see a progress bar solely because it's a bit of a pain to do. Many shopping sites have indicators of how far you are through the buying process (Step 2 of 4), and online surveys often have progress bars indicating the position in the survey. Typically these are static to the page (as in, making progress and seeing the indicator move involves submitting a form and displaying the next page in the sequence), but so far as I can see from the spec progress can be used in these situations; it isn't restricted to use on a single page where it is updated dynamically. Smylers
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, 13 Aug 2009 19:34:47 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: I'd think that the author in this use-case is not likely to be happy using an unstyle-able progress element and getting some kind of unknown appearance that might clash with their color scheme or such. You seem to base most of your argument on that progress will not be stylable. I think the idea is that it will be stylable though. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, Aug 13, 2009 at 4:00 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Thu, Aug 13, 2009 at 2:11 PM, Anne van Kesterenann...@opera.com wrote: You seem to base most of your argument on that progress will not be stylable. I think the idea is that it will be stylable though. Yes, I guess I got sort of sidetracked. I assume the idea is that it will be styleable eventually, but I don't see how it would work with existing CSS properties, so I'd assume it would take significant implementation effort and not happen very soon. I don't think it will be used very widely or usefully until it becomes styleable. Beyond that, the use-cases just seem very narrow compared to other elements invented in HTML 5. The number of progress bars needed on the web is pretty modest, and the gains from marking them up semantically don't seem to be large. For some particular types of progress bars, progress gives better accessibility than any straightforward existing possibility I can think of, but a) authors concerned about accessibility could usually add some kind of text without any trouble, and b) the progress of some activity is rarely critical information in web apps, so if you're missing it you usually won't be missing much anyway. Well, it's a default widget in jQuery UI. I think that makes a good case for it being common enough that it'll see use. (For reference, the other default widgets are a datepicker and slider, which are new input types, a styleable dialog box, and then accordion and tab displays (which were hit by some proposals between Brad Kemper and I on the CSS list a while back).) ~TJ
Re: [whatwg] Spec comments, sections 3.1-4.7
On Sun, 2 Aug 2009, Aryeh Gregor wrote: First, a general remark: what's the difference supposed to be between PASS and BUG? Firefox and WebKit are listed as PASS and BUG in these two cases respectively, for instance: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactions-with-xpath-and-xslt http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#controlling-the-input-stream The descriptions just say passes all the available test cases for this feature, and has nearly complete support for this feature, but does not yet pass all the relevant test cases. But in both cases, it says Tests: 0. I guess this is an error in the XPath/XSLT section, since all the other parts with no tests list browsers as BUG rather than PASS? Currently they're all just judgement calls currently; there aren't any tests listed for most features. Feel free to change the annotations if you feel they are wrong (alt+double-click a section to edit it's marker). In 3.2.3: This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an httponly parameter added to the cookie string causes the cookie to be hidden from script. Why doesn't the spec define them? Cookies are out of scope of the HTML5 spec. This is being discussed in the http-state mailing list. In 3.4.1.7: When a pointing device is clicked, the user agent must run these steps: 1. Let e be the nearest activatable element of the element designated by the user, if any. 2. If there is an element e, run pre-click activation steps on it. 3. Dispatching the required click event. . . . The third item's grammar doesn't match the first two. Probably it should be Dispatch instead of Dispatching. Fixed. In 3.5: I'm not certain what the point of 3.5 is. What agents are supposed to keep track of paragraph boundaries, and what are they supposed to do with them? They don't affect the DOM or rendering as far as I can tell; what do they affect? Should browsers care about them? Conformance checkers? What should authors be aware of, other than not straddling elements across paragraph boundaries? (And why should they care about that? That's not clearly explained either.) This section is just defining the semantics of text that is directly in flow elements other than p elements. It's only really theoretically useful for people doing semantic processing of HTML documents. In practice it's useful for people who have debates about what HTML documents mean. In 4.2.3: If there are multiple base elements with href attributes, all but the first are ignored. If there are multiple base elements with target attributes, all but the first are ignored. Why are these notes, and not normative? Do they duplicate normative requirements elsewhere? Yes. 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. In 4.6.1: suports - supports Fixed. 4.6.11 and 4.6.12: Most new elements in HTML 5 either add clear functionality (e.g., video) or provide convenient styling hooks (e.g., article). progress and meter seem to do neither. What's the point of these elements, from an author's perspective? Or even from anyone's perspective? What use cases do they fulfill? 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. In particular, it seems like authors would be reluctant to use progress and meter if they couldn't style them. I don't think there's any obvious way to really control the styling of these controls with CSS, so authors would be stuck with whatever color scheme and general feel the UA happens to support. That seems like it would look ugly compared to manually-constructed elements that serve the same purpose. 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
Re: [whatwg] Spec comments, sections 3.1-4.7
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? 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. Like IE7 Compatibility Mode, say. This is prohibited by the standard and does make the user agent non-conformant in that respect, but it's not useful to add a generic clause to the standard saying you can ignore everything if you really have to to handle this case. That's implicit in the fact that the standard isn't mandated by law or whatever. So I withdraw the suggestion. 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. 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.) 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. It's really unlikely that you'd need such excruciating precision in the markup here. It's pretty ugly, and violates the general principle that if your markup isn't easily readable in a text editor, you're using too much of it. Actually, in real life I think the best recommendation would be to just not use kbd or samp at all, and use code or something instead unless there's some special reason you want to distinguish user input from other types of code, like style (in which case kbd or samp would be more convenient than using a class). I'm guessing that these elements are only present in the standard because they were in previous versions of HTML and there's no good reason to actively remove them? They strike me as drastically less useful than many other tags that would be rejected for having an insufficient use-case. Are F-sigma and G-delta variables? Well, strictly speaking I guess they're constants, if you want to make
[whatwg] Spec comments, sections 3.1-4.7
First, a general remark: what's the difference supposed to be between PASS and BUG? Firefox and WebKit are listed as PASS and BUG in these two cases respectively, for instance: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactions-with-xpath-and-xslt http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#controlling-the-input-stream The descriptions just say passes all the available test cases for this feature, and has nearly complete support for this feature, but does not yet pass all the relevant test cases. But in both cases, it says Tests: 0. I guess this is an error in the XPath/XSLT section, since all the other parts with no tests list browsers as BUG rather than PASS? In 3.2.3: This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an httponly parameter added to the cookie string causes the cookie to be hidden from script. Why doesn't the spec define them? In 3.4.1.7: When a pointing device is clicked, the user agent must run these steps: 1. Let e be the nearest activatable element of the element designated by the user, if any. 2. If there is an element e, run pre-click activation steps on it. 3. Dispatching the required click event. . . . The third item's grammar doesn't match the first two. Probably it should be Dispatch instead of Dispatching. In 3.5: I'm not certain what the point of 3.5 is. What agents are supposed to keep track of paragraph boundaries, and what are they supposed to do with them? They don't affect the DOM or rendering as far as I can tell; what do they affect? Should browsers care about them? Conformance checkers? What should authors be aware of, other than not straddling elements across paragraph boundaries? (And why should they care about that? That's not clearly explained either.) In 4.2.3: If there are multiple base elements with href attributes, all but the first are ignored. If there are multiple base elements with target attributes, all but the first are ignored. Why are these notes, and not normative? Do they duplicate normative requirements elsewhere? 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. In 4.6.1: suports - supports 4.6.11 and 4.6.12: Most new elements in HTML 5 either add clear functionality (e.g., video) or provide convenient styling hooks (e.g., article). progress and meter seem to do neither. What's the point of these elements, from an author's perspective? Or even from anyone's perspective? What use cases do they fulfill? In particular, it seems like authors would be reluctant to use progress and meter if they couldn't style them. I don't think there's any obvious way to really control the styling of these controls with CSS, so authors would be stuck with whatever color scheme and general feel the UA happens to support. That seems like it would look ugly compared to manually-constructed elements that serve the same purpose. 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. In 4.6.17: When the sub element is used inside a var element, it represents the subscript that identifies the variable in a family of variables. While this is often what subscripts are used for in variable names, it doesn't have to be. For instance, F_\sigma and G_\delta are used in real analysis to refer to a countable union of closed sets and a countable intersection of open sets, respectively. \sigma and \delta here denote somme and Durchschnitt respectively, and don't serve as identifiers in a family of variables in any meaningful sense: they represent the operation of taking countable unions/intersections. This statement should either be removed, or weakened (usually or such) and made informative. In 4.6.26: I don't think it's a good idea to recommend the use of the title attribute for annotations or footnotes. User agents do not normally provide any visual cue if a title attribute is present, to the best of my knowledge, except on abbr elements. Even if some cue is provided, it's unlikely that many users will actually recognize the cue as a suggestion to hover over the element. The large majority of users probably won't realize there's a tooltip. IMO, tooltips should never be used to provide information that's not
