| 00:25 | <cardona507> | mpilgrim - thanks for diveintohtml5.org - its great |
| 08:21 | <JonathanNeal> | hola. |
| 08:22 | <Hixie> | othermaciej: is there a page anywhere with an up to date list of the current issues with pending change proposal deadlines? |
| 08:23 | <othermaciej> | Hixie: no - I was just thinking earlier today that we need one like that |
| 08:23 | <Hixie> | it's getting difficult to keep track |
| 08:23 | <othermaciej> | Hixie: more generally a list of issues indicating current state (CfC to close, waiting for proposal, proposal in hand and waiting for response, etc) |
| 08:23 | <othermaciej> | yes I know |
| 08:24 | <othermaciej> | it's hard for me too |
| 08:24 | <othermaciej> | in fact I think we have some CfC's to close things etc which we are not properly tracking |
| 08:24 | <othermaciej> | I am glad Shelley made a concrete proposal |
| 08:24 | <othermaciej> | I can't say I like <fltcap> as a name |
| 08:25 | <othermaciej> | should I ask her to describe how to spec her proposed <fltcap> element or do you think it's ok for her proposal to mostly leave that undefined? |
| 08:27 | <Hixie> | i'm not up to date on list mail |
| 08:27 | <Hixie> | so i've no idea what you are talking about :-) |
| 08:27 | <othermaciej> | ah |
| 08:27 | <JonathanNeal> | So when writing <header><h1>Foo</h1><nav>...this and that...</nav></header> the nav section has an implied heading of Foo, right? |
| 08:28 | <othermaciej> | Shelley sent a Change Proposal for the dt/dd reuse issue |
| 08:28 | <othermaciej> | and proposed <fltcap> as a new element to use as the caption for both <figure> and <dialog> |
| 08:29 | <Hixie> | JonathanNeal: no, it has no heading (and an implied heading "navigation" maybe, that's up to the UA) |
| 08:30 | <Hixie> | othermaciej: i think the idea of inventing a new element to mean the same as <caption>/<legend>/<dt>/<th>/<h1>/etc is pretty well-understood |
| 08:30 | <othermaciej> | mmkay |
| 08:31 | hsivonen | fails to guess where 'lt' comes in <fltcap> without reading the proposal |
| 08:31 | <othermaciej> | given that she proposed a specific name, I won't be picky about the lack of detail since presumably the behavior is pretty clear |
| 08:31 | <Hixie> | lack of detail is preferred, imho |
| 08:31 | <Hixie> | since any detail we have will end up requiring another Decision to change when we find it is a problem |
| 08:33 | <JonathanNeal> | Hixie, so should nav have a heading? |
| 08:33 | <JonathanNeal> | In that case, Hixie? |
| 08:33 | <Hixie> | JonathanNeal: it may |
| 08:34 | <hsivonen> | maybe I should make V.nu complain about rel=profile before I get around to supporting the rel registry in general |
| 08:34 | <hsivonen> | to remove the validator aspect from the profile discussion |
| 08:35 | <hsivonen> | (since now it looks like rel=profile has the advantage over @profile that it validates) |
| 08:38 | <Hixie> | has anyone told you what rel=profile is for, yet? |
| 08:39 | <hsivonen> | Hixie: yes, but not what the point is compared to @profile |
| 08:39 | <Hixie> | oh good, what is it for? |
| 08:40 | <hsivonen> | Hixie: the purpose is that extension A and extension B can both use syntax foo |
| 08:40 | <hsivonen> | Hixie: and then you use the profile to decide if foo should be processed according to A or B |
| 08:40 | <Hixie> | in the same document? |
| 08:40 | <hsivonen> | Hixie: as I understand it, as drafted, you don't get to use A and B in the same document |
| 08:41 | <Hixie> | why can't you just use the two extensions without the rel=profile then? |
| 08:41 | <hsivonen> | Hixie: because then you don't know if foo should be processed according to A or B |
| 08:42 | <hsivonen> | (no, I don't know what happens if you use foo and specify profiles for both A and B) |
| 08:42 | <Hixie> | is there a concrete example of this? i'm not really following. |
| 08:43 | <hsivonen> | Hixie: I'm not aware of any example in the past where this was needed |
| 08:43 | <hsivonen> | Hixie: but I can try to contrive a "concrete" example |
| 08:44 | <hsivonen> | Hixie: RDFa x.y says that the property attribute takes a CURIE |
| 08:44 | <JonathanNeal> | It seems each person I ask has a different take on HTML5 and particularly header, footer, and nav. Examples in the draft almost always show a headless nav. |
| 08:46 | <hsivonen> | Hixie: RDFa z.å says that the property attribute takes another kind of value whose lexical space matches CURIE but that needs totally different processing |
| 08:47 | <hsivonen> | Hixie: then you use profile to decide which set of processing rules to apply |
| 08:47 | <hsivonen> | Hixie: or |
| 08:48 | <hsivonen> | Hixie: plausible examples are so hard to come up with |
| 08:48 | <Hixie> | ...or, you could not change your language in a backwards-incompatible way, and thus not need it |
| 08:48 | <hsivonen> | Hixie: right |
| 08:49 | <hsivonen> | Hixie: so another scenario would be this (non-concretely): |
| 08:49 | <hsivonen> | IBM intranet uses foo for something |
| 08:49 | <hsivonen> | and Boeing intranet unaware of this uses foo for something else |
| 08:49 | <hsivonen> | then Google deploys a third foo on the Web |
| 08:49 | <hsivonen> | now clients that see both the public Web and one of the intranets needs to deal |
| 08:50 | <Hixie> | and so they need to go and update every page to say profile="ibm"? |
| 08:50 | <Hixie> | wouldn't it be just as easy to just change the pages to use ibm-foo instead? |
| 08:50 | <hsivonen> | Hixie: something like that |
| 08:51 | <Hixie> | this seems rather poorly thought through |
| 08:51 | <hsivonen> | Hixie: maybe they use profile='http://www42.ibm.com/2009/11/11/fooml'; from get-go, so there's nothing to update |
| 08:51 | <hsivonen> | Hixie: you don't say |
| 08:51 | <Hixie> | if they knew to make their stuff unique, they wouldn't use "foo", they could just use "ibm-foo" |
| 08:52 | <hsivonen> | maybe the three letters ibm aren't globally as unique as http://www42.ibm.com/2009/11/11/fooml |
| 08:52 | <hsivonen> | Hixie: maybe Manu could explain this better than I can |
| 09:02 | jgraham | notes that Shelley's change proposal actually contains two competing change proposals a) drop figure and details and b) use a new element instead of <dd> and <dt> inside <figure> and <details> |
| 09:02 | <Hixie> | hsivonen: if in practice "foo" has been globally unique enough, "ibm-foo" seems plenty enough |
| 09:03 | <jgraham> | Which seems problematic because I can live with b) or c) (maintain the staus quo) but cannot live with a) |
| 09:03 | <jgraham> | So I can't meaningfully have an opinion on the change proposal as a whole |
| 09:04 | <jgraham> | (and without the "what to do about <figure> and <details> bits the change propoal doesn't make any sense even though those changes are pitched as "ancillary") |
| 09:05 | <jgraham> | (but with a more correct spelling of "ancilliary") |
| 09:09 | <hsivonen> | Hixie: it seems that more disambiguation than that is some kind of Holy Grail |
| 09:10 | <hsivonen> | Hixie: However, I predict that optional disambiguation will fail |
| 09:10 | <Hixie> | no ned to predict it |
| 09:10 | <Hixie> | just look at profile="" |
| 09:11 | <hsivonen> | Hixie: my prediction applies to rel=profile |
| 09:11 | <hsivonen> | Hixie: I postdict the same for @profile |
| 09:11 | <othermaciej> | hsivonen, Hixie: tantek promoted rel=profile as a superior alternative because you could scope it (I guess by using <a rel="profile">?) |
| 09:12 | <hsivonen> | othermaciej: I'll comment on that when I see a concrete proposal for scoping |
| 09:12 | <hsivonen> | othermaciej: however, if the whole concept is flawed, scoping won't help it |
| 09:12 | <othermaciej> | <link rel="profile"> does not seem to provide for that, assuming <link> is disallowed in the body |
| 09:12 | <othermaciej> | I explained to Tantek the canonical reasons for thinking head@profile is a bad thing over lunch at TPAC |
| 09:12 | <hsivonen> | othermaciej: Manu's and Julian's proposal explicitly prohibits <a rel=profile> |
| 09:13 | <hsivonen> | I have to admit I'm rather puzzled by tantek's profile advocacy considering that Microformats are the premier case study of @profile not working |
| 09:13 | <othermaciej> | he mentioned that a considerable amount of Microformat publishing is accompanied by a profile, though much is not; and said he knew of a total of 1 non-validator Microformats tools that respect @profile |
| 09:14 | <hsivonen> | othermaciej: was that Cognition? |
| 09:14 | <hsivonen> | Cognition doesn't pay attention to @profile by default |
| 09:14 | <othermaciej> | I told him that, since a wise tool should ignore @profile, then it's a waste of time to authors to add it, and therefore a waste of time for validators to tell authors to add it even as a warning (I think it is a SHOULD for many microformats) |
| 09:14 | <othermaciej> | he mentioned that it was a mode, and I am not sure he named the tool but he said it was by Toby Inkster (I think) |
| 09:15 | <hsivonen> | if profile were working why would Cognition's default be to ignore it? |
| 09:15 | <hsivonen> | I think Toby Inkster is the developer of Cognition |
| 09:15 | <othermaciej> | anyway, he still seemed to think there was value in nagging authors (at a non-mandatory level) to add profile when validating Microformats, even though many won't, and nearly all tools ignore it |
| 09:16 | <Hixie> | yes, Cognition was the tool in question |
| 09:16 | <Hixie> | anyway, bed time for me |
| 09:16 | <Hixie> | nn |
| 09:16 | <hsivonen> | how do Microformat validators work anyway, when the formats lack clear authoring conformance criteria? |
| 09:17 | <hsivonen> | nn |
| 09:22 | <Philip`> | hsivonen: I guess the idea is that validator developers make their own decisions about what is useful to warn users about, and can compete on the basis of who has the most useful warnings (i.e. makes it easiest for authors to write content that works in all consumers) |
| 09:24 | <hsivonen> | Philip`: so profile is just one thing thrown out there that validator developers could warn users about or not warn users about? |
| 09:24 | <hsivonen> | Philip`: if warning about it is optional, what upside is there for warning about it? |
| 09:25 | <hsivonen> | I'm glad I'm not on a team implementing OOXML: https://twitter.com/jirkakosek/statuses/5614612516 |
| 09:25 | <hsivonen> | MS must be delighted for letting ISO bikeshed their format. |
| 09:27 | <Philip`> | Maybe there are believed to be some consumers either now or in the future, which would require the profile attribute, and it has approximately zero cost to add so it's considered worthwhile |
| 09:28 | <hsivonen> | it's not a zero cost to have e.g. 10% of authors wondering if they should use a profile and if yes which one(s) |
| 09:32 | Philip` | 's experience with OOXML is largely limited to people sending messages to his college mailing list saying "sorry, this is .docx, hope you can open it" |
| 09:34 | <Philip`> | Real quote: "Therefore, please find attached further information . They are in docx format so hopefully you can all open the attachment !!" |
| 09:35 | <Philip`> | It's always nice when the defining feature of a file format is its incompatibility |
| 09:36 | <hsivonen> | from twitter, it looks like the defining feature of OOXML Strict is to be incompatible--again |
| 09:36 | <Philip`> | That seems okay as long as nobody uses it |
| 09:37 | <hsivonen> | I expect vendors to praise the virtues of OOXML Strict to governments and then selling them OOXML non-Strict systems |
| 09:37 | <hsivonen> | s/selling/sell/ |
| 09:38 | <Philip`> | "Reason for namespace change was to prevent data loss when you open document w/new features in oldapp" - by making it so you lose access to *all* the data when you only have an old app? |
| 09:38 | <hsivonen> | Philip`: my reaction, too |
| 09:39 | <MikeSmith> | hmm, didn't know Rob Pike was at Google now |
| 09:39 | <hsivonen> | IIRC, he has been there for quite a while now |
| 09:40 | <MikeSmith> | yeah, seems so |
| 09:40 | <MikeSmith> | e-mail address is r⊙gc |
| 09:40 | <othermaciej> | re tantek and profile, I did not get a very clear explanation as this seems out of alignment with his positions on most matters, and I was mostly trying to advise him on how to fruitfully make his case in favor of profile |
| 09:42 | <hsivonen> | sometimes I've thought the purpose of @profile for microformats is to have something so that when the RDF folks go "OMG! You don't have URI-based extensibility.", the Microformat community can point at @profile |
| 09:42 | <hsivonen> | and others should just politely ignore it |
| 09:43 | <jgraham> | What's the right word to use when you want to say that something should be an action that takes a system from a fully functional state A to another fully functional state A' rather than to an incomplete state B requiring subsequent actions to reach A' |
| 09:43 | <jgraham> | "atomic" seems close |
| 09:44 | <Philip`> | You could say it "should take a system from a fully functional state A to ... etc" |
| 09:44 | <Philip`> | Then everyone would know what you mean |
| 09:45 | <jgraham> | I could. But I thought there was a word for such a thing. That everyone would know if htey saw it but I couldn't remember going the other way |
| 09:45 | <Philip`> | Maybe call it a "complete change" for short, or something |
| 09:46 | <hsivonen> | transaction? |
| 09:46 | Philip` | can't think of a word either |
| 09:46 | <Philip`> | "Consistency" is probably the database terminology, for transactions that go from one valid state to another |
| 09:47 | <Philip`> | (as in ACID) |
| 09:47 | <jgraham> | "Complete consistent change" sounds nice |
| 09:47 | <jgraham> | Dunno if it is technically right |
| 09:48 | <Philip`> | It's just words, it can mean whatever you want |
| 10:08 | <krisives> | http://santiance.com/2009/11/better-html-form-cryptography/ ? |
| 11:54 | <MikeSmith> | are there any widely deployed browsers that render XML PIs in text/html documents? |
| 11:55 | <MikeSmith> | I'm reading http://www.w3.org/TR/xhtml-media-types/#C_1 |
| 11:56 | <jgraham> | MikeSmith: zcorpan may well know, when he's around |
| 11:56 | <MikeSmith> | OK |
| 11:56 | <hsivonen> | MikeSmith: http://lists.w3.org/Archives/Public/public-xhtml2/2008Sep/0000.html |
| 11:56 | <hsivonen> | "Namely some crappy mobile browsers, AFAIK. |
| 11:56 | <hsivonen> | " |
| 11:57 | <MikeSmith> | ah |
| 11:57 | <hsivonen> | says zcorpan there |
| 11:59 | <MikeSmith> | I notice his comment about IE6 there |
| 11:59 | <MikeSmith> | the presence of the XML declaration puts IE6 into quirks mode? |
| 12:01 | <MikeSmith> | hmm, yeah, I see that it does |
| 12:05 | <gsnedders|work> | MikeSmith, Yeah, I think that'd far more of a concern. |
| 12:05 | <MikeSmith> | yeah |
| 12:06 | gsnedders|work | replies to oolllldddd email |
| 12:06 | <hsivonen> | there probably a crappy mobile browser that breaks for every feature one might think of |
| 12:11 | <jgraham> | gsnedders|work: There's a difference between html5lib having a crappy implementation that has O(N^2) behaviour and the spec mandating O(N^2) behaviour (given the constraint that you can't change your platform string implementation) |
| 12:11 | <gsnedders|work> | The spec wouldn't mandate O(n^2) though. |
| 12:11 | <jgraham> | And your solution doesn't work for incremental parsing |
| 12:12 | <gsnedders|work> | It would mandate O(n^2) no more than it already does for a</x>a |
| 12:13 | <jgraham> | gsnedders|work: How do you fix O(N^2) behaviour for the <table> case without giving up incremental parsing? |
| 12:13 | <jgraham> | And with simple immutable strings> |
| 12:13 | <jgraham> | argh s/>/?/ |
| 12:14 | <jgraham> | s/parsing/rendering/ |
| 12:15 | <gsnedders|work> | How do adjacent text nodes help with the incremental rendering case? You still might need to re-render in the case you find more text, the spec only defines black-box behaviour so if you want to do incremental rendering you could always insert a text node when you hit table to have something (hopefully right) to render. |
| 12:18 | <annevk2> | jgraham, associate multiple strings with one text node? |
| 12:19 | <jgraham> | annevk2: Yeah I guess if you can change the DOM implementation that works |
| 12:19 | jgraham | notes that doesn't work for html5lib\ |
| 12:19 | <annevk2> | fair enough |
| 12:20 | <jgraham> | (it also adds complexity for browsers since you can't necessarily drop the new parser in to the old browser once you have to change other modules) |
| 12:21 | <annevk2> | isn't there some other limit browsers typically hit why most have multiple strings per text node impls? |
| 12:21 | <annevk2> | maybe I'm mistaken |
| 12:21 | <gsnedders|work> | Opera is the only I know of that currently creates multiple text nodes |
| 12:22 | <gsnedders|work> | (and those nowadays are all edge-cases) |
| 12:22 | <jgraham> | Dunno. If browsers already allow multiple string objects to represent a single text node in the DOM then we should revert the spec for sure |
| 12:22 | gsnedders|work | is being stupid agian |
| 12:22 | <gsnedders|work> | *agian |
| 12:22 | <gsnedders|work> | *again |
| 12:22 | <gsnedders|work> | ignore what I said above, I have no idea if it is right |
| 12:22 | <gsnedders|work> | (not even in the Opera case) |
| 12:23 | <annevk2> | keep it up and you might not have a choice next summer :p |
| 12:23 | <gsnedders|work> | When have I ever done anything apart from be stupid? :P |
| 12:24 | gsnedders|work | has never been able to read IRC closely to know what he's actually responding to and normally responds to something that wasn't said |
| 12:24 | hsivonen | think the perf characteristics of the hard requirements of the parsing algorithm should be optimized for languages that have mutable character buffers |
| 12:24 | <gsnedders|work> | (my answer about was referring to multiple text nodes, not how a single text node is represented internally) |
| 12:25 | jgraham | disagrees with hsivonen :) |
| 12:25 | <hsivonen> | (since high-performance implementations will use low-level languages anyway) |
| 12:25 | <jgraham> | Go is a low level language with immutable strings |
| 12:25 | gsnedders|work | thinks they should make sense for both, but favour low-level languages when a choice has to be made |
| 12:25 | <gsnedders|work> | But nobody uses Go. |
| 12:25 | <hsivonen> | I can sympathise with immutable strings in the tree representation |
| 12:26 | <gsnedders|work> | (at least for HTML parsing) |
| 12:26 | <gsnedders|work> | (much) |
| 12:26 | <jgraham> | gsnedders|work: Yet |
| 12:26 | <hsivonen> | but the tree builder's internal buffer shouldn't be immutable in a sane low-level language |
| 12:26 | <jgraham> | gsnedders|work: (for all you know Google have a HTML5 parser in Go) |
| 12:27 | <jgraham> | hsivonen: I'm not sure I agree that sanity -> mutable string type |
| 12:28 | <gsnedders|work> | In Go you would just use slices, as far as I can tell |
| 12:28 | <hsivonen> | if you don't have arrays, I think the language doesn't count as low-level :-) |
| 12:29 | <gsnedders|work> | It has both slices and arrays, and slices are normally used |
| 12:29 | <jgraham> | Right, we could use arrays in python too but it is not very obvious as an approach |
| 12:30 | <jgraham> | (and the data you get out at the other end has to be a string for compatibility with the rest of the world) |
| 12:30 | <hsivonen> | How does Go compare to Sawzall? |
| 12:30 | <jgraham> | (and the case that we care about is very close to the other end) |
| 12:30 | <jgraham> | (since it is about appending data to an existing string in a DOM node) |
| 12:31 | <jgraham> | (and you don't necessarily get a free choice of how your DOM implementaion works) |
| 12:31 | <gsnedders|work> | hsivonen, Do you actually gain anything in Gecko by having adjacent text nodes? |
| 12:31 | <hsivonen> | gsnedders|work: not having to check if there's an adjacent node at insertion time |
| 12:31 | <hsivonen> | that's about it |
| 12:32 | <gsnedders|work> | I guess cases like a</x>a are all fine because of mutable strings |
| 12:32 | <gsnedders|work> | So it's only the foster parenting case that is at all interesting in the low-level case |
| 12:32 | <hsivonen> | and maybe AAA |
| 12:33 | <hsivonen> | or maybe getting it wrong in AAA is just my fault |
| 12:33 | <gsnedders|work> | When do you do string concat in AAA? |
| 12:33 | <hsivonen> | I flush character at the start of the AAA |
| 12:33 | <hsivonen> | which may be bogus |
| 12:34 | <hsivonen> | then I have if (entryPos < listPtr) { |
| 12:34 | <hsivonen> | flushCharacters(); |
| 12:34 | <hsivonen> | } |
| 12:34 | <hsivonen> | in reconstructTheActiveFormattingElements |
| 12:34 | <hsivonen> | which may be bogus, too |
| 12:35 | <hsivonen> | gsnedders|work: it a Gecko integration-level bug that text nodes don't join between document.writes |
| 12:35 | <hsivonen> | *it's |
| 12:36 | <hsivonen> | basically, currently text nodes never join |
| 12:36 | <hsivonen> | once text leaves the tree builder |
| 12:37 | <gsnedders|work> | ah, OK, so not applicable to the general case |
| 12:37 | <hsivonen> | the HTML5 parser in Gecko has a lazily flushed buffer in the tree builder |
| 12:37 | <hsivonen> | like WebKit appears to have if black box behavior is any indication |
| 12:38 | <hsivonen> | except for IE and spec compat, I flush trailing text on document.write |
| 12:38 | <hsivonen> | well, not on trunk yet |
| 12:38 | <hsivonen> | since I haven't been able to land stuff |
| 12:38 | <gsnedders|work> | Why not? |
| 12:39 | <hsivonen> | lack of superreview on the first patch in my queue |
| 12:41 | gsnedders|work | guessed that, so nothing interesting |
| 13:07 | <hsivonen> | does anyone happen to have an alphabetized copy of the HTML5 entity list with non-MathML entities colored differently? |
| 13:08 | hsivonen | wants to work out how often *common* entities share a prefix longer than 2 characters with another entity (where the other entity may be a MathML entity) |
| 13:10 | hsivonen | wishes the mathml entities didn't have some many shared prefixes |
| 13:11 | <hsivonen> | lots of entities starting with "Double", "Left", "Down", etc. |
| 13:12 | <hsivonen> | grr. lots of entities starting with 'lt' |
| 13:12 | <hsivonen> | and 'gt', too |
| 13:13 | <hsivonen> | so much for making the common case easy *and* fast |
| 13:13 | <hsivonen> | things are brighter for amp and nbsp |
| 13:14 | <Philip`> | Someone should measure how common each entity name is |
| 13:14 | <hsivonen> | I think it's safe to assume that lt is common |
| 13:14 | <hsivonen> | so the search strategy shouldn't suck for lt |
| 13:15 | <Philip`> | gsnedders|work: "the following would equally lead to O(n^2) behaviour given the above conditions (i.e., a immutable string type like that of Python)" - no it shouldn't |
| 13:16 | <gsnedders|work> | it shouldn't |
| 13:16 | <Philip`> | The vague idea was that your "insert text node" function should not insert a text node but should build up a list of strings, and your "insert anything except a text node" function should concatenate and flush the list of strings |
| 13:17 | <gsnedders|work> | Right, I know |
| 13:17 | <hsivonen> | gsnedders|work: doesn't html5lib have a lazily-flushed accumulation buffer? |
| 13:17 | <Philip`> | so it would handle the "a</x>a" case because </a> wouldn't cause anything to get inserted, so you wouldn't flush the list |
| 13:17 | <gsnedders|work> | hsivonen, No |
| 13:17 | <hsivonen> | gsnedders|work: whoa. that's bad. |
| 13:17 | <jgraham> | gsnedders|work: We can add one pretty easilly though |
| 13:17 | <gsnedders|work> | jgraham, Indeed. |
| 13:18 | <jgraham> | hsivonen: Not really |
| 13:18 | <jgraham> | It doesn't show up in any profiling runs I remember |
| 13:19 | <jgraham> | (I guess it is bad if someone tries to DOS a html5lib instance but really you can do that jus by feeding it a really long document so I'm not that bothered) |
| 13:19 | <hsivonen> | the HTML5 spec is the DoS use case :-) |
| 13:19 | Philip` | reads the rest of gsnedders|work's email and see that he mentions this stuff already |
| 13:21 | <Philip`> | jgraham: My (ill-informed) view of DOS attacks is that we should fix any situations where the attacker does not have to do an amount of work proportional to the work the parser will perform |
| 13:21 | <Philip`> | You can feed it a really long document but that means you have to use your own time and bandwidth |
| 13:22 | <gsnedders|work> | hsivonen, Most of the profiling we've done is with the spec :P |
| 13:22 | <Philip`> | whereas you can trigger O(n^2) behaviour with a very small amount of input and cause a very large amount of processing in the parser |
| 13:22 | <Philip`> | (where n is the length of the input) |
| 13:23 | <gsnedders|work> | I just don't see the need to have the list of strings _and_ adjacent text nodes when the former can cope with all the problems that html5lib will come across |
| 13:23 | <Philip`> | If you guarantee O(n) behaviour, then it's easy to e.g. limit your input to 1MB and be pretty sure your parser isn't going to take forever or eat all your memory |
| 13:25 | <Philip`> | (That's useful in non-intentional-attack cases like crawling random web pages, too) |
| 13:27 | <Philip`> | ...And that doesn't seem like an unreasonable guarantee to provide, if the parser is just careful about string concatenation and limits the formatting reconstruction clone depth |
| 13:30 | Philip` | decides he probably ought to read and understand emails before commenting on them |
| 13:50 | <TabAtkins> | Just got my Wave invitation. Anyone interested in me sending them an invite? |
| 13:51 | jgraham | has several invites and no friends |
| 13:51 | <jgraham> | Or at least no friends that are interested in using a pre-release version of a new communication platform |
| 13:51 | <TabAtkins> | Hehe. |
| 13:54 | <hsivonen> | when does wave offer invites for sending? |
| 13:55 | <hsivonen> | among my friends from the university, there's a shortage of wave invites and an oversupply of spotify invites |
| 13:56 | <annevk2> | sigh |
| 13:56 | <annevk2> | we should just add MathML entities to XML and be done with it |
| 13:56 | <jgraham> | hsivonen: Dunno, I just got them when I signed up |
| 13:56 | <jgraham> | s/signed up/got my account/ |
| 13:56 | <jgraham> | and got more later |
| 13:57 | hsivonen | didn't get any invites to send out as part of getting his wave account |
| 13:57 | <hsivonen> | or maybe I'm just too inept to figure out the UI for invites |
| 13:58 | <jgraham> | hsivonen: I got a wave called "Invite others to Google Wave" |
| 13:58 | <TabAtkins> | hsivonen: Yeah, I just have a wave with an invite app in it. |
| 13:58 | <jgraham> | Which has a counter of invitations and a box for email address |
| 13:59 | <hsivonen> | ok. I didn't get such a wave |
| 13:59 | <hsivonen> | but now the inbox view went crazy |
| 13:59 | <hsivonen> | even though I'm using the same browser build as earlier today |
| 14:00 | <TabAtkins> | My wave tab is still claiming I have a single unread update. This is a lie. And it's affecting my OCD. >_< |
| 14:00 | <jgraham> | Yeah it is really buggy still |
| 14:00 | <jgraham> | And kinda slow for large waves |
| 14:01 | <hsivonen> | it annoyes me that Google sniffs Minefield as not Firefox |
| 14:01 | <hsivonen> | *annoys |
| 14:01 | jgraham | mumbles something about Opera support |
| 14:10 | <TabAtkins> | annevk2: What's the holdup? The fact that we'd be changing the XML spec as well? |
| 14:11 | <TabAtkins> | Also, Wave has insufficient keyboard accessibility right now. I can't scroll in a wave using up and down. |
| 14:14 | <jgraham> | TabAtkins: wfm |
| 14:14 | <jgraham> | (somewhat) |
| 14:14 | <TabAtkins> | jgraham: ?_? |
| 14:14 | <jgraham> | TabAtkins: I can scroll in a wave using up and down |
| 14:14 | <TabAtkins> | Hrm. |
| 14:14 | <jgraham> | It is not exactly smooth though |
| 14:15 | <TabAtkins> | I can use page-up and -down, but not the arrows. |
| 14:15 | <annevk2> | TabAtkins, the holdup is routing through the XML Core WG and all stakeholders of XML |
| 14:15 | <annevk2> | i.e. a pretty big holdup |
| 14:15 | <annevk2> | anyway, really gotta leave |
| 14:16 | <jgraham> | TabAtkins: You need to get the focus on a message first |
| 14:16 | <TabAtkins> | Makes sense. Also, there's that argument about new predefined entities borking current custom entities. |
| 14:16 | <jgraham> | up/down moves the focus between messages which also causes scrolling |
| 14:16 | <TabAtkins> | jgraham: Nah, I've definitely got the message focused. It has a green border and everything. |
| 14:16 | <jgraham> | TabAtkins: Which browser |
| 14:17 | <TabAtkins> | Chrome 3.0.195.27 |
| 14:22 | <TabAtkins> | Hm, got the erroneous "new update" thing to disappear by filling in my profile. |
| 14:24 | <hsivonen> | what features does Wave use that Opera doesn't have? |
| 14:25 | <jgraham> | hsivonen: AFAICT the problem is that each browser has a specific codepath that uses proprietry features in that browser |
| 14:25 | <jgraham> | s/each/each supported/ |
| 14:26 | <TabAtkins> | That would be automagic from GWT. |
| 14:26 | <hsivonen> | jgraham: :-( I'd have hoped Google knew better than writing to browsers instead of spec features |
| 14:27 | <gsnedders|work> | We don't fire mutation events in designMode documents is the only actual bug of ours |
| 14:27 | <TabAtkins> | Wave was written in Java, though - there is no 'browser' involved. Browsers are just a compilation target. |
| 14:27 | <hsivonen> | so does GWT put a lock on the browser market by effectively preventing new entrants? |
| 14:28 | <TabAtkins> | Probably doesn't help. |
| 14:28 | <gsnedders|work> | It doesn't just prevent new entrants, it blocks existing browsers too |
| 14:28 | <hsivonen> | or do new entrants 'simply' need to fully clone one of the existing engines and spoof its UA string? |
| 14:28 | <gsnedders|work> | hsivonen, That would work |
| 14:28 | <TabAtkins> | I'd call that an effective prevention. |
| 14:28 | <gsnedders|work> | hsivonen, But effectively amounts to the same |
| 14:29 | <gsnedders|work> | hsivonen, It relies upon specific stacktrace formats too! |
| 14:29 | <hsivonen> | why? |
| 14:30 | <jgraham> | hsivonen: Because it can I guess |
| 14:30 | <gsnedders|work> | It somewhat absurd the level of detail it relies upon |
| 14:30 | <jgraham> | If this is typical of the sort of code that GWT produces I would be loathe to use it in production |
| 14:30 | hsivonen | has a hard time coming up for a use case why the run time needs to examine stack traces |
| 14:31 | <hsivonen> | the GWT compiler is pretty cool though |
| 14:31 | <jgraham> | Since there seems to be a high chance of the site breaking with new releases of the same browser, let alone new browsers |
| 14:31 | <hsivonen> | too bad the framework has unhealthy characteristics |
| 14:32 | <gsnedders|work> | The concept is kinda cool, but it's a terrible implementation |
| 14:32 | <TabAtkins> | That's the problem with building a high-level abstraction on top of *another* high-level abstraction. |
| 14:33 | <TabAtkins> | If you move sufficiently far away from the original, you enter the realm of horrifying hacks. |
| 14:33 | <hsivonen> | TabAtkins: well, they *could* feature-sniff it they weren't so concerned about minimizing the .js download sizes |
| 14:33 | <TabAtkins> | True, that much at least would work. |
| 14:33 | <TabAtkins> | And jeez, not like feature-sniffing code is large or anything. |
| 14:34 | <Philip`> | Does there exist a non-web-based Wave client (like in Python or something)? |
| 14:34 | <TabAtkins> | In theory there does. |
| 14:34 | <jgraham> | There is a ruby one |
| 14:34 | <jgraham> | But I think s/client/library/ |
| 14:34 | <jgraham> | I don't think it has a UI or anything |
| 14:34 | gsnedders|work | mumbles something about LysKOM being nearly identical |
| 14:34 | <Philip`> | Not necessarily one that works fully, just one where I could see what happens when sending bogus XML to it |
| 14:34 | <hsivonen> | how does ruby deal with Wave plug-ins? |
| 14:34 | <Philip`> | s/it/the server/ |
| 14:34 | <gsnedders|work> | Philip`, hah |
| 14:35 | <gsnedders|work> | Philip`, I should've guessed :) |
| 14:35 | <hsivonen> | does Wave use XML as the message format? |
| 14:35 | <gsnedders|work> | hsivonen, XMPP, IIRC |
| 14:35 | <gsnedders|work> | Yeah, it uses XMPP + extensions |
| 14:36 | <hsivonen> | ah. so that's why they use a new domain name in the address |
| 14:36 | <hsivonen> | to mint separate XMPP ids for Gmail chat and Wave |
| 14:38 | jgraham | looks at the profile of html5lib he did ealier and notes that inserting text is now a noticable operation in the profile |
| 14:38 | <jgraham> | So maybe it is worth optimising at last |
| 14:38 | <zcorpan> | why isn't "The public identifier is set to: "-//W3O//DTD W3 HTML Strict 3.0//EN//"" instead "The public identifier starts with: "-//W3O//DTD W3 HTML Strict 3.0//""? |
| 14:39 | <zcorpan> | and "-/W3C/DTD HTML 4.0 Transitional/EN" |
| 14:39 | <mpilgrim> | there are no clients for google wave |
| 14:39 | <mpilgrim> | yet |
| 14:39 | <TabAtkins> | I think I will call it "gwave", and try to pronounce it like that without giggling. |
| 14:39 | <mpilgrim> | all the work on standardizing the protocol ( http://www.waveprotocol.org/ ) is about building your own server |
| 14:39 | <mpilgrim> | not your own client |
| 14:40 | <mpilgrim> | the way the client communicates with the server is currently undefined |
| 14:40 | <mpilgrim> | or rather, is defined solely by the web-based implementation |
| 14:40 | <mpilgrim> | this is a TODO |
| 14:40 | <jgraham> | How can you build a server if the way the client communicates with it is undefined? |
| 14:41 | <Philip`> | mpilgrim: When I said "client" I may have meant "server" |
| 14:41 | <mpilgrim> | you can build servers that communicate with other servers |
| 14:41 | <mpilgrim> | it's a federated protocol (like XMPP that it builds on) |
| 14:42 | <Philip`> | since I meant whatever it is that can communicate with Google's code over XMPP |
| 14:42 | <mpilgrim> | i understand about half the words i just typed |
| 14:42 | <mpilgrim> | i'm mostly repeating what i learned at the google developer day talk about wave earlier this week |
| 14:42 | <jgraham> | Servers that don't talk to clients don't sound all that interesting. But maybe there is some magic in the word "federated" that makes them interesting |
| 14:42 | <gsnedders|work> | So basically you're as ignorant as all of us? :P |
| 14:42 | <mpilgrim> | i may be missing something important |
| 14:43 | <Philip`> | I probably should have asked: Does there exist a vaguely usable open-source implementation of the Google Wave Federation Protocol? |
| 14:43 | <mpilgrim> | but i have been told that non-googlers have successfully deployed servers that talk to google's server |
| 14:43 | <mpilgrim> | i'm just not sure what they talk about |
| 14:43 | <Philip`> | jgraham: You build the server and the client |
| 14:43 | <Philip`> | jgraham: and don't need a standard between them |
| 14:44 | <mpilgrim> | philip`: that would be available at http://www.waveprotocol.org/ |
| 14:44 | <Philip`> | jgraham: but you do have a standard between servers and servers, so clients can talk to each other |
| 14:44 | <hsivonen> | jgraham: you can substitute a Novell server |
| 14:44 | <mpilgrim> | which, apparently, links to http://code.google.com/p/wave-protocol/source/checkout |
| 14:44 | <mpilgrim> | and now you know more than i do |
| 14:44 | <hsivonen> | jgraham: but the way your browser talks to the Novell or Google servers is an implementation detail, I guess |
| 14:45 | <Philip`> | mpilgrim: I was hoping there was one that wasn't Java :-) |
| 14:45 | <mpilgrim> | ah |
| 14:45 | <mpilgrim> | you realize it was written in java, yes? |
| 14:45 | <Philip`> | and also I failed to notice there was a Java one |
| 14:45 | <Philip`> | (even though I already downloaded that code months ago) |
| 14:45 | <Philip`> | (and then forgot) |
| 14:45 | <mpilgrim> | hsivonen: the way your browser talks to the Novell or Google servers is, currently, an undefined implementation detail, yes |
| 14:45 | <hsivonen> | whenever I watch a Google presentation on anything Java-related, it all always looks more patterny than what I've even handled |
| 14:46 | <Philip`> | mpilgrim: I realise that one was written in Java, but hoped someone else might have made a nice simple easily-hackable one in Python or something |
| 14:46 | <mpilgrim> | google has publicly stated that we plan to document it |
| 14:46 | <mpilgrim> | i don't think i've ever heard a timeline for that, though |
| 14:46 | <hsivonen> | s/even/ever/ |
| 14:46 | TabAtkins | just realized that mpilgrim works for Google. |
| 14:46 | <gsnedders|work> | TabAtkins, You slow old man :P |
| 14:47 | <hsivonen> | GWT apps seem to be incredibly patterny |
| 14:47 | mpilgrim | reserves comment, since i don't know who most of you work for either |
| 14:47 | <hsivonen> | it's a bit intimidating |
| 14:47 | <gsnedders|work> | Well, I'm at work. |
| 14:47 | <hsivonen> | (being patterny--not not knowing who works for whom) |
| 14:47 | <TabAtkins> | And I work for someone irrelevant. |
| 14:47 | <zcorpan> | gsnedders|work: go back to doing work |
| 14:47 | <gsnedders|work> | zcorpan, Sorry Daddy. |
| 14:48 | mpilgrim | also... wisely... reserves comment on GWT in general |
| 14:48 | <zcorpan> | gsnedders|work: good boy |
| 14:48 | <mpilgrim> | this conversation has taken a disturbing turn |
| 14:48 | <gsnedders|work> | zcorpan, Now you go back to doing work too. |
| 14:49 | <zcorpan> | good point |
| 14:50 | <mpilgrim> | paul_irish: what are your post-1.0 plans for modernizr? |
| 14:51 | <paul_irish> | hey mpilgrim |
| 14:51 | <paul_irish> | lemme pull up those for ya |
| 14:51 | <TabAtkins> | paul_irish keeps his plans in a vault. |
| 14:51 | <paul_irish> | :) i just committed tests for localstorage, webworkers, and applicationcache. |
| 14:52 | <paul_irish> | additionally we now have tests for video/audio formats.. Modernizr.video.mp4 etc |
| 14:52 | <mpilgrim> | hooray |
| 14:52 | <jgraham> | In a well, if he's pulling them up |
| 14:52 | <paul_irish> | input placeholders and autofocus are also in |
| 14:52 | mpilgrim | checks his notes too |
| 14:52 | <paul_irish> | as well as plugin mechanism for adding new tests |
| 14:52 | <gsnedders|work> | How do you cope with CSS3 properties that are prefixed in implementations? Do you have to manually add each prefixed version of each property? |
| 14:52 | <paul_irish> | yup. |
| 14:52 | <gsnedders|work> | Ow. |
| 14:53 | <mpilgrim> | how about <input required> ? |
| 14:53 | <mpilgrim> | <input autocomplete> ? |
| 14:53 | <mpilgrim> | and <input pattern> ? |
| 14:53 | <gsnedders|work> | Seeming people will probably use out of date versions of Modernizr for far too long, if we add -o-amazing-new property and it only checks for -moz-amazing-new-property then we keep using a non-native version, which sucks |
| 14:54 | <paul_irish> | mpilgrim: no we don't have some form stuff that i still want. required/pattern/autocomplete are not in, but i'll add autocomplete to the ticket to track. |
| 14:55 | <paul_irish> | also there's a lot of demand for svg tests.. svg clip paths and such. that'd be a nice addition to 1.5 |
| 14:55 | gsnedders|work | wonders how well just having a list like, "-moz-", "-o-", "-webkit-" etc. would work and trying all of them |
| 14:55 | hsivonen | much prefers Modernizr to GWT's macro-level handful of code paths |
| 14:55 | <gsnedders|work> | That might break when the spec changes under the prototype impls though |
| 14:55 | <mpilgrim> | btw, loved your recent post about defeating the FOUT |
| 14:55 | <hsivonen> | URL? |
| 14:55 | <paul_irish> | and then the other ones i'm tracking are postMessage / open/webDatabase, hashchange support, and html54 drag n drop |
| 14:56 | <gsnedders|work> | hsivonen, Likewise, as all browsers get the same code path and should be able to change over time |
| 14:56 | <mpilgrim> | http://paulirish.com/2009/fighting-the-font-face-fout/#defeatthefout |
| 14:56 | hsivonen | would prefer WebKit just fixing their @font-face behavior |
| 14:56 | <hsivonen> | mpilgrim: thanks |
| 14:56 | mpilgrim | would actually prefer that firefox change their implementation to match webkit |
| 14:56 | <paul_irish> | gsnedders|work: http://github.com/Modernizr/Modernizr/blob/master/modernizr.js#L120 we test all the vendor specific as well as the non-prefixed |
| 14:56 | <mpilgrim> | but neither seems likely |
| 14:57 | <hsivonen> | oh. it's doing the opposite that I want |
| 14:57 | <gsnedders|work> | paul_irish, Ah, OK, I meant by what I asked earlier if you did that |
| 14:57 | <hsivonen> | I get complaints that my site is slow to become readable in WebKit |
| 14:57 | <hsivonen> | since all the fonts are @font-face |
| 14:57 | <mpilgrim> | dude, your site is slow because you have like 5 MB of fonts |
| 14:58 | <mpilgrim> | subsetting a little wouldn't kill you |
| 14:58 | <paul_irish> | yah the mozilla bug tracking FOUT is leaning in a direction that text will be invisible, but it'll go to fallback font if it thinks the delay will be "long" |
| 14:58 | <paul_irish> | no patches landed yet |
| 14:58 | <hsivonen> | mpilgrim: then I'd have to re-subset when I write something with a new character |
| 14:58 | <gsnedders|work> | paul_irish, I'd add all the prefixes now listed in CSS 2.1 |
| 14:58 | <hsivonen> | mpilgrim: works for me in Fennec even |
| 14:58 | <gsnedders|work> | paul_irish, http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords |
| 14:59 | <paul_irish> | gsnedders|work: oh nice! hot tip. thank you |
| 14:59 | <mpilgrim> | on diveintohtml5.org, i subset to A-Za-z0-9 plus a few punctuation characters and other fancy typographical characters |
| 14:59 | <mpilgrim> | shaved quite a bit off of the font sizes |
| 15:01 | <mpilgrim> | specifically, these characters: http://hg.diveintohtml5.org/hgweb.cgi/file/tip/fonts-original/chars |
| 15:01 | TabAtkins | is satisfied to see … on that list. |
| 15:01 | <paul_irish> | mpilgrim: http://github.com/Modernizr/Modernizr/blob/master/modernizr.js is the latest.. i think it now picks up all the remaining tests from your detect chapter. |
| 15:01 | <mpilgrim> | yay |
| 15:01 | <mpilgrim> | release it and i'll update the text |
| 15:02 | <mpilgrim> | you have until december 11th |
| 15:02 | <mpilgrim> | then we're freezing for print |
| 15:02 | <paul_irish> | certainly. you'll be the first to know. |
| 15:02 | <paul_irish> | Oh excellent. we can do that. |
| 15:03 | <mpilgrim> | excellent |
| 15:03 | <mpilgrim> | i love it when a plan comes together |
| 15:03 | <mpilgrim> | now if you'll excuse me, i need to go spend 8 hours on a plane |
| 15:03 | <mpilgrim> | seeing as how i am (STILL!) on the wrong side of the atlantic |
| 15:03 | <paul_irish> | enjoy |
| 15:03 | <TabAtkins> | You should have gotten on those wifi planes. |
| 15:03 | <TabAtkins> | Then you could be with us forever. |
| 15:04 | <Philip`> | hsivonen: Subsetting to exactly the characters used on your pages seems like a very 1990s notion, when Win-1252 fonts were unbearably large :-) |
| 15:05 | <Philip`> | Now you can just strip out Greek and Cyrillic and CJK and whatever, and get large savings without losing anything useful |
| 15:06 | jgraham | wonders what will happen if hsivonen ever wants to use a non-BMP character |
| 15:06 | <Philip`> | Then it can use the fallback font |
| 15:06 | <hsivonen> | I have some Polish content on my site |
| 15:06 | <jgraham> | But it will look ugly! |
| 15:07 | <hsivonen> | so I'd have to cover that |
| 15:07 | <hsivonen> | in general, subsetting and failing to include all Latin characters actually used leads to mighty ugliness |
| 15:07 | <hsivonen> | using a fallback font for a random math symbol might be bearable |
| 15:09 | <Philip`> | That's easy to solve by including all Latin characters |
| 15:11 | <hsivonen> | is the current story of inherent security vs. policy-dependance for DAP deliverables documented somewhere? |
| 16:20 | <TabAtkins> | Are the latest firefox nightlies 3.6b2, or 3.7a1? |
| 16:21 | <karlcow> | TabAtkins: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ |
| 16:22 | <TabAtkins> | Danke. I never find that page easily when I google for it. Bookmarking now. |
| 16:41 | <GPHemsley> | <3 HTML5 validator, which actually complains about things that are important |
| 16:41 | <GPHemsley> | (and tells you why) |
| 16:42 | <ment> | like "It seems you are trying to parse JPEG image." ? |
| 16:50 | <GPHemsley> | and stuff like "this row only had 2 cells, but it should have had 4" |
| 16:51 | <GPHemsley> | though I am wondering what it means by "at this point" regarding attributes that aren't allowed |
| 16:52 | <GPHemsley> | "end tag for element "HEAD" which is not open" vs. "Stray end tag head." is nice |
| 17:03 | <TabAtkins> | Oh god how am I freezing FF with this I don't even know. |
| 17:03 | <TabAtkins> | Or wait - yes I do. Silly me. |
| 17:12 | <Philip`> | "most programmers do not want draconian error handling where automatic recovery might be possible. Thus why, for instance, assert() is usually a no-op in production builds." - I thought assert was a no-op in production builds primarily because of (unjustified) performance concerns |
| 17:15 | <TabAtkins> | Well, that *too*, but really, do you *want* your production builds to error out on a bad assertion? |
| 17:16 | <Philip`> | Yes |
| 17:16 | <Philip`> | since failed assertions sometimes lead to security vulnerabilities |
| 17:22 | Philip` | is reminded of the people who made invalid pointer reads (in C/C++ programs) return 0 instead of crashing, and found that most programs worked fine with that kind of error recovery |
| 17:22 | <Philip`> | but the idea hasn't really caught on |
| 17:23 | <Philip`> | C++ compilers have been adding more draconian features, in fact |
| 17:23 | <Philip`> | like checking for stack corruption |
| 17:23 | <Philip`> | and enabling it by default in production builds |
| 17:45 | jgraham | hopes someone else will explain that XML parsers/serializers are observed to have bugs and that the oppertunity cost of making your site bulletproof against XML errors is rather poor given that it has almost no tangible benefits v just using HTML |
| 17:49 | <Philip`> | But what if you're using your web page for financial transactions and are too lazy to include a checksum? |
| 17:50 | <jgraham> | You are an idiot? |
| 17:50 | <jgraham> | And likely have bigger problems |
| 17:51 | <Philip`> | Also, how's that relevant for XML vs HTML, given that random errors are likely to occur in content and not cause syntax errors? |
| 17:51 | <jgraham> | That example? |
| 17:51 | <jgraham> | No idea |
| 17:58 | Philip` | supposes public-html doesn't really need another draconianness debate in any case |
| 19:13 | <Philip`> | gsnedders: You might want to update http://wiki.whatwg.org/wiki/Parser_tests if you changed the test format |
| 20:54 | <jgraham> | gsnedders: yt? |
| 21:42 | <annevk2> | hmm, short URL fail: http://bit.ly/4e1BSG |
| 21:42 | <hamcore> | why fail? |
| 21:43 | <hamcore> | it goes to http://html5.org/ |
| 21:43 | <annevk2> | because it's longer, not shorter |
| 21:43 | <annevk2> | duh |
| 21:44 | <annevk2> | oh lolz |
| 21:44 | <annevk2> | someone is yet again bringing up the stupid bank example in relation to the merits of draconian error handling |
| 21:45 | <Steve^> | is that the stupid [bank example] or the [stupid bank] example? |
| 21:46 | <hamcore> | annevk2 oh, sure. |
| 21:46 | <ment> | jgraham: where is the go html5 parser? all i see is some weird xml/html4 parser |
| 21:48 | <annevk2> | Steve^, the former |
| 21:49 | <annevk2> | the flaws with the example have been discussed to some extent on http://www.tbray.org/ongoing/When/200x/2007/01/30/XML-2 |
| 21:49 | <annevk2> | of course since it has been given since like '97 it is understandable not everyone has caught up with this yet |
| 21:55 | <Hixie> | annevk2: ignore DATAGRID_ERR |
| 21:55 | <Hixie> | if we redo datagrid i'll reassign a number for it |
| 21:56 | <annevk2> | kk |
| 21:57 | <annevk2> | i dislike the way XHR does exceptions btw |
| 21:57 | <annevk2> | throwing for non-author errors makes for such a lame API |
| 22:01 | <Steve^> | one wonders why a bank would send transactions in HTML |
| 22:01 | <Hixie> | or unsigned XML |
| 22:02 | <Hixie> | if the message can get truncated, it can probably also get modified |
| 22:02 | <Steve^> | maybe if we swapped from <> to [] people wouldn't compare so much |
| 22:03 | <annevk2> | or moreover, unvalidated XML |
| 22:03 | <annevk2> | validation seems like a pretty basic requirement if you really want to make sure it is the right message |
| 22:04 | <Hixie> | dude if you're transferring millions of euros, you had better be signing the data or doing some other kind of reliability guarantee |
| 22:05 | <Hixie> | well-formedness isn't going to cut it |
| 22:06 | Steve^ | wonders if the HTML5 draft gets signed before being sent to important people |
| 22:09 | <Dashiva> | Is the bank also using RDFa to authenticate and authorize the transaction, I wonder :) |
| 22:09 | <Philip`> | Steve^: It gets sent through loads of preprocessing steps on loads of servers that are of unascertained security, before being sent to any people at all, so it'd be pretty easy to sneak something into the published document |
| 22:10 | <Steve^> | Philip`, what's the password? |
| 22:11 | <Philip`> | Steve^: It's not *that* easy :-p |
| 22:12 | <Steve^> | Philip`, I hoped you'd be celebrating beer wednesday or something. worth a shot |
| 22:12 | <Dashiva> | "Given high enough density of hashmarks almost anything is valid Perl" |
| 22:24 | <TabAtkins> | Steve^: I'll get Philip` to celebrate Liquor Friday with me. Hit him up then. |
| 23:27 | <MikeSmith> | as far as the parsing algorithm, an element with a plus sign in it is not an error, right? |
| 23:28 | <Dashiva> | In it? In the element name? |
| 23:28 | <MikeSmith> | Dashiva: yeah |
| 23:29 | <MikeSmith> | e.g., <foo+bar> |
| 23:29 | <Dashiva> | It is |
| 23:29 | <MikeSmith> | ah |
| 23:29 | <Philip`> | MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tag-name-state says it's not a parse error |
| 23:29 | <Philip`> | or, rather, doesn't say it is a parse error |
| 23:29 | <Hixie> | it shouldn't be a _parse_ error, no |
| 23:30 | <Hixie> | 'course since there's no foo+bar element, it's still an error |
| 23:30 | <Dashiva> | Right, that's a much more useful answer |
| 23:30 | <MikeSmith> | OK |
| 23:42 | <Philip`> | MikeSmith: (I do hope you're not planning to use + in an element name) |
| 23:43 | <MikeSmith> | Philip`: I was asking in context of a message Jonathan Rees posted to www-tag yesterday |
| 23:46 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-tag/2009Nov/0015.html |
| 23:47 | <Philip`> | Ah |
| 23:47 | <MikeSmith> | this part: |
| 23:47 | <MikeSmith> | [[ |
| 23:47 | <MikeSmith> | For example, one might say that addition of new elements and |
| 23:47 | <MikeSmith> | attributes is likely to happen, but not changes in the lexical syntax |
| 23:47 | <MikeSmith> | such as the addition of something like <% .... %> or allowing + in |
| 23:47 | <MikeSmith> | element names. |
| 23:47 | <MikeSmith> | ]] |
| 23:50 | <MikeSmith> | seems like he was stating that as a example of a type of syntax restriction |
| 23:52 | <MikeSmith> | maybe part of the answer should be, there are no existing arbitrary syntax restrictions like that -- instead there are only things that generate parse errors and things that are do not |
| 23:52 | <MikeSmith> | -are |
| 23:52 | <Hixie> | there are some arbitrary restrictions |
| 23:52 | <Hixie> | like unquoted attributes can't contain ` |
| 23:52 | <Hixie> | because of potential security problems with IE |
| 23:52 | <MikeSmith> | I see |
| 23:53 | <MikeSmith> | so maybe I can make up a list of those |
| 23:54 | <MikeSmith> | that seems in part at least to be what he's wondering about |
| 23:54 | <MikeSmith> | that is, the bounds on what can be changed in the syntax and what can't be |
| 23:56 | <Hixie> | i dunno |
| 23:56 | <Hixie> | we can probably add new syntax |
| 23:56 | <Hixie> | it'd just be somewhat painful |
| 23:57 | <Hixie> | and we can add anything that is currently a bogus comment pretty easily |
| 23:57 | <Hixie> | e.g. we could add <% ... %> so long as "..." can never be ">" |
| 23:58 | <Hixie> | we could add <!start range selection> ... <!end range selection> |
| 23:58 | <Hixie> | so other things like that |
| 23:58 | <MikeSmith> | Hixie: I realize the first two points. but it seems like things such as the restriction on unquoted attribute values containing ' that really can't be changed practically changed at this point |
| 23:58 | <Hixie> | unquoted attribute values only can't contain ' because it's confusing |
| 23:59 | <MikeSmith> | eh? I thought you just said it was an IE security issue? |
| 23:59 | <Hixie> | that's ` |
| 23:59 | <Dashiva> | That was ` |
| 23:59 | <Hixie> | not ' |
| 23:59 | <MikeSmith> | ah |