| 01:54 | <webben_> | Is there a document that describes the typical testing process when new elements/attributes are proposed for HTML5? |
| 01:54 | <webben_> | (note, not the stuff about finding problems and evaluating different solutions) |
| 02:12 | <zcorpan_> | webben_: what testing process? |
| 02:13 | <webben_> | stuff like inspecting in the live DOM viewer, testing in actual browsers, making experimental implementations |
| 02:14 | <webben_> | oh, and surveying the web to see what's out there |
| 02:14 | <zcorpan_> | i'm not aware of any document that describes that, no |
| 02:14 | <webben_> | ah well. thanks anyhow :) |
| 02:15 | <zcorpan_> | perhaps there's an archived email though |
| 02:15 | <zcorpan_> | dunno |
| 02:15 | <webben_> | does that short list miss out any obvious steps? |
| 02:17 | <zcorpan_> | researching if there are proprietary implementations that solve the same problem |
| 02:18 | <webben_> | ah, that comes under evaluating different solutions |
| 02:18 | <zcorpan_> | true |
| 12:09 | <hsivonen> | bad stuff. my email provider has a load problem and I'm locked into their service :-( |
| 15:47 | <hsivonen> | is there a replacement for Hixie's character identifier? it is currently broken |
| 16:25 | <webben_> | hsivonen: Character identifier? |
| 16:25 | <webben_> | what did it do? |
| 16:26 | <hsivonen> | webben_: identify the code points and unicode names of pasted text |
| 16:26 | <webben_> | hsivonen: http://people.w3.org/rishida/scripts/uniview/conversion.php |
| 16:26 | <hsivonen> | webben_: cool. Thanks. |
| 16:26 | <webben_> | yw |
| 21:55 | <zcorpan_> | http://aetherlumina.com/html/sucks.html is pretty funny |
| 21:58 | <zcorpan_> | at the same time it's sad because it's largely true |
| 21:59 | <webben> | when he says XHTML isn't valid XML, precisely what sort of XHTML is he talking about? XHTML distorted via Appendix C, or vanilla "XML" XHTML? |
| 22:00 | <webben> | or does he just mean the document of the XHTML 1.0 spec itself? |
| 22:01 | <webben> | also, some of the sites he lists as having no doctype do have a doctype (maybe the rant's just old, I dunno) |
| 22:01 | <zcorpan_> | dunno. when i try validating w3.org with the service he says i get a number of errors about the dtd |
| 22:03 | <zcorpan_> | wayback machine's first copy of the rant is from april 2003 |
| 22:34 | <jgraham_> | annevk2: yt? |
| 22:39 | <annevk2> | sort of |
| 22:41 | <jgraham_> | It's not at all urgent. I was just wondering if there's any chance of getting enough space on james.html5.org to build python 2.5, since that seems to be the right way to fix python suckiness on dreamhost |
| 22:41 | <jgraham_> | But it's not a big problem if not |
| 22:42 | <annevk> | how much do you need? |
| 22:42 | <annevk> | gigabyte? |
| 22:43 | <annevk> | just give me a number of MB |
| 22:45 | <annevk> | you got 10GB now |
| 22:45 | <annevk> | instead of 100MB |
| 22:45 | <jgraham_> | OK, so that rather makes my attemp to estimate how much is needed pointless :) |
| 22:45 | <jgraham_> | Thanks :) |
| 22:46 | <annevk> | the plan comes with 290GB and the UI sort of encourages to put limits on users so I give everyone 100MB by default |
| 22:47 | <annevk> | assuming that scripts + html pages + the occasional image doesn't go over that, but it's a pretty arbitrary limit |
| 22:48 | <hsivonen> | hmm. would be interesting to build an encrypted Dreamhost filesystem with FUSE |
| 22:48 | <jgraham_> | Yeah, having limits makes sense |
| 22:48 | <hsivonen> | and use it as a TimeMachine backing store... |
| 22:49 | <gsnedders> | I mean, you never know what I might use it for :P |
| 22:49 | gsnedders | needs to write more tests |
| 22:49 | gsnedders | has too much to-do |
| 22:53 | <jgraham_> | hsivonen: So I was thinking about the whole table @headers thing again and I wondered if it should be made conforming but the spec should say that authors SHOULD NOT use @headers unless no other mechanism could express the correct relationships |
| 22:53 | <jgraham_> | However I thought you might not like the machine-checkable-but-hard-o-implement criteria |
| 22:53 | <jgraham_> | s/-o /-to-/ |
| 22:54 | <gsnedders> | jgraham: someone might see one way of marking something up, but another person might not |
| 22:54 | <webben> | Given the complexity of some of the proposed header/cell association mechanisms, I should think that imposes a substantial cognitive load on authors. |
| 22:54 | <jgraham_> | The theory is that the only people who care about @headers also care about accessibility and so are more likely than average to actualy follow the spec on this point |
| 22:54 | <gsnedders> | that pushes it a bit too far |
| 22:54 | <webben> | But I can see you could machine-check it. |
| 22:55 | <webben> | OTOH it's unclear what the advantage of burdening authors with the burden of checking it would be. |
| 22:56 | <webben> | saving bytes? |
| 22:56 | <jgraham_> | gsnedders: I don't think that's actually likely to be a problem in practice |
| 22:57 | <jgraham_> | webben: The problem is that people get @headers wrong so often that it can actually be harmful to respect it |
| 22:57 | <jgraham_> | OTOH there are a few legitimate cases where no other mechanism so far proposed can work |
| 22:58 | <webben> | The problem there is incorrect heading information, not how the information is expressed. |
| 22:59 | <webben> | If people get headers wrong, and you run a tool which checks to see if the headers info is superflous, then the tool's result will be wrong too. |
| 22:59 | <jgraham_> | The problem is @headers makes it so easy to get the information wrong that _in practice_ it can be worse than doing nothing |
| 22:59 | <webben> | So the only sort of tool that helps is one that shows you the associations and asks if they're right. |
| 23:00 | <jgraham_> | (typical mistakes include mistyping the attribute name, mistyping the idrefs, putting an idref to an element not in the table) |
| 23:00 | <webben> | all three sound like situations where a UA should act as if the attribute isn't there |
| 23:01 | <webben> | and therefore the fact that the attribute is wrong shouldn't make it worse than if it wasn't there |
| 23:02 | <jgraham_> | webben: it does make it worse than using e.g. scope attributes to express the same information though |
| 23:03 | <jgraham_> | and in some cases - e.g. if the author just gets one idref wrong, it houldn't ignore the whole value, presumably |
| 23:03 | <webben> | well, the only reason not to use scope is because either a) you're generating with a tool that generates table markup and just uses header/id (removing the human error element) or b) consuming agents don't support scope. |
| 23:03 | <webben> | artificially limiting authors to scope doesn't help in either situation |
| 23:03 | <jgraham_> | webben: Let's ignore the limitations of UAs for the moment |
| 23:04 | <jgraham_> | (arguably that would be a good reason to violate a SHOULD NOT, but not enough to violate the implicit MUST NOT of removing the attribute from the spec) |
| 23:05 | <jgraham_> | s/that/UA limitations/ |
| 23:05 | <webben> | I think making good practice (making websites that actually work) dependent on violating SHOULD NOTs is counter-intuitive. |
| 23:06 | <webben> | (although I can see your point given the technical definition of SHOULD NOT) |
| 23:07 | <jgraham_> | The solution to that problem is to make the UA vendors implement non-@headers algorithms in their product. |
| 23:07 | <webben> | Yeah, and the solution to IE not supporting XHTML is to "make" MS implement XHTML. |
| 23:07 | <jgraham_> | Which they really ought to do anyway since so few sites use @headers |
| 23:07 | <webben> | few sites use scope either |
| 23:08 | <jgraham_> | Hey I didn't say it would be easy :) |
| 23:08 | <webben> | I don't think the solution to making websites that actually work is to foist problems onto client software vendors and end-users. |
| 23:08 | <jgraham_> | re:scope indeed, which is why I'm trying to make it needed in as few cases as possible |
| 23:10 | <othermaciej> | webben: actually, putting a burden on client software vendors is probably better than putting it on web developers, if getting it right is possible either way and if it matters to the end user |
| 23:10 | <othermaciej> | because there's a lot fewer user agents than web sites |
| 23:10 | <othermaciej> | so that's fewer places to get it wrong |
| 23:10 | <jgraham_> | The history of the web suggests that trying to adjust the behavior of the inhomogeneous mass of authors is ineffective way to solve problems |
| 23:11 | <webben> | I wouldn't say the history of web developers desiring UAs to implement specs is a particularly happy history either. |
| 23:11 | <othermaciej> | do you mean that we developers don't desire that, or that UAs don't implement the specs that web developers want? |
| 23:11 | <webben> | besides we're not talking here about giving authors licence, but about restricting them with a SHOULD NOT. |
| 23:11 | <jgraham_> | I would rather try and change a handful of UAs than a large number of authors |
| 23:12 | <webben> | (or appearing to restrict them, and thus confusing the issue) |
| 23:12 | <webben> | meh, changing web output is cheap compared to changing expensive software installs |
| 23:13 | <othermaciej> | per unit, yes |
| 23:13 | <othermaciej> | but web output is much much larger in total |
| 23:13 | <webben> | (witness how we bend over backwards to serve IE6 ... and upgrading from IE6 is nearly free) |
| 23:13 | <jgraham_> | webben: Restricting people is often good overall |
| 23:13 | <webben> | (where upgrading means moving to IE7 or any other decent browser) |
| 23:13 | <jgraham_> | e.g. the more limited UI in Firefox made it a success over the Mozilla suite |
| 23:14 | <othermaciej> | IE seems to be the only browser that doesn't get upgrade traction |
| 23:14 | <jgraham_> | (often web output is backed by expensive software installs) |
| 23:14 | <othermaciej> | (not sure why - bug lockin? people who never upgrade?) |
| 23:15 | <webben> | I'm not sure how far you can push an analogy between user interfaces (which are designed to present functionality to the user) and markup languages (that are designed, basically, to trigger functionality in client software0 |
| 23:15 | <othermaciej> | languages are a user interface for developers |
| 23:15 | <jgraham_> | they both involve human interaction at some stage in the process |
| 23:15 | <webben> | yes, but UIs are intrinsically much freer |
| 23:16 | <webben> | because the functionality on the backend can be guaranteed by the same developers |
| 23:16 | <webben> | (if the language was being designed from scratch, this would be a void argument of course) |
| 23:17 | <jgraham_> | An obvious example of a restriction in a language for increased usability is python+whitespace |
| 23:17 | <jgraham_> | (irrespective of whether you think that is a design success, that's why it works the way it does) |
| 23:17 | <webben> | heh, well that's as controversial as restricting HTML5 to XHTML-esque markup styles. |
| 23:18 | <webben> | I'm not saying restrictions in languages are bad; I'm just saying that the need to make this language actually deliver imposes constraints on what restrictions are realistic. |
| 23:18 | <othermaciej> | Python in general tries to avoid having More Than One Way To Do It |
| 23:19 | <jgraham_> | Although a more accurate statement would be "more than one unnecessarily redundant way to do it" |
| 23:20 | <webben> | (It's also notable that since web consuming software is tolerant, the basic reaction to restrictions in this language is to ignore them. People pay attention to white space in Python cos not doing so breaks their programs.) |
| 23:22 | <jgraham_> | webben: To get back to the point, we have a feature with a small set of use cases but which is known in practice to cause significant problems for authors (and hence end users). We can either a) ban it entirely b) discourage it except when absolutely necessary or c) ignore the problems. I think b) makes the most sense |
| 23:24 | <webben> | it's necessary wherever scope would be necessary |
| 23:24 | <webben> | assuming one wants it to work |
| 23:24 | <webben> | (it's theoretically necessary only in a smaller set of cases I agree.) |
| 23:25 | <webben> | I suppose what you could have would be a WCAG1-style discouragement, "Once user agents support, don't use unless bla bla bla" |
| 23:26 | <webben> | but even then one's basically second-guessing what level of backwards-compatibility developers want to provide. |
| 23:28 | <webben> | Maybe one would be best served by actually explaining the problems and letting devs make up their own minds. |
| 23:30 | <jgraham_> | I don' think the spec is the right place to put UA compatibly information, but it could certainly go in the authoring guide |
| 23:30 | <webben> | Oh, I didn't mean say UA X supports this, UA X does not. More just explaining the general problem that some UAs do, and some UAs don't. |
| 23:31 | <webben> | (but all UAs should) |
| 23:36 | <jgraham_> | I still think the authoring guide would be better |