# [09:24] * Quits: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com) ("Perhaps on the rare occasion pursuing the right course demands an act of piracy, piracy itself can be the right course?")
# [09:29] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
# [09:51] <zcorpan_> the first fragment would be conforming with the old rules since ul is struct-inline... but then no-one would understand the old rules anyway
# [09:54] * zcorpan_ notes that the article refers to error numbers
# [09:59] <Hixie_> and so long as no semicolon occurs between the & and the =, which is author-controlled, i don't see that there could be a problem, really
# [10:06] <hsivonen> Hixie_: when replying to Jim Correia, I noticed that the obsolete-happiness of HTML5 undermines the argument that everyone should trust we don't need versioning for validation going to HTML5 + 1.
# [10:10] <hsivonen> Hixie_: the issue is that people disagree on what "only improves the Web"
# [10:11] <zcorpan_> Hixie_: s/test/validate and test/
# [10:11] <hsivonen> I'd rather see authors spend their time on improving the Web instead of firefighting border='0' copy-paste snippets
# [10:12] <othermaciej> document conformance is hard because there's less at stake
# [10:12] <Hixie_> hsivonen: sure. but that's different from <font>, bgcolor=, align=, etc.
# [10:12] <othermaciej> because people can publish nonconforming documents and there isn't really a problem
# [10:12] <othermaciej> so there's always the temptation to be paternalistic
# [10:12] <hsivonen> Hixie_: I think obsoleting align on th and td doesn't improve the Web
# [10:13] <Hixie_> i think making markup minimal and moving to all css improves the web dramatically
# [10:13] <hsivonen> Hixie_: fwiw, I wouldn't take Transitional wholesale. I want to get rid of <basefont> and <isindex>, for example.
# [10:13] <Hixie_> both in terms of performance and reuse.
# [10:14] <Hixie_> hsivonen: i think that allowing media-specific markup is giving a very wrong message at a time where author are slowly learning the right way.
# [10:14] <hsivonen> Hixie_: if we cared about performance enough to use it as an excuse to ban border='0', we should ban comments for consistency
# [10:15] <hsivonen> and liberal use of whitespace
# [10:15] <Hixie_> hsivonen: i would be more inclined to go back up the slippery slope and remove /> and xmlns="" than i would be to add align="".
# [10:16] <hsivonen> Hixie_: alignment of table cells is conceptually often dependent on the kind of content but Selectors cannot do AI-based matching on the nature of element content
# [10:16] <hsivonen> Hixie_: so letting the author set alignment is the simplest solution
# [10:17] <hsivonen> Hixie_: I don't see what good it would do if authors had to use class='number' instead of align='right'
# [10:17] <zcorpan_> perhaps allow only align=right on <td> and make it mean "number"
# [10:18] <hsivonen> zcorpan_: what if you want to right-align ths that are column heads for numbers?
# [10:18] <Hixie_> hsivonen: just put the class on the table and then use css to set the align on the relevant cells
# [10:18] <zcorpan_> hsivonen: ok, <th> too, meaning that this is a header for a column of only numbers
# [10:19] <hsivonen> Hixie_: what kind of GUI do you envision for writing those selectors?
# [10:19] <hsivonen> Hixie_: would my mother who uses dreamweaver be better off if she had to tweak CSS to content instead of using a pre-designed style sheet?
# [10:20] <hsivonen> Hixie_: I think the pro-CSS principle goes wrong if the authors has to tweak CSS to particular content and a pre-designed style sheet won't work
# [10:21] <hsivonen> Hixie_: stuff that changes on a case-by-case basis like image dimensions and cell alignment should be settable in HTML
# [10:22] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
# [10:22] <hsivonen> Hixie_: with HTML 4.01 Transitional for contextual stuff, I haven't had to add stuff to the style sheet my mother uses in years
# [10:22] <Hixie_> i disagree. i think it's quite reasonable for a wysiwyg editor to work out what rules are necessary to get the desired effect, and i think the incremental rendering argument for img height/width is ok, but the per-image argument is moot
# [10:23] <othermaciej> hsivonen: for tables (proper data tables at least) the main thing missing is column styling, which in theory should be offered but in practice has been too thorny to implement
# [10:24] <othermaciej> (it's rare for alignment to be something tweaked per-cell, but it applies more often to a whole row than a whole column)
# [10:24] <othermaciej> er, I meant that the other way around
# [10:24] <hsivonen> othermaciej: but the point is moot until CSS delivers column styling and top browsers implement it
# [10:25] <hsivonen> othermaciej: until then, authors need to deal with the current per-cell aligment
# [10:26] <Hixie_> well, html5 won't be done for years, maybe someone can get something done in css by then
# [10:26] <hsivonen> Hixie_: have you used Word with autostyles enabled? the user experience becomes horrible, when the editor tries to guess styling rules and adds a level of indirection by guessing
# [10:27] <Hixie_> (i've long proposed [#col=3] and similar)
# [10:27] <Hixie_> hsivonen: that's not what i'm suggesting
# [10:27] <othermaciej> it's too bad tables are row-major instead of column-major, in retrospect the other way would be better for styling
# [10:28] <hsivonen> Hixie_: adding an ID and an # selector doesn't really solve something that authors need solved. I think HTML5 should just let go of the strict non-presentationalism principle
# [10:29] <hsivonen> Hixie_: or what are you suggesting when you say the editor should work out the rules?
# [10:29] <Hixie_> hsivonen: if the user sets all the cells of one column to one type of alignment, it's trivial to come up with a single rule for that with no classes and no IDs, or maybe one class if there are multiple tables.
# [10:30] <hsivonen> Hixie_: is it trivial to round-trip such a rule without editor-specific annotations and have the rule reasonbly editable in GUI?
# [10:32] <Hixie_> < Hixie_> i think making markup minimal and moving to all css improves the web dramatically < Hixie_> both in terms of performance and reuse.
# [10:33] <hsivonen> Hixie_: performance is a red herring if you allow comments at the same time
# [10:37] <othermaciej> that's not to say this is a reason in itself to encourage presentational attributes
# [10:38] <hsivonen> Hixie_: as for maintenance, since aligment is coupled with cell content, contextual attributes make more maintenance sense than elaborate (and brittle!) selectors stored at a distance
# [10:38] <othermaciej> on the other hand align on table cells seems to be very much a special case
# [10:38] <othermaciej> mainly due to lack of usable column styling
# [10:38] <Hixie_> hsivonen: i think you are assuming a world where <td align> is used just for saying "this is a number", and i think in practice that this is far from what it is used for.
# [10:39] <franksalim> you're just talking about the align attribute, not inline styling of table cells, right?
# [10:39] <othermaciej> so one wouldn't want to go down the slippery slope to <p align> or other stuff like that
# [10:39] <hsivonen> franksalim: I'm talking about align='right'
# [10:39] <hsivonen> othermaciej: I don't want align on p or div
# [10:39] <franksalim> hsivonen: i don't understand the necessity of preserving that
# [10:39] <zcorpan_> Hixie_: same goes with <table> being used for data tables...
# [10:40] <Hixie_> othermaciej: we're already going down that slope. hence my comment earlier that arguments like this are more likely to see me go back _up_ the slope and remove /> and xmlns="", than they are to see me go further down the slope with adding img border=0, td align="", etc.
# [10:40] <othermaciej> /> and xmlns="" aren't really in the same category
# [10:41] <othermaciej> those are pointless talismans that make chameleon markup theoretically possible for the joy of those who care about such things
# [10:42] <hsivonen> Lachy: the point of allowing border='0' is to save people the trouble of getting rid of it again, and again, and again
# [10:42] <othermaciej> though I don't think the case is as strong for <td align> as for <b>
# [10:42] <Lachy> for cell alignment, I generally use class names on each table cell that needs special styling, and then style them all at once using a class selector
# [10:43] <Hixie_> hsivonen: i want people to get rid of it.
# [10:43] <hsivonen> Lachy: how is that more noble than <span class='italic'> to avoid <i>?
# [10:43] <Lachy> hsivonen, it's more work to put border=0 on each img, than it is to put a single rule in a reusable stylesheet
# [10:43] <Hixie_> othermaciej: for <b>, i can see how we can define it in a completely non-presentational manner quite legitimately.
# [10:44] <hsivonen> Lachy: I'm not suggesting that people write border='0'. I'm suggesting that we don't ask people to delete it when a tool or a cute badge template put it in the markup
# [10:44] <Hixie_> so how do we catch new authors writing it?
# [10:44] <othermaciej> so is this because Gecko puts borders around images in links by default?
# [10:45] <Hixie_> that's the problem transitional never solved
# [10:48] <othermaciej> (I wonder if there's a bug?)
# [10:49] <hsivonen> othermaciej: I couldn't find one yesterday
# [10:49] <othermaciej> hsivonen: yes, 5-10 years after they ship a version of Firefox that does that people might stop including the border='0'
# [10:49] <Lachy> othermaciej, does webkit use a border?
# [10:49] <hsivonen> othermaciej: right, so during that time, is it good use of human time to keep hunting instances of border='0'?
# [10:49] <Hixie> hsivonen: i think catching it is important, because it's one of many things (like align=right, and />, and xmlns="") that litters the web and for which the web would be a better place without
# [10:51] <othermaciej> I wonder if anyone has ever filed a bug about lack of this behavior in WebKit
# [10:51] <hsivonen> Hixie: I think the cost of improving the Web on this particular point is unfavorable compared to the expected improvement
# [10:52] <Lachy> I wonder if IE could drop it for IE8 in all modes?
# [10:52] <hsivonen> Lachy: if they don't for the IE 5.5 mode, copy-pasteable snippets will continue to have border='0' or, worse, style='border:0'
# [10:53] <Hixie> hsivonen: i think that the cost of having an unclear message (you can have border, but only if it is 0, and only on img, not on table, and you can have align=right on td but not on col and not on p...)
# [11:09] <roc> we still use lang/xml:lang as part of the font selection process
# [11:10] <othermaciej> if anyone is still curious...
# [11:10] <othermaciej> we do have a bug filed for lacking a border on broken images, but no such bug as far as I can tell for link images
# [11:11] <Hixie> "With browser vendors tripping all over themselves to implement draft modules from the CSS3, HTML5 and XHTML2 specifications, the first wave of web standards is drawing to a close."
# [12:52] <Philip`> "An end tag whose tag name is "br" Parse error. Act as if a start tag token with the tag name "br" had been seen. Ignore the end tag token."
# [12:52] <Philip`> I guess it's implicit that the generated token has no attributes
# [13:27] <gsnedders> hsivonen: peh. it's not hard in RSS! you just check whether it has anything that looks like an end tag (without attributes) or an entity and if it has either, treat it as HTML :P
# [13:29] <gsnedders> annevk: do browsers return the last header if you request Content-Type (or something else relevant to the protocol) and there are multiple headers of the type? What if there are occurrences of the header in the trailer of a chunked response?
# [13:29] * annevk tries to make access control more friendly to lots of non-GET methods to lots of different URIs on the same domain
# [14:26] * annevk makes access control even more complicated first
# [14:27] <annevk> with access control QA teams can rejoice as they'll be guaranteed with work for the coming decade
# [14:27] <hsivonen> is the RDF schema under the Document License or the Software License?
# [14:28] <zcorpan_> annevk: so *that's* why you're working on access control ;)
# [14:28] <zcorpan_> hsivonen: the document conformance criteria are wrong at this point
# [14:29] <zcorpan_> hsivonen: that was pointed out but not fixed before publication
# [14:29] <zcorpan_> (dunno about the license though)
# [14:30] <hsivonen> zcorpan_: ok. I'm looking for reasonably machine-readable copyright-wise unencumbered data about what the roles are, what states and properties apply to which roles and the datatypes of the states/properties
# [14:30] <hsivonen> Document License being encumbered but Software License or MIT license being unencumbered
# [14:32] <hsivonen> though the RDF schema is so small after all, that perhaps typing a RELAX NG schema is simpler than writing a converter
# [14:39] <annevk> i hope it looks reasonable when styled
# [14:39] * Philip` thinks there should be a machine-readable way of describing state machines like that, which can get converted into human-readable spec text
# [14:40] <annevk> some people prefer models rather than this, but I'm unsure how to write them down accurately
# [14:40] <Philip`> (I'd particularly like that since it'd save me the work of converting the human-readable text into a machine-readable form...)
# [14:40] <annevk> my state machines don't exactly map to code straigh away
# [14:41] <annevk> at least not the code we write nowadays
# [14:41] * Philip` now supports comments, non-special start tags and non-special end tags in his OCaml HTML5 parser
# [14:42] <Philip`> which is not particularly impressive yet :-(
# [14:43] <annevk> ah, you started with doing the treebuilding phase?
# [14:44] <Philip`> I started with the tokeniser, and finished that months ago :-)
# [15:33] <Dashiva> Shouldn't the error be about implied elements instead, then?
# [15:33] <zcorpan_> i guess the validation layer doesn't know which elements were implied
# [15:34] <hsivonen> Dashiva: there are many "Error: Unclosed elements."
# [15:34] <Dashiva> hsivonen: Then maybe there shouldn't be an error at all for the implied ones
# [15:35] <Dashiva> It seems odd to error on <s>, error on unclosed, and then later create an additional error about an implied duplicate, after all both issues have been reported
# [15:35] <hsivonen> Dashiva: like zcorpan_ said, the validation layer doesn't know which elements were implied. besides, the DOM conformance requirements don't discriminate between implied and explicit
# [15:35] <zcorpan_> or it could perhaps figure it out by comparing the error with the sax event that carries location information (or how it's implemented)
# [15:35] <Philip`> Safari seems to limit things by not cloning a node more than once
# [15:36] <hsivonen> It's more likely that this issue isn't worth tweaking on the validation layer, because nodes getting cloned to this extent is rare in real content
# [15:37] <hsivonen> which is why Safari can get away with its limit
# [15:37] <zcorpan_> Philip`: that might be a good perf win
# [15:38] <Philip`> It looks like a DOS vulnerability in the validator, since an attacker can do O(n) work to make the validator do O(n^2)
# [15:42] <hsivonen> I think the biggest DoS attack vectors against the validator right now are user-provided regular expressions is schemas and user-provided XPath in schemas