Re: [whatwg] Seeing the open issues
Ian Hickson skrev: In response to the concerns over the lack of transparency that have recently been expressed both in these mailing lists and on blog posts, I have written a tool that exposes the issues I have on my list: http://www.whatwg.org/issues/ I was going to vote for the headers and axis attributes on table cells, but they were not on the list at all. Considering the really strong uproar against HTML 5 from accessibility experts that this issue has caused, I found it surprising to see they were not even considered an issue. Lars Gunther
Re: [whatwg] Color attributes
On Fri, 27 Jul 2007 13:07:26 +0200, Simon Pieters [EMAIL PROTECTED] wrote: On Thu, 05 Jul 2007 23:43:55 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Color attributes in HTML have special processing. Some tests/demos: http://simon.html5.org/test/html/parsing/color-attributes/ https://bugzilla.mozilla.org/attachment.cgi?id=188040 contains further tests and an algorithm that is supposed to match what IE does. The only flaw in that algorithm AFAICT is that there is a step missing before the first step: match the value against the list of supported color keywords. For reference, the complete algorithm would be: 1. If the value case-insensitively matches a color keyword, use that and abort these steps. [CSS3COLOR] ASCII-case-insensitively, even. transparent is also to be treated as a keyword, meaning transparent. (It seems that IE treats transparent as black for text color, but that's a CSS thing.) 2. Trim all but the first 128 chars from the string. 3. If it exists, strip the first leading #. 4. Replace non-valid-hex chars with 0s. 5. Lower-case the string. ASCII-lower-case. 6. Make string length a multiple of 3 and a minimum of 3 by appending 0s. 7. Split the string into 3 equal segments. 8. Trim all but the right-most 8 chars from each segment. 9. If segment length is 1, left-pad each segment with a 0, else: 10. While segment length is greater than 2 and the first char of each segment is equal to 0, trim the left-most char from each segment, then: 11. Trim all but the first 2 chars from each segment. 12. Join the segments and append them to a # char to create the final string. Test cases for the algorithm: http://simon.html5.org/test/html/parsing/color-attributes/the-algorithm/ -- Simon Pieters
[whatwg] Answering the question...
Earlier today, Lachlan Hunt posed the following question [http://krijnhoetmer.nl/irc-logs/whatwg/20070823#l-271]: # [04:40] Lachy why do people keep overreacting and bringing up the headers issue all the time?! http://lists.w3.org/Archives/Public/public-html/2007Aug/0926.html # [05:15] Hixie headers= are allready counted by our editor as insignificant # [05:15] Hixie they are? i thought i'd not yet looked at them. ...and there you have it. Despite protracted discussion (argument?) and a formal submission from the WAI PF regarding the requirement of headers for complicated tables on June 6, 2007 [http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html], the official word from Ian Hickson is that they've not yet looked at them. What more needs to be looked at? Our community provided research, rationale and worked within the system (and the system's rules) in response to this issue, yet it is still deemed open or unresolved. It is *exactly* this kind of response/reaction that many such as myself are frustrated with. This issue should be resolved - now. Either headers as they are currently used are *in* the HTML 5 draft, or they are *out*. I challenge the editors to answer this very simple question - are you *really* listening to us, or are you simply smiling and nodding, and going back to your IRC channel to bash the accessibility advocates once again? Lachlan, the answer to your question is as clear as the nose on your face - we keep bringing up the same issues, because you guys keep ducking the hard answers. JF
Re: [whatwg] Answering the question... (timing of table headers issue)
On Thu, 2007-08-23 at 10:40 -0700, John Foliot wrote: [...] Despite protracted discussion (argument?) and a formal submission from the WAI PF regarding the requirement of headers for complicated tables on June 6, 2007 [http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html], the official word from Ian Hickson is that they've not yet looked at them. What more needs to be looked at? Our community provided research, rationale and worked within the system (and the system's rules) in response to this issue, yet it is still deemed open or unresolved. It is *exactly* this kind of response/reaction that many such as myself are frustrated with. This issue should be resolved - now. I sympathize with your frustration, but I ask that you remain patient. I am in regular communication with Al Gilman about that June 6 message. He understands that it may be some weeks/months before the HTML WG has a considered response. (I think I just missed you yesterday, Al.) The current priorities of this group, as noted in the Current Events section of our homepage http://www.w3.org/html/wg/#current 1. design principles 2. initial reviews of the HTML 5 spec These initial reviews are breadth-first; the goal is to raise issues and awareness, but not to fully address all the issues that come up, just yet. I tried putting something else ahead of design principles, namely a differences between HTML 4 and HTML 5 document, but there were formal objections that appealed to the What should the HTML WG publish first? survey http://www.w3.org/2002/09/wbs/40318/wd7/results which put the design principles ahead of the spec, 34 to 25. The back-log of comments on HTML specs goes back a lot further than June of this year. In May, the editors asked for a few months to deal with a backlog of a few years of WHATWG feedback. It has now been a few months, and I'm starting to re-negotiate priorities with the editors. But keep in mind that we have, so far, made *no* design decisions. We haven't decided that HTML 5 will have a p element. Before we address subtle issues like the table headers issue, first we should deal with the fact that we're about 3 months overdue for releasing anything on http://www.w3.org/TR/ for community review by finishing the current round of discussion on design principles. Then I think we should tackle a few no-brainer technical issues just to get a feel for the process. And then we'll decide about table headers and that sort of thing. I appreciate the testing and research that is going on meanwhile. That's an essential part of quality design decision-making. I recommend teleconferences as a good way to get a feel for group priorities and schedule. For example, we talked about the timing of this table headers issue last week. http://www.w3.org/2007/08/16-html-wg-minutes#item05 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Re: [whatwg] Answering the question... (timing of table headers issue)
Dan Connolly wrote: I sympathize with your frustration, but I ask that you remain patient. Dan, Thank you for your prompt response. While patience is indeed a virtue, my (our?) patience is being sorely tested, as while the official word is that we're nowhere near deciding anything, current editors and contributors are going ahead and making pronouncements that lead many to believe that much of HTML5 is 'fait accomplis'. As someone once said to me, you can't suck and blow at the same time. To whit: * Is Anne (Standards Suck) van Kesteren out of place to be announcing that HTML5 has dropped input usemap? [http://annevankesteren.nl/2007/08/input-usemap] * Is Lachlan Hunt definitive when stating, HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document. [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as HTML5 currently will not be including the usemap attribute on input elements. [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] * Is From Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] These types of pronouncements *do* tend to send mixed messages, don't you agree? If these authors/HTML 5 contributors can be categorically making these kinds of statements, then is it not unreasonable to expect something like, Based upon current feedback, the headers attribute will be preserved in HTML5 (attribute to whom you wish)? I know that these issues have been raised to you previously. If we are to accept that it is still at the ...*no* design decisions made... stage then is it unreasonable for us to expect that these types of statements/pronouncements cease from the editors? Else, there will continue to be a perception of what you say vs. what you do that outsiders will continue to question (and continue to revisit - Lachlan's initial complaint). Respectfully, JF
Re: [whatwg] Seeing the open issues
On Thu, 23 Aug 2007, Keryx Web wrote: Ian Hickson skrev: In response to the concerns over the lack of transparency that have recently been expressed both in these mailing lists and on blog posts, I have written a tool that exposes the issues I have on my list: http://www.whatwg.org/issues/ I was going to vote for the headers and axis attributes on table cells, but they were not on the list at all. Considering the really strong uproar against HTML 5 from accessibility experts that this issue has caused, I found it surprising to see they were not even considered an issue. You can find a number of e-mails regarding headers= under the semantics-tables folder. I don't think anyone has actually suggested that we use axis=, though. Mostly, though, the headers= issue is being covered in the HTMLWG's wiki, which is a separate (and in-development) list of issues from the issues list here (which is basically just a view of my IMAP folders). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Answering the question... (timing of table headers issue)
On Thu, 2007-08-23 at 12:14 -0700, John Foliot wrote: Dan Connolly wrote: I sympathize with your frustration, but I ask that you remain patient. Dan, Thank you for your prompt response. While patience is indeed a virtue, my (our?) patience is being sorely tested, as while the official word is that we're nowhere near deciding anything, current editors and contributors are going ahead and making pronouncements that lead many to believe that much of HTML5 is 'fait accomplis'. As someone once said to me, you can't suck and blow at the same time. To whit: * Is Anne (Standards Suck) van Kesteren out of place to be announcing that HTML5 has dropped input usemap? [http://annevankesteren.nl/2007/08/input-usemap] Evidently; i.e. perception is reality, and I'm getting complaints about this weblog entry. Anne, you and I have certainly talked about the connotations and denotations of dropped. Something like the editors are evidently inclined to drop input usemap; it will be interesting to see whether any new arguments come up perhaps wouldn't have generated as many complaints. How about updating your weblog entry with something like that, Anne? * Is Lachlan Hunt definitive when stating, HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document. [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as HTML5 currently will not be including the usemap attribute on input elements. [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] He seems to be accurately quoting from current editor's drafts. That seems like a useful way to get feedback from the mozilla development community, no? It seems to me that in the bugzilla context, it's reasonably well known that HTML 5 is a moving target. The Mozilla foundation is reasonably well represented in this working group; I'm interested to get confirmation as to whether this is business-as-usual or something counter to norms there. * Is From Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] I accept underspecified and likely to be dropped as his opinion, and as far as I know he's correct that it's not implemented by IE. These types of pronouncements *do* tend to send mixed messages, don't you agree? Yes. That's an accurate reflection of the constituencies in the working group: there are a variety of opinions. We could have chartered the working group to keep its discussions member-confidential until we reached consensus, but I don't think that would be better. If these authors/HTML 5 contributors can be categorically making these kinds of statements, then is it not unreasonable to expect something like, Based upon current feedback, the headers attribute will be preserved in HTML5 (attribute to whom you wish)? What I get from Al Gilman's 6 June message is that something that provides the functionality of the headers attribute is needed. He doesn't argue that the headers attribute is the only acceptable solution. http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html I have seen a fair amount of test data fly by and I have seen a lot of discussion of use cases. I have not digested it all yet. I know that these issues have been raised to you previously. If we are to accept that it is still at the ...*no* design decisions made... stage then is it unreasonable for us to expect that these types of statements/pronouncements cease from the editors? Else, there will continue to be a perception of what you say vs. what you do that outsiders will continue to question (and continue to revisit - Lachlan's initial complaint). Indeed, until the issue is resolved, we all have to accept that it will continue to be discussed and revisited. Respectfully, JF -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Re: [whatwg] Answering the question... (timing of table headers issue)
Dan Connolly wrote: * Is Lachlan Hunt definitive when stating, HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document. [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as HTML5 currently will not be including the usemap attribute on input elements. [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] He seems to be accurately quoting from current editor's drafts. That seems like a useful way to get feedback from the mozilla development community, no? I disagree. He is stating it as fact, when in reality it is the current thinking. If you are seeking feedback, then it is a proposal: re-read what Lachlan has written, it does not sound like a proposal, but rather a firm decision to which mozilla should be conforming to (it's a bug report!!!). * Is Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] I accept underspecified and likely to be dropped as his opinion, and as far as I know he's correct that it's not implemented by IE. Fair enough, but by reading this, there is no indication that it is opinion, and is further clouded by the fact that he is making a projection regarding 2 browser's future implementation/non-implementation, even though he does not work for nor speak for either. Failing to recognize that this is a problem is of concern. These types of pronouncements *do* tend to send mixed messages, don't you agree? Yes. That's an accurate reflection of the constituencies in the working group: there are a variety of opinions. We could have chartered the working group to keep its discussions member-confidential until we reached consensus, but I don't think that would be better. Clearly allowing any and all to espouse their opinion as de-facto decision is not working either. JF
[whatwg] Offline Web Apps
(If you reply, please only include one of the mailing lists in your reply. Thanks.) So I read through all the offline Web app discussions: http://www.whatwg.org/issues/#filesystem http://code.google.com/apis/gears/api_localserver.html http://www.campd.org/stuff/Offline%20Cache.html ...and various others. USER INTERACTION SCENARIOS It seems like we are talking about the following kinds of scenarios: 1. User goes to a page, then, without closing the page, goes offline and uses it, then goes back online and continues to use it. The page and its subresources are always at their most up-to-date. Interactions with the page while offline are synced to the server when going online. 2. User goes to a page, then closes the browser. User restarts the browser while offline, and goes to the page. User restarts the browser again while online, and goes to the page. The page and its subresources are always at their most up-to-date. Interactions with the page while offline are synced to the server when going online. 3. Same as 1 or 2, except that the user is not online for long enough to fully download the updated resources. The application doesn't stop working, it is still usable the second time the user is offline. OTHER NEEDS We also seem to have the following requirements: * Some way to specify what pages are needed while offline, even if the page doesn't link to it. * Some way to handle two offline Web apps both using the same secondary resource, if we have some sort of versioning scheme. (So you can update the two apps independently without breaking either despite them using the same resource.) * Resilience to updates -- if the page is open when you go online and there's an update pending, or when you go online just as you're loading the page (common with wireless networks, since you're likely to take a few seconds to connect and your browser is often ready beforehand) and there's an update pending. * Resilience to broken updates. (More than the reload button?) * There needs to be a way for the application to talk to the server without talking to the offline cache. * The API should be simple, both to authors on the client side, and to authors on the server side, and to the end user, and ideally to the implementors (and to me, the spec author!). QUESTIONS * Does an app have to be multiple top-level pages, or can we assume an app is a single page? (The idea below assumes single-page apps.) * Do we really need a way to ignore the query parameters when fetching and serving from cache when offline? (The idea below assumes not. I don't really understand the use case if the answer is yes.) * Do we really need a way to check the status of cookies when fetching pages? (The idea below assumes not, since the discussion earlier seemed to establish that wasn't necessary.) IDEA Ok so here's my idea based on the existing ideas, the comments on those ideas, and so forth. One of my main goals was keeping everything as simple as possible. My proposal is that we add a new attribute to the html element, which flags that the page is a Web app that wants to be pinned for offline execution and that when you next fetch the file or one of its subresources while online, it should try to update all the subresources atomically. html application This could either trigger the different behaviour automatically, or only when requested by the user, or we could say this applies to any page, but that the user must enable it, or we could provide an API which triggers this for the page. I kind of like the explicit attribute, though. For pages that say this: * If the page is already in cache, load the page and all its resources from the cache. * If the page is not in the cache, create a new cache for it and start storing it there. Then display it from the cache (loading incrementally, so the first load is indistinguishable to the user from any other load). * Any resources it uses go into the cache. Different applications (HTML files with html application) that use the same resources (even if they are on other domains) result in multiple conceptual copies in different (per-app) caches, and with updates (see below) they can end up being at different revisions. This ensures that an application always has one coherent set of files from the time of its last update, with none of its components updating unexpectedly. The main UA cache should always have the latest file that was fetched, so if you visit the URL directly while offline you could see a different version than the version that a particular Web app sees. Web developer tools might offer a way to pick which app cache to use when looking at files for debugging. * The cache ignores cache expiration headers, keeping all content even when it is stale, though the headers are still used when
Re: [whatwg] Offline Web Apps
On Aug 23, 2007, at 6:42 PM, Ian Hickson wrote: IDEA Ok so here's my idea based on the existing ideas, the comments on those ideas, and so forth. One of my main goals was keeping everything as simple as possible. My proposal is that we add a new attribute to the html element, which flags that the page is a Web app that wants to be pinned for offline execution and that when you next fetch the file or one of its subresources while online, it should try to update all the subresources atomically. html application This could either trigger the different behaviour automatically, or only when requested by the user, or we could say this applies to any page, but that the user must enable it, or we could provide an API which triggers this for the page. I kind of like the explicit attribute, though. ... Comments? I haven't read over the details but there seems to be an obvious showstopper problem: this won't work for web applications that consist of more than one page. Regards, Maciej
Re: [whatwg] Answering the question... (timing of table headers issue)
On Aug 23, 2007, at 3:43 PM, John Foliot wrote: * Is Maciej Stachowiak correct when he states, This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result. [http://bugs.webkit.org/show_bug.cgi?id=15032] I accept underspecified and likely to be dropped as his opinion, and as far as I know he's correct that it's not implemented by IE. Fair enough, but by reading this, there is no indication that it is opinion, and is further clouded by the fact that he is making a projection regarding 2 browser's future implementation/non-implementation, even though he does not work for nor speak for either. Failing to recognize that this is a problem is of concern. This isn't my advice to the WebKit developers, this is my comment on a bug report *as* a WebKit developer. Is it wrong for implementors to look at past specs, other implementations, or the ongoing web standards process in making decisions on what to implement? In fact, is it even a matter that should be discussed on a bunch of web standards mailing lists, rather than in the bug tracker? Regards, Maciej
Re: [whatwg] Offline Web Apps
On Thu, 23 Aug 2007, Maciej Stachowiak wrote: I haven't read over the details but there seems to be an obvious showstopper problem: this won't work for web applications that consist of more than one page. Indeed, that was called out as a potential issue. But is that really a problem? It's easy to work around (e.g. with iframe)s if you really must have multiple top-level pages, but aren't web apps moving to a one-page model anyway? The problem gets significantly more complicated with multiple top-level pages all taking part in the same conceptual application. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Answering the question... (timing of table headers issue)
John, Dan and Maciej wrote: [snip] I'd like to request, if that is at all possible, that we keep this kind of discussion out of the WHATWG mailing list. Insofar as the WHATWG and the WHATWG HTML5 document are concerned, people are welcome to make any statements they like, especially on their blogs and in bug systems, as well as on the WHATWG's own blog, on forums, in the WHATWG IRC channel, or wherever. This discussion, therefore, is irrelevant to this mailing list. In addition, I'd like to request that the tone of e-mails sent to the WHATWG list be kept far more civil than the original e-mail in this thread. All WHATWG contributors are a team working together. Regarding the specific issue raised, namely that of the ability for all users of HTML pages to determine without ambiguity which header cells apply to which data cells in tables in HTML documents, this is one of the many hundreds of open issues, which you can see on the issues list: http://www.whatwg.org/issues/ If you would like for me to prioritise one issue over another, please vote for the issue e-mail in question. Anyone who has written an e-mail that has ended up in that list at some point is able to vote. In general I would counsel patience; features from HTML4 (such as headers= or style=) are not a high priority since they already have a specification and therefore what HTML5 says about them does not really matter on the short term while HTML5 is in such early stages as it is now. Rest assured that universal access is an integral part of the design of all HTML features, including tables, and all feedback, whether sent to this list or to the HTMLWG list or anywhere else that I hear about will get considered in due course. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Offline Web Apps
On Aug 23, 2007 8:18 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 23 Aug 2007, Maciej Stachowiak wrote: I haven't read over the details but there seems to be an obvious showstopper problem: this won't work for web applications that consist of more than one page. Indeed, that was called out as a potential issue. But is that really a problem? It's easy to work around (e.g. with iframe)s if you really must have multiple top-level pages, but aren't web apps moving to a one-page model anyway? The problem gets significantly more complicated with multiple top-level pages all taking part in the same conceptual application. The single-page model has other nice advantages. For example, there's never any confusion about which cache should serve a resource. It's the one that's associated with the application which the resource is contained in. Could multi-page apps be addressed by letting applications specify that other applications should be cached (using a similar api to the one that lets applications programatically cache resources)? - a
Re: [whatwg] Offline Web Apps
On Thu, 23 Aug 2007, Aaron Boodman wrote: The single-page model has other nice advantages. For example, there's never any confusion about which cache should serve a resource. It's the one that's associated with the application which the resource is contained in. Indeed. Could multi-page apps be addressed by letting applications specify that other applications should be cached (using a similar api to the one that lets applications programatically cache resources)? Ooh, that might work. Yeah. Maciej, what do you think? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
