| 00:02 | annevk3 | wonders if the testcase format for Validator.nu is described somewhere |
| 00:02 | <annevk3> | in case I suddenly get interested in making polyglot tests, that is |
| 00:04 | <Lachy> | annevk3, I suppose you could just make them in the format used by html5lib, and then it should be fairly easy to convert to a different format if needed |
| 00:04 | <annevk3> | oh wow |
| 00:04 | <annevk3> | that latest bug report is awesome |
| 00:05 | <annevk3> | JavaScript people are corporate lol |
| 00:06 | <Lachy> | this one? [Bug 7547] New: on .drawImage() negative widths or heights should flip/mirror the image. There's no easy way of fliping images in canvas |
| 00:06 | <Lachy> | that's the latest one I have |
| 00:09 | <annevk3> | latest in yesterday's #html-wg logs then |
| 00:10 | <Lachy> | oh, that one. I was working on a reply to that. Not sure if I'll actually respond yet |
| 00:11 | <annevk3> | I take it you're bored? :) |
| 00:13 | <Lachy> | not really, I was doing several things at the same time |
| 00:14 | <Lachy> | just thought it would be useful to explain to him why having the spec defined in terms of the DOM was a good thing overall that made things simpler, not more complex |
| 00:19 | <and> | Is this the right channel for html5lib? |
| 00:19 | <Hixie> | yes |
| 00:19 | <tantekc> | Lachy - yeah, it's unfortunate, but better than inventing yet-another-abstraction (<cough>Infoset</cough) |
| 00:20 | <tantekc> | because of course, inventing yet another abstraction doesn't confuse anyone right? |
| 00:23 | <and> | Thanks. I have started to implement the tokeniser, and the tests in html5lib seem useful. However, I would like to make it stand-alone (i.e., possible to use without a treebuilder), and I did not find any tests for the transition to RCDATA or RAWTEXT. Are there any, or is the assumption that a real treebuilder has to be used for that? |
| 00:24 | <annevk3> | the tests only cover what can happen in practice |
| 00:25 | <annevk3> | oh wait |
| 00:25 | <and> | It seems possible to run the tokeniser without a real treebuilder. The only real problem seems to be foreign content inside HTML inside foreign content, but I have not really tried to figure out how that works. |
| 00:25 | <annevk3> | the assumption is that you need a treebuilder to switch that flag |
| 00:26 | <annevk3> | there should be tests that set the flag to an initial state and then test if things are tokenized correctly |
| 00:26 | <and> | Fair enough. Any intuition regarding how much of the treebulder is needed to get the tokenisation right? |
| 00:26 | <gsnedders> | Is there any reason why that can't be done in the tokenizer? Are there any cases where it's hard to tell whether it should be changed or not? |
| 00:26 | gsnedders | has been meaning to look into this for ages |
| 00:27 | <gsnedders> | Anyhow, time for my to get six hours sleep (ergh) |
| 00:27 | <annevk3> | i think the implementations made so far both decided it would be best in the treebuilder |
| 00:27 | <and> | Nested foreign content seems to be the only obvious problem. |
| 00:27 | <annevk3> | because it effectively depends on the tag name |
| 00:28 | <and> | (If I am right in thinking that the RCDATA and CDATA states are only reached after a corresponding start token.) |
| 00:28 | <and> | Yes, but there are just a handful of elements with CDATA/RAWTEXT or CDATA content, so that seems easy to add. |
| 00:29 | <and> | *CDATA/RAWTEXT or RCDATA |
| 00:31 | <annevk3> | and, true, I think the design of the existing implementations influenced the tests here |
| 00:31 | <annevk3> | though I might be missing something, been a while since I played with the parser |
| 00:32 | <and> | Sure. Thanks for the information. |
| 00:41 | <Hixie> | and: you can't know if you'll be switching mode without a tree |
| 00:41 | <Hixie> | and: because sometimes start tag tokens are just dropped on the floor without switching |
| 00:43 | <and> | Hixie: "Sometimes"? Does this happen outside of foreign contents as well? |
| 00:43 | <and> | s/ as well// |
| 00:44 | <annevk3> | yeah |
| 00:44 | <annevk3> | <select> <style> xx </select> xx |
| 00:44 | annevk3 | forgot |
| 00:44 | <annevk3> | only <script> is dealt with inside <select> |
| 00:44 | <annevk3> | <style>, <xmp>, <title>, <plaintext>, etc. are dropped on the floor |
| 00:48 | <and> | Right. The real question, then, is how much of the treebuilder can be ignored if the goal is not to build a tree or DOM, and the answer may not be easy to extract from the spec. |
| 00:51 | <Hixie> | and: what's the goal? |
| 00:54 | <tantek> | if the goal is just to not build a tree or DOM, one answer would be NOP. ;) (defining things in terms of negatives - what they're not - is usually unproductive) |
| 00:54 | <and> | Hixie: One goal would be to look at tokenisation of character references without the treebuilder overhead, but implementing a part of the treebuilder is probably not a good idea if a substantial part is required anyway. |
| 00:56 | annevk3 | figures out who and is by /whois |
| 00:56 | <annevk3> | welcome! |
| 00:56 | <and> | Thanks! |
| 00:59 | <annevk3> | still waiting to hear back on encodings from the two missing browsers; guess I'll ping them tomorrow |
| 00:59 | <othermaciej> | what's the encoding question? |
| 01:00 | <annevk3> | othermaciej, trying to fill out the tables in http://wiki.whatwg.org/wiki/Web_Encodings |
| 01:00 | <annevk3> | i.e. which encodings are shipping with Safari and what aliases are recognized and which matching algorithm is used to see if labels well, match |
| 01:01 | <Hixie> | and: you mean for a study? |
| 01:01 | <Hixie> | and: i think you'll end up needing a full tree builder, even if it just throws out the DOM it's creating |
| 01:01 | <Hixie> | and: (the tree builder only uses internal data structures, it doesn't need the output iirc) |
| 01:02 | <mpilgrim> | erlehmann: of course the XHTML side is shorter |
| 01:03 | <mpilgrim> | "fail at first error" is shorter than "parse billions of pages of existing web content according to the following 200-page algorithm" |
| 01:03 | <annevk3> | i'd still like to see a never-failing SAX API for HTML defined one day (where you end up with graphs I guess) |
| 01:04 | <mpilgrim> | i was under the impression that a SAX-like API would be difficult due to reparenting, adoption, whatever |
| 01:04 | <annevk3> | for quite a few non-browser use cases that would actually be better than a DOM-based API I think |
| 01:04 | <mpilgrim> | there are non-browser use cases? |
| 01:05 | <mpilgrim> | someone's been falling for roy fielding's bullshit |
| 01:05 | <annevk3> | mpilgrim, yeah, you'd need a distinct conformance class for such an API that can do other things there |
| 01:05 | <othermaciej> | annevk3: of the unanswered questions asked on the wiki, I know we use the system version of ICU on Mac, and we do use TEC on Mac only for extra encodings that are not in ICU |
| 01:05 | <and> | Hixie: Yes, I tried to look at the http://www.dotnetdotcom.org/ dataset, which seems to support my suspicion about the current handling of unterminated character references not being an ideal match for existing pages, but the results are rather too noisy since it is difficult to distinguish between attribute values and text without a parser. |
| 01:05 | <mpilgrim> | ooh, there's an encoding wiki now? where? |
| 01:06 | mpilgrim | reads the backscroll and retracts the question |
| 01:06 | <annevk3> | and, maybe use the Validator.nu HTML parser? |
| 01:06 | <annevk3> | othermaciej, and on Windows? |
| 01:07 | <othermaciej> | annevk3: our matching algorithms used to be case insensitive match ignoring addition or removal of underscores or hyphens |
| 01:07 | <othermaciej> | annevk3: I think we might use ICU's matching now for at least some encodings; not sure |
| 01:07 | <Hixie> | and: yeah |
| 01:07 | <othermaciej> | annevk3: on Windows we ship our own ICU and don't support any non-ICU encodings |
| 01:07 | <annevk3> | cheers |
| 01:08 | <and> | annevk3: I was hoping to get away with something more lightweight, but that is indeed a possible solution. |
| 01:13 | <othermaciej> | annevk3: more specifically, our encoding name comparison is: |
| 01:13 | <othermaciej> | "Hash for all-ASCII strings that does case folding and skips any characters that are not alphanumeric." |
| 01:14 | <othermaciej> | so it will ignore any extra non-alphanumeric characters, which might be more lenient than is needed |
| 01:14 | <annevk3> | sounds like UTS22 |
| 01:14 | <annevk3> | I think it's actually causing you compat problems just like us |
| 01:15 | <othermaciej> | that's possible |
| 01:15 | <othermaciej> | TextEncodingRegistry.cpp is the file in our source tree that's responsible for creating all the text encoding name maps |
| 01:15 | <annevk3> | on crazy sites that specify EUC_JP in HTTP but are actually UTF-8 yet we recognize them as EUC-JP because of UTS22 whereas Firefox and IE don't |
| 01:17 | <othermaciej> | that's crazy |
| 01:19 | <othermaciej> | TextCodecICU::registerExtendedEncodingNames includes most of the aliases we add on top of ICU |
| 01:19 | <othermaciej> | Latin-1 and UTF-16 have hardcoded special-case codecs |
| 01:21 | <othermaciej> | for Latin-1 we register a whole lot of aliases for ISO-8859-1, windows-1252, and US-ASCII; we consider the three technically different but decode all three as WinLatin1 |
| 01:22 | <othermaciej> | similarly we have a lot of aliases for UTF-16LE and UTF-16BE |
| 01:39 | <annevk3> | ta othermaciej, added some notes to look at this later |
| 05:59 | <mpilgrim> | http://diveintohtml5.org/detect.html |
| 05:59 | <mpilgrim> | feedback welcome |
| 05:59 | <mpilgrim> | (other than "it looks like shit in opera 10," which i already know about) |
| 06:01 | <roc> | where did you get these fonts? |
| 06:01 | <cardona507> | that looks good to me - nice fonts |
| 06:01 | <roc> | the page looks fantastic to me |
| 06:01 | <mpilgrim> | roc: http://diveintohtml5.org/about.html has links |
| 06:04 | <roc> | thanks |
| 06:05 | <roc> | I wish all your graphics were SVG, but nonetheless, great page |
| 06:06 | <mpilgrim> | the SVG versions are much much larger |
| 06:07 | <mpilgrim> | as they are basically created from scans of old books |
| 06:07 | <mpilgrim> | so not terribly optimized as far as vector graphics go |
| 06:08 | <mpilgrim> | anyway, thanks for the kind words |
| 06:08 | <mpilgrim> | if anyone has any technical corrections or stumbles across any bugs in the dynamic content, please let me know |
| 07:35 | <hsivonen> | the deadlock discussion makes me think NPAPI lets plug-ins do too many things |
| 07:42 | <hsivonen> | mpilgrim: Are you intentionally giving your readers the impression that Geolocation is an HTML5 feature? |
| 07:45 | <hsivonen> | mpilgrim: I see the Q & A now |
| 07:46 | <boblet> | mpilgrim: the position of the Canvas API support statement below the illustration made me think the illustration was done via Canvas. Also you’re using “HTML 5”, but I assume that’s intentional. Other than that informative and looks great |
| 07:48 | <hsivonen> | Hixie: even mpilgrim isn't using <figure>/<legend> yet. Maybe we really need to change the <legend> part to <c> or something |
| 07:49 | <hsivonen> | mpilgrim: Video for Everybody! requires authors to use a soon-to-be-royalty-bearing format |
| 07:49 | <Hixie> | hsivonen: i really don't understand what the rush is |
| 07:50 | <Hixie> | hsivonen: i wasn't expecting anyone to use 90% of this stuff for another decade |
| 07:50 | <hsivonen> | Hixie: is using <legend> instead of <c> worth the wait? |
| 07:50 | <Hixie> | yes |
| 07:50 | <cardona507> | another decade? |
| 07:51 | <hsivonen> | Hixie: for what benefit? avoiding the minting of another element |
| 07:51 | <hsivonen> | Hixie: when you then go ahead and mint stuff like <dialog> |
| 07:52 | <Hixie> | hsivonen: <c> is a dumb name. <legend> is the exact right name. |
| 07:52 | <hsivonen> | mpilgrim: congrats for figuring out the codecs parameters for H.264 |
| 07:53 | <hsivonen> | mpilgrim: unfortunately, they are unlikely to be correct for video that your readers might encode |
| 07:53 | <hsivonen> | profiles and AVC levels FTW! |
| 07:55 | tantek | thinks <dialog> is a dumb name for a conversation, and there's scant data to legitimize a misconceived offhand informative example from HTML4 (dt/dd for conversations). |
| 07:56 | <Hixie> | tantek: is zeldman done collecting the feedback from his blog commenters yet? :-) |
| 07:57 | <hsivonen> | why does this stuff look like COM instead of looking like JS or even Java? http://www.forum.nokia.com/infocenter/index.jsp?topic=/Web_Developers_Library/GUID-4DDE31C7-EC0D-4EEC-BC3A-A0B0351154F8.html |
| 07:59 | <MikeSmith> | the think I like the least about it <dialog> is that its addition causes the semantics of the <dt> and <dd> elements to change drastically depending on what their parent element is. which seems like very suboptimal language design. |
| 07:59 | <Hixie> | MikeSmith: why? |
| 08:00 | <hsivonen> | Hixie: are you planning on saying anything about cruft in SVG subtrees? |
| 08:00 | <MikeSmith> | Hixie: because elements should have consistent semantics unless there's some really good reason for them not too |
| 08:00 | <Hixie> | hsivonen: dunno, what's the question? |
| 08:01 | <othermaciej> | are there other cases in HTML where semantics change significantly based on the parent element? |
| 08:01 | <Hixie> | MikeSmith: why? |
| 08:01 | <hsivonen> | Hixie: whether the cruft should be conforming despite being bogus |
| 08:01 | <othermaciej> | I would say semantics of <li> change depending on the parent |
| 08:01 | <Hixie> | hsivonen: sounds like an SVG issue, why would I say anything? |
| 08:01 | <othermaciej> | it's a list item in both <ul> and <ol>, but in the latter case it implies an ordering position |
| 08:01 | <MikeSmith> | Hixie: because it's easier for authors |
| 08:01 | <hsivonen> | Hixie: you caused the cruft to become non-conforming per SVG |
| 08:02 | <hsivonen> | Hixie: before you did your thing, SVG was coherent on this particular point |
| 08:02 | <tantek> | Hixie - why do you think inconsistency in element semantics is a good thing? |
| 08:02 | <Hixie> | MikeSmith: i don't really buy that. i don't think authors have problems with that. what makes you think they do? |
| 08:02 | <Hixie> | hsivonen: oh you mean in text/html? |
| 08:03 | <hsivonen> | Hixie: right |
| 08:03 | <othermaciej> | whether it's due to SVG or HTML, someone should define it |
| 08:03 | <othermaciej> | so it doesn't become one of those gap-between-the-spec things |
| 08:03 | <Hixie> | hsivonen: the text/html parsing just generates a DOM, the conformance criteria apply after that, just as if you'd created an equivalent DOM using the DOM API. |
| 08:03 | <Hixie> | tantek: i don't think it's inconsistent. |
| 08:04 | <othermaciej> | right now I think conformance of SVG in text/html is not clearly defined |
| 08:04 | <hsivonen> | Hixie: right, so there's demand for a definition of "bogus but conforming" that defines no-namespace attributes with a colon in their local name bogus but conforming on http://www.w3.org/2000/svg elements |
| 08:04 | <Hixie> | on a completely different topic, how does the UA know which private key is associated with a certificate it gets back after the server has taken the public key created by <keygen> and turned it into a client cert? |
| 08:04 | <MikeSmith> | othermaciej: I don't think the case of <li> is comparable. it's still an item in a list, it just happens to be two different types of lists. whereas in the case of <dialog>, <dt> and <dd> become something else completely |
| 08:04 | <hsivonen> | Hixie: and http://www.w3.org/2000/svg elements with a colon in their local name as bogus but conforming |
| 08:04 | <Hixie> | hsivonen: i have no intention of making any bogus things conforming. |
| 08:04 | <tantek> | MikeSmith - agreed |
| 08:05 | <othermaciej> | MikeSmith: I'm wondering whether there are other examples |
| 08:05 | <Hixie> | hsivonen: (unless there are compelling use cases that need that, like with the <br/> nonsense or the xmlns="" nonsense) |
| 08:05 | <othermaciej> | MikeSmith: besides, arguably, <legend>, but that's also new in HTML5 |
| 08:05 | <hsivonen> | Hixie: do you find the SVG WG's use cases compelling? |
| 08:06 | <Hixie> | hsivonen: i have no idea what their use cases are. I'm assuming from the way you're talking that there's some thread i haven't read yet that is all about this. |
| 08:06 | <othermaciej> | Hixie: the compelling use case here is pasting output from Inkscape into an HTML document without having to do a great deal of postprocessing first |
| 08:06 | <othermaciej> | (well, arguably compelling) |
| 08:06 | <MikeSmith> | othermaciej: I can't think of any offhand. Not only can't I think of comparable examples in HTML, I can't think offhand of any in other markup vocabularies either |
| 08:06 | <hsivonen> | Hixie: what othermaciej said. IIRC, copying and pasting from Inkscape is part of the SVG WG's use cases |
| 08:07 | <Hixie> | hsivonen: inkscape litters its documents with bogus content? |
| 08:07 | <hsivonen> | Hixie: it sprays junk all over |
| 08:07 | <othermaciej> | MikeSmith: well in this case, HTML4 already gave <dt> and <dd> both sets of semantics |
| 08:07 | <hsivonen> | Hixie: really tedious to remove in a text editor |
| 08:07 | <Hixie> | hsivonen: well that sucks |
| 08:08 | <Hixie> | hsivonen: i'd recommend asking the inkscape guys to have an html-mode output that doesn't do taht. |
| 08:08 | <hsivonen> | Hixie: IIRC, Inkscape has a clean output mode already |
| 08:08 | <Hixie> | we don't need _more_ tag soup |
| 08:08 | <MikeSmith> | othermaciej: how so? |
| 08:08 | <Hixie> | hsivonen: oh |
| 08:08 | <Hixie> | hsivonen: well then |
| 08:09 | <Hixie> | hsivonen: problem solved |
| 08:09 | <hsivonen> | Hixie: the use case in taking stuff someone else saved in Inkscape and copying that |
| 08:09 | <hsivonen> | Hixie: from a clip art library |
| 08:09 | <hsivonen> | Hixie: or a Free content repository |
| 08:10 | <othermaciej> | MikeSmith: http://www.w3.org/TR/html401/struct/lists.html#h-10.3 |
| 08:10 | <othermaciej> | "Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words." |
| 08:10 | <Hixie> | hsivonen: so basically the proposal is to make certain cases of xml output from certain tools conforming but not support other cases of xml output from other tools? |
| 08:10 | <othermaciej> | MikeSmith: HTML5 just removes that application of DL and assigns it to DIALOG |
| 08:11 | <tantek> | othermaciej - that's false. HTML4 only gave dt and dd one set of *normative* semantics - definition terms and definitions. |
| 08:12 | <othermaciej> | tantek: is the sentence I quoted a false statement of fact in the HTML4 spec, then? |
| 08:12 | <hsivonen> | Hixie: the idea is to bless the cruft that's already in SVG/XML in Wikimedia Commons, etc. as stuff you can copy and paste without a flurry of errors |
| 08:12 | <othermaciej> | (assuming it's not a conformance criterion) |
| 08:12 | <Philip`> | Inkscape has two different modes for saving SVG, one with loads of extra editor-specific data and one without - is the idea that both formats should be copy-and-pastable? |
| 08:12 | <tantek> | the conversation nonsense came from an *informative* example that was nothing more than a mistake - someone misusing semantic elements for their presentational effect |
| 08:12 | <Hixie> | tantek and I are like two priests both with our own interpretation of a really vague holy text |
| 08:13 | <othermaciej> | tantek: the sentence I quoted is not backed by an example |
| 08:13 | <hsivonen> | Philip`: yes, because stuff exported in the wrong mode is already out there as potential source to copy |
| 08:13 | <Hixie> | hsivonen: i'd recommend just coallescing the errors into one, but from what you've said it doesn't sound like something we'd want to make conforming. |
| 08:13 | <othermaciej> | tantek: I'd believe it was a mistake, but it does not seem any more or less normative than the rest of the DL/DT/DD definition |
| 08:13 | <hsivonen> | Hixie: I can try that |
| 08:14 | <hsivonen> | Hixie: but it won't make users happy |
| 08:14 | <hsivonen> | Hixie: so what's the point? |
| 08:14 | <tantek> | othermaciej the key phrase there is ", for example," == informative |
| 08:14 | <othermaciej> | hsivonen, Hixie: another claimed use case is foreign namespace content that bears the copyright notice and license for the content, and cannot legally be removed |
| 08:14 | <Hixie> | tantek: if you read html4 literally, 99% of the spec is non-normative and you're left with very little worth talking about. |
| 08:15 | <hsivonen> | othermaciej: I think that use case is based on a faulty interpretation of the CC licenses |
| 08:15 | <tantek> | Hixie - also not true - and I submitted a test suite with methodology to prove it. |
| 08:15 | <Hixie> | othermaciej: parsing an xml file as text/html removes the copyright notice. |
| 08:15 | <hsivonen> | othermaciej: the syntax no longer expresses a license anyway if you paste it to text/html |
| 08:16 | <Hixie> | tantek: your methodology was "let's make up some rules about how to get normative statements from this spec, then pretend the spec had said those were the rules" |
| 08:16 | <hsivonen> | othermaciej: thus, syntax looking like RDF/XML isn't appropriate for the text/html medium |
| 08:16 | <Hixie> | hsivonen: the point is making sure that authors say what they think they are saying |
| 08:16 | <othermaciej> | hsivonen: what would be the legal way to paste an SVG containing a license or copyright notice in foreign namespace content into a text/html document? |
| 08:17 | <tantek> | Hixie - the rules were not "made up", they were constructed based on asking the Editor what was intended by the language used. |
| 08:17 | <Hixie> | tantek: the editor is not a normative source. |
| 08:17 | <tantek> | othermaciej - if you believe it is a mistake, then you should oppose <dialog> in HTML5 |
| 08:17 | <othermaciej> | hsivonen: replace with a faithful plain text representation? |
| 08:17 | <hsivonen> | othermaciej: IANAL, but writing the copyright notice and license legend in plain text next to the SVG island |
| 08:17 | <hsivonen> | othermaciej: possibly embellished with microdata |
| 08:18 | <tantek> | and that portion of the DL/DT/DD description is ", for example, " which makes it less normative |
| 08:18 | <Hixie> | tantek: and whether you made them up or the editor made them up doesn't change that they were made up, from the perspective of them not being in the spec. |
| 08:18 | <othermaciej> | tantek: I don't have the information at hand to determine with any certainty whether it was a mistake |
| 08:18 | <tantek> | Hixie - the editor is the source of the language of the spec, including "MUST", "SHOULD" etc., and "this section is normative" etc. thus, the editor *is* a normative source. |
| 08:18 | <othermaciej> | tantek: but whether it was a mistake or not doesn't seem to impact the usefulness of <dialog> (I am pretty agnostic about it) |
| 08:18 | <Hixie> | tantek: no, sorry. that's not how it works. |
| 08:18 | <othermaciej> | hsivonen: presumably you could also put it in plain text in a comment or inside <metadata> |
| 08:19 | <tantek> | Hixie, simple contradiction ("that's not how it works") is not an argument. |
| 08:19 | <Hixie> | tantek: nor is stating that it is how it works, as you are doing :-) |
| 08:19 | <hsivonen> | othermaciej: does SVG allow text children there? |
| 08:19 | <othermaciej> | hsivonen: but that's a tricky manual step, and it becomes a matter of legality, not just authoring tool leftovers |
| 08:19 | <hsivonen> | othermaciej: one might argue that comments are devoid of semantics |
| 08:20 | <tantek> | Hixie - I did not state "how it works", I explained with reasoning why the editor's use of language is normative or informative - that's part of the editor's job in writing up a spec. |
| 08:20 | <hsivonen> | othermaciej: well, we aren't going to make the entirety of RDF/XML work just because so people thought it was a great idea to use RDF/XML for licensing data |
| 08:20 | <othermaciej> | hsivonen: comments are indeed devoid of semantics, but I don't think that makes them an invalid copyright notice |
| 08:20 | <hsivonen> | s/so/some/ |
| 08:21 | <Hixie> | tantek: the intent of the person writing teh spec is irrelevant to what the spec means. Only the spec, and what the spec references normatively, are relevant. Unless the spec says that a human can override it, no human can override it. |
| 08:21 | <othermaciej> | hsivonen: I agree that it would probably be unwise to make it "work", at least in the sense of parsing it in the intended namespaceful way, along with other foreign namespaces |
| 08:21 | <Hixie> | tantek: some specs do say that, e.g. the rules for Munchkin explicitly defer to the owner of the game to resolve rules disputes. |
| 08:21 | <Hixie> | tantek: HTML4 does not. It claims various things about itself, like use of RFC2119, and doesn't mention any editor as being some final arbiter of meaning. |
| 08:22 | hsivonen | wonders if RSS is like Munchkin |
| 08:22 | <Hixie> | tantek: therefore the only correct way to interpret HTML4's normative meaning is to read it and its references and not to make up (or have the editor make up) post-hoc rationalisations about the text of the spec. |
| 08:23 | <Hixie> | tantek: now as it happens, html4 is so poorly written than a literal reading is a futile exercise, as i mentioned |
| 08:23 | <Hixie> | tantek: and it's quite possible that a pragmatic reading with the editor's advice is a more _useful_ undertaking |
| 08:23 | <tantek> | Hixie - indeed, I think that is a good summary of the differences of our readings of HTML4 |
| 08:23 | <Hixie> | tantek: but that is quite irrelevant when it comes to the point of establishing the pedantically precise normative Truth that can be determined from HTML4. |
| 08:25 | <Hixie> | hopefully html5 doesn't have this issue and nobody will later come and say "hey ian, what's normative?" and require that i answer in a way that isn't just pointing to the answer. |
| 08:25 | <tantek> | but is pedantically precise normative truth more important, or what browsers actually implement, or what authors actually publish, or ... ? |
| 08:25 | <tantek> | Hixie - HTML5 will have errors, it is inevitable. |
| 08:25 | <Hixie> | sure, but nothing as eggregious as html4, i hupe |
| 08:25 | <Hixie> | hope |
| 08:25 | <tantek> | In fact, given how big HTML5 is, there is a much higher chance it will have errors than HTML4 did/does. |
| 08:25 | <tantek> | have (more) errors |
| 08:25 | <Hixie> | i'm sure it'll have more errors too |
| 08:25 | <Hixie> | but a thousand typos is nothing compared to not having a normative statement about pretty much anything :-) |
| 08:26 | <Hixie> | anyway, what matters is what legacy content intended, and to that end I've ignored HTML4 completely in writing HTML5 |
| 08:26 | <Hixie> | (much to Julian's dismay) |
| 08:26 | <othermaciej> | does the definition of <dl> in HTML4 include any of the Tantek-extended normativity keywords? |
| 08:26 | <othermaciej> | (I can't remember what they were) |
| 08:27 | <othermaciej> | also, does anyone actually use <dl> for marking up conversations (thereby indicating a need for some more suitable way to do so)? |
| 08:28 | <tantek> | othermaciej - http://www.w3.org/MarkUp/Test/HTML401/current/assertions/prologue.html |
| 08:29 | <tantek> | which is part of http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html |
| 08:29 | <tantek> | referenced by http://www.w3.org/MarkUp/Test/HTML401/current/htmltestdocumentation.html |
| 08:30 | <othermaciej> | tantek: does "is" count as a case of "are"? |
| 08:30 | <tantek> | which is the documentation for http://www.w3.org/MarkUp/Test/HTML401/current/ |
| 08:34 | <tantek> | othermaciej - I believe that's what the documentation was saying, but perhaps could have been more explicit and included all forms of a verb rather than just an illustrative form. |
| 08:34 | <tantek> | othermaciej - also note that the "Another application of DL, for example..." sentence is in the context of a sequence of *informative* examples |
| 08:34 | <tantek> | "Here is an example:" ... |
| 08:34 | <tantek> | "Here is an example with ..." |
| 08:34 | <tantek> | "Another application of DL, for example..." |
| 08:35 | <tantek> | hence the reasonable informative treatment of that text |
| 08:35 | <tantek> | as all examples are informative |
| 08:35 | <tantek> | whether described as "here is an example" or "for example" |
| 08:37 | <othermaciej> | tantek: it seems there isn't any normative definition of DL at all using your extended keywords |
| 08:38 | <othermaciej> | the only verbs applied to it are "vary" and "consist" |
| 08:39 | <tantek> | othermaciej - not true, there are several testable assertions derived from normative text regarding DL, see Assertions 10.3-1 through 10.3.1-3 here: http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_section10.html |
| 08:40 | <tantek> | sorry - make that *two* testable assertions |
| 08:40 | <tantek> | Assertion 10.3-1 and 10.3-2 |
| 08:40 | <tantek> | (regarding DL) |
| 08:40 | <othermaciej> | tantek: the one you expressed as an "author must" doesn't actually use any of the key verbs |
| 08:40 | <tantek> | "must" is already a key RFC2119 word |
| 08:40 | <tantek> | "are required" |
| 08:41 | <tantek> | = "must" |
| 08:41 | <othermaciej> | the only verbs in it are "vary", "consist", "give" (in passive voice), "restrict" (in passive voice) and "contain" |
| 08:41 | <othermaciej> | I mean Assertion 10.3-2 |
| 08:42 | <othermaciej> | I think you'd have to be psychic to know that sentence is normative, but the one about marking up dialogues is not |
| 08:42 | <tantek> | yes - I think that's evidence that we used "is" as normatively as "are" |
| 08:42 | <tantek> | othermaciej - not at all, "for example" = informative |
| 08:43 | <Hixie> | othermaciej: psychic, or willing to apply out-of-band information obtained from the person who wrote the spec |
| 08:43 | <othermaciej> | so you're saying "is" used as an auxiliary verb for a passive voice verb indicates normativity, but not if the sentence includes the words "for example"? |
| 08:43 | <tantek> | othermaciej - right - anything of an "example" nature is informative. |
| 08:43 | <othermaciej> | but all passive voice verbs are normative |
| 08:44 | <othermaciej> | while active voice ones are not, unless they are on the special list |
| 08:44 | <othermaciej> | but you also includes this sentence in the assertion, which doesn't have any of the magic words, even as auxiliary verbs: "Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description." |
| 08:45 | <tantek> | othermaciej - that sentence was included for context so the following normative sentences would make sense. |
| 08:45 | <tantek> | it's not its own assertion |
| 08:46 | <tantek> | (judging *what* to quote from the spec for each assertion was certainly a challenge) |
| 08:47 | <othermaciej> | so if that second sentence said "the DT element gives the term" instead of "the term is given by the DT element" it would not be normative? |
| 08:47 | <hsivonen> | tantek: the first assertion (at http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_section05.html) shouldn't be marked (author) if one assumed the spec writer used the SGML concept of "document character set" correctly |
| 08:47 | <hsivonen> | tantek: since the SGML concept is always Unicode for HTML |
| 08:48 | <tantek> | othermaciej - we would have had to have made the term "gives" explicitly normative as well, though in hindsight, should have anyway given it's use with "is". |
| 08:49 | <hsivonen> | It's also interesting that "User agents must also know the specific character encoding that was used to transform the document character stream into a byte stream" is annotated as (author) when the sentence says what UAs must do |
| 08:49 | <tantek> | hsivonen - I think you're right. you may have found the first bug in the testable assertions. well done. |
| 08:49 | <othermaciej> | here is a sentence using "may" that contains "for example": "For example, using CSS, one may specify that the style of numbers for list elements in a numbered list should be lowercase roman numerals." |
| 08:49 | <othermaciej> | is that non-normative? |
| 08:50 | Hixie | wonders how "user agents must know [...]" is supposed to be implemented |
| 08:50 | <tantek> | othermaciej - yes that's non-normative, and should be in the HTML spec, as the HTML spec doesn't normatively define what CSS does or does not do. |
| 08:50 | <tantek> | that's common for cross-spec/functionality references |
| 08:51 | <tantek> | (using informative language so as to not potentially invalidate the normative language in another spec) |
| 08:51 | <tantek> | (key for good spec modularity) |
| 08:51 | <othermaciej> | it seems like most uses of "for example" are true statements of fact |
| 08:52 | <othermaciej> | but I guess that one for dl has to be either normative or false |
| 08:52 | <tantek> | othermaciej - most "informative" statements are true statements of fact. that doesn't make them normative. |
| 08:52 | othermaciej | likes the RFC keyword system a lot better |
| 08:52 | <tantek> | othermaciej - indeed. |
| 08:53 | <Philip`> | If you made the term "gives" explicitly normative, presumably you'd still have to apply some other non-normative interpretation to cases like "Using external (linked) style sheets gives you the flexibility to change the presentation without revising the source HTML document" |
| 08:53 | <othermaciej> | although there still doesn't appear to be a normative definition of DL itself, even if DT and DL are not |
| 08:54 | <othermaciej> | it seems like the following sentence with "for example" introduces a genuine SHOULD/RECOMMEND-level requirement: "In the absence of more sophisticated behavior, for example tailored to the needs of a particular script or language, we recommend the following behavior for user agents" |
| 08:54 | <tantek> | othermaciej - unfortunately the only normative definition of DL is that it must have a start and end tag per Assertion 10.3-1 :/ |
| 08:54 | <tantek> | othermaciej "we recommend" is actually non-normative |
| 08:55 | <tantek> | per http://www.w3.org/TR/html401/conform.html |
| 08:55 | <othermaciej> | as distinct from "recommended"? |
| 08:55 | <tantek> | "At times, the authors of this specification recommend good practice for authors and user agents. These recommendations are **not normative** |
| 08:55 | <boblet> | re: now-completed discussion of <dialog> and <dl>, would <dialog> be used for marking up a theatrical play or IRC log? if so what about non-actor dialog, such as stage directions and joined/left etc announcements? |
| 08:55 | <tantek> | **emphasis adde** |
| 08:55 | Hixie | updates his registration for TPAC to point out he now has clashes with not three, but four working groups on the first two days |
| 08:55 | <tantek> | "These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording. |
| 08:55 | <tantek> | " |
| 08:56 | <Lachy> | hsivonen, the solution to the RDF/XML looking stuff (and other useless metadata) within <metadata> in SVG is to simply comment it out if the author thinks it can't physically be removed from the image |
| 08:56 | <tantek> | and "we recommend ... (the following)" is exactly what quoted text says |
| 08:56 | <Philip`> | "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]." sounds like it conflicts with that |
| 08:57 | <tantek> | Philip`: "RECOMMENDED" is not the same as "we recommend" |
| 08:57 | <othermaciej> | boblet: <dialog> could be used for such purposes in theory, but in practice its content model is not suitable for expressing anything but the conversation itself, so stage directions, join/leave messages, IRC /me actions, etc could not be properly marked up in <dialog> |
| 08:57 | <Philip`> | Oh, I missed the "ED" |
| 08:57 | <tantek> | more good reasons to dump <dialog> |
| 08:58 | Hixie | thinks if <dialog> is popular, we should just add <ds> or whatever to cover that case |
| 08:58 | <hsivonen> | Lachy: that's not a solution to the inkscape cruft |
| 08:58 | <tantek> | Philip` - yes, the distinction ("ED") is too subtle and prone to error in reading. |
| 08:58 | <Hixie> | but that's a problem for a future spec |
| 08:58 | <Lachy> | hsivonen, I know |
| 08:58 | <Lachy> | the solution to that is to have them stripped out by a simple post processor |
| 08:58 | <othermaciej> | does anyone actually currently mark up conversations with <dl>? or in any other distinct and idiomatic way? |
| 08:59 | <othermaciej> | that's the relevant question to me, not what HTML4 may or may not have meant |
| 08:59 | <hsivonen> | Lachy: having anything but textual copy and paste defeats the SVG WG's use cases |
| 08:59 | <tantek> | othermaciej - ordered list, with cite for the speaker and q for the utterance, e.g.: http://rbach.priv.at/Microformats/IRC/2009-08-28 |
| 09:00 | <Hixie> | (<cite> for speaker contradics html5's statements about <cite> btw) |
| 09:00 | <boblet> | othermaciej: that’s what I thought. I think authors would potentially find it confusing to decide whether to use method A or B if there are two approved ways for marking up a conversation (depending on whether it contains non-actor content) |
| 09:00 | <tantek> | Hixie - your HTML5 defintion of <cite> contradicts existing usage. Ergo the HTML5 definition of <cite> should change to conform to existing usage. |
| 09:00 | <Lachy> | hsivonen, that's not a problem unless you think their use case deserves addressing, which I don't. The more we can encourage authors to strip useless cruft from markup, the better |
| 09:00 | <tantek> | especially since that usage is permitted in HTML4 |
| 09:01 | <Hixie> | tantek: actually, research indicates that <cite> for people is used far less than for other things, and is in fact used less than, say, <cite> for italics, or <cite> for the sake of it with no good semantic use. |
| 09:01 | <hsivonen> | Lachy: I think telling authors not to type cruft is a worthwhile thing to do. Telling them to remove cruft, no so much. |
| 09:02 | <Lachy> | what's the difference? |
| 09:02 | Philip` | likes how HTML5 lets him extract stuff like http://philip.html5.org/tests/canvas/suite/spec.yaml where there's an explicit "must" statement for most test cases |
| 09:02 | <Hixie> | tantek: i actually disagree that html4 allows <cite> for people, but my reading of html4 is at odds with other people's, so i'm not going to argue that point |
| 09:02 | <Hixie> | tantek: except to point out yet again that html4 is ungodly vague. |
| 09:02 | <MikeSmith> | othermaciej: I think Jonas's message on <dialog> from a while back was meant to make the case that there's little evidence of anybody actually using <dl> for dialogs |
| 09:03 | MikeSmith | looks in the list archive |
| 09:03 | <hsivonen> | Lachy: the difference is that the first case saves time and the latter wastes it |
| 09:03 | <heycam> | i haven't been paying attention to the conversation just now, but for the point about conformance of SVG DOM subtrees created from parsing text/html documents, i'm sure we could add some wording in svg's conformance appendix about that |
| 09:03 | <tantek> | Hixie, research indicates that <cite> is used for people far more than <dt> is |
| 09:03 | <tantek> | therefore you should drop <dialog> |
| 09:03 | <tantek> | and fix <cite> accordingly |
| 09:03 | <Hixie> | othermaciej: (per tantek's rules, is "Contains a citation or a reference to other sources" normative?) |
| 09:03 | <heycam> | currently conformance is markup focussed rather than dom focussed |
| 09:04 | <othermaciej> | heycam: I think that would be a reasonable approach |
| 09:04 | <Hixie> | tantek: <dialog> wasn't added because of high usage |
| 09:04 | <tantek> | Hixie - doesn't matter |
| 09:04 | <heycam> | but we could add something about say converting the dom to markup and then determining the conformance based on that |
| 09:04 | <Hixie> | tantek: it kinda does |
| 09:04 | <tantek> | if you want to be consistent in your methodology |
| 09:04 | <othermaciej> | heycam: it does seem that conformance of SVG (at least for 1.1) is ultimately defined in terms of the source text, if you chase all the normative references |
| 09:04 | <heycam> | othermaciej, right |
| 09:04 | <hsivonen> | heycam: in this case, the DOM is not serializable as XML |
| 09:04 | <heycam> | hsivonen, you're talking about the metadata rdf stuff? |
| 09:05 | <heycam> | i guess i'm just worrying about the general issue |
| 09:05 | <Hixie> | tantek: my methodology is not blind adherence to a single principle, it's a very broad set of principles that encompass far more than just usage. |
| 09:05 | <hsivonen> | heycam: that and the inkscape cruft |
| 09:05 | <heycam> | of defining document conformance |
| 09:05 | <tantek> | you should prefer <cite> for people rather than <dt> for people (in conversations) |
| 09:05 | <othermaciej> | hsivonen: you could apply the infoset coercion rules first, but that would certainly result in documents that are not conforming SVG |
| 09:05 | <Hixie> | tantek: why? |
| 09:05 | <tantek> | btw reference to broader request for cite: http://www.zeldman.com/superfriends/guide/#cite |
| 09:05 | <boblet> | Actually it’d be great if there was a quasi-official coding patterns reference (how to mark up a play script etc). Perhaps a section in the Wiki at some stage? |
| 09:05 | <heycam> | well, to be honest, text/html doesn't support xml namespaces -- so if you've got some elements in there with colons in them, you're going to produce invalid text/html imo |
| 09:05 | <Hixie> | tantek: actually, for <cite>, if you want that changed, please respond to the relevant thread in whatwg recently |
| 09:05 | <hsivonen> | othermaciej: true, but it would be the resulting spec text incomprehensible to authors |
| 09:05 | <Hixie> | tantek: since it was discussed to death there already |
| 09:06 | <Lachy> | hsivonen, it's not a waste of time to produce cleaner markup |
| 09:06 | <Lachy> | it makes working with the markup easier |
| 09:06 | <Hixie> | tantek: is zeldman done collecting the feedback from his blog commenters yet btw? |
| 09:06 | <tantek> | and requesting of dropping of dialog: http://www.zeldman.com/superfriends/guide/#dialog |
| 09:06 | <heycam> | but i guess it could be in line with allowing xmlns="" talismans to allow rdf stuff to not be unconforming |
| 09:06 | <othermaciej> | heycam: that was hsivonen's interpretation of the de facto reality, but apparently that would make a great deal of existing SVG produce errors when pasted into text/html |
| 09:06 | <Hixie> | tantek: send that feedback to the list if you want it to get a reply |
| 09:06 | <heycam> | othermaciej, yeah, given a lot is produced by inkscape and inkscape outputs the extra stuff |
| 09:06 | <tantek> | Hixie - will do, was merely citing it here for the benefit of connecting the discussions for the logs. |
| 09:07 | <Lachy> | and makes subsequent copy/pasting by other authors easies by not having to ignore so much useless cruft |
| 09:07 | <Lachy> | *easier |
| 09:07 | heycam | has to leave, but i'll raise an issue with the svg wg about the "conformance of a dom" thing |
| 09:07 | <Hixie> | i found http://www.zeldman.com/2009/09/04/html5-redefines-footer/ somewhat ridiculous, btw. claiming credit for something that had nothing to do with him. |
| 09:07 | <Hixie> | and not even apologising when called on it |
| 09:07 | <heycam> | s/i'll/he'll/ if i want to get my pronouns right :) |
| 09:09 | <hsivonen> | so, it looks like I can express all tree operations as an opcode and three pointers |
| 09:09 | <hsivonen> | if I bake the element namespace into the opcode |
| 09:09 | <hsivonen> | yay for namespaces complicating my work again |
| 09:10 | <Lachy> | Hixie, it's understandable why he thought he played a part in it. The timing of when they first published their feedback, and when you dealt with older feedback on the same issue, was very coincidental |
| 09:11 | <Hixie> | Lachy: sure, but he didn't correct it or anything when it was pointed out that it was in fact a coincidence |
| 09:11 | <othermaciej> | Hixie: since you did what he wanted, it doesn't seem very important whether you did it because you listened to him (as he thought) or due to similar feedback from others (as was actually the case) |
| 09:11 | <takkaria> | hsivonen: hm, why are you expressing tree operations as opcodes? |
| 09:11 | <othermaciej> | he didn't actually directly claim that it was *because* of his request, though the justaposition implies that |
| 09:12 | <hsivonen> | takkaria: to put their identity on a heap-allocate queue as opposed to having direct on-stack method calls |
| 09:12 | <Hixie> | othermaciej: it grates on me that someone would claim to be contributing and claiming credit for it (whether implicitly or not) when they have in fact not done so, because it takes away from the credit that the real contributors should be getting |
| 09:12 | <hsivonen> | *allocated |
| 09:12 | <Hixie> | othermaciej: we have literally hundreds of people who have actually contributed, and they deserve the credit that he's taking |
| 09:13 | <hsivonen> | takkaria: the tree building algorithm runs independently of the tree operations actually happening |
| 09:13 | <boblet> | Hixie: I actually think that the coincidental timing is a good thing, as it’s going to both encourage more people to get involved (increased perception they can contribute), and hopefully to do so in a constructive way (some of the feedback has been backed up by more than personal opinion) |
| 09:13 | <takkaria> | hsivonen: ah, interesting |
| 09:13 | <takkaria> | hsivonen: I'm guessing this is for off-main-thread parsing? |
| 09:13 | <hsivonen> | takkaria: yes |
| 09:13 | <Hixie> | hsivonen: how many opcodes? If your pointers are aligned, and if you don't have many opcodes, you might be able to encode the opcodes in the LSBs of the pointers, for extra obfuscation. :-) |
| 09:14 | <othermaciej> | Hixie: well, the spec has acknowledgements, I guess if you wanted to give more credit you could cite people who gave relevant feedback in commit messages |
| 09:14 | <hsivonen> | takkaria: although I already had a setup like this in order to batch notifications so that the CSS frame constructor didn't run after every tree operation |
| 09:14 | <Hixie> | othermaciej: i do, sometimes. but the commit messages aren't going to get the exposure his claims are. |
| 09:14 | <othermaciej> | but I suppose I should stay away from getting in the middle of the Leibniz-Newton priority dispute here |
| 09:15 | <Hixie> | yeah |
| 09:15 | <Hixie> | me too |
| 09:15 | <Hixie> | i'm not going to make a fuss over it or anything |
| 09:15 | <Hixie> | it just grates me |
| 09:15 | Hixie | might be overly protective of the spec's contributors :-) |
| 09:15 | <Philip`> | othermaciej: "cite people"? I thought that wasn't allowed :-p |
| 09:16 | <hsivonen> | Hixie: 19 opcodes so far |
| 09:16 | <othermaciej> | I think I am one of the few people that is not offended by Zeldman's high level of self-esteem |
| 09:16 | <hsivonen> | Hixie: will have a few more |
| 09:17 | <Hixie> | hsivonen: if your pointers are aligned to 4-byte boundaries, you get 2 bits per pointer, right? with 6 bits you can have 64 opcodes. |
| 09:17 | <Hixie> | hsivonen: (btw this is the worst idea ever unless you expect to have bazillions of these flying about) |
| 09:18 | <hsivonen> | Hixie: seems like a premature optimization, but I'll keep it in mind |
| 09:18 | <Hixie> | (your pointers might well be aligned, though, especially if they're coming out of an arena as i expect they are) |
| 09:18 | <Hixie> | yeah like i said, it's a horrible idea :-) |
| 09:18 | <hsivonen> | Hixie: they come out of jemalloc |
| 09:18 | <tantek> | Hixie - your comment on Zeldman's post seems to explain the situation clearly enough. I'm not sure what you're objecting to. Anyone who reads the post and comments will see the details you note and given that no-one is arguing with you, accept them. |
| 09:19 | <Hixie> | hsivonen: no idea what that is |
| 09:19 | <othermaciej> | it's a custom malloc implementation borrowed from FreeBSD |
| 09:20 | <othermaciej> | on modern systems you can always expect any pointer that comes from an allocator to be at least 4-byte aligned, and likely 8-byte aligned if the allocation is at least 8 bytes in size |
| 09:21 | <Hixie> | yeah, i was just looking at the jemalloc source |
| 09:21 | <othermaciej> | however, stuffing flags in the low bits of pointers should probably not be the first tool you reach for |
| 09:21 | <Hixie> | indeed |
| 09:21 | <Hixie> | more like the last tool |
| 09:22 | <hsivonen> | now I have an opcode, three pointers and one integer |
| 09:22 | <othermaciej> | (we do it sometimes in WebKit but only if we can prove the space saved is a singificant memory improvement) |
| 09:22 | <hsivonen> | getting rid of the integer might actually be a small win |
| 09:25 | Philip` | thought malloc had to return at least 8-byte aligned, because you might potentially use it for storing doubles and (in practice) they ought to be 8-byte aligned, or something like that |
| 09:27 | <othermaciej> | Philip`: yeah, but not for a 4-byte allocation, if malloc supports true 4-byte allocations |
| 09:29 | <Philip`> | Hmm, C99 seems to just say it is "suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object ..." |
| 09:30 | <Philip`> | but since *(double*)malloc(4) is always going to be undefined behaviour, I suppose that means it doesn't have to be double-aligned |
| 09:31 | <Philip`> | (even though it is any type of object) |
| 09:31 | <Philip`> | s/it/double/ |
| 09:45 | <Hixie> | five points to the first person who can find me a page with a smallish table that one could imagine markup up using microdata where the items correspond to columns rather than rows |
| 09:46 | <Hixie> | and one point for each error that anyone can find in any of the files in http://damowmow.com/playground/microdata/ |
| 09:47 | <Lachy> | Hixie, what's the value of these points you're offering? |
| 09:47 | <Hixie> | they're each worth one point |
| 09:47 | <Lachy> | hah |
| 09:48 | <Lachy> | can we exchange them for prizes if we get enough? |
| 09:50 | <Hixie> | with each other? sure |
| 09:51 | <Lachy> | <p>Taken on <time itemprop="http://flickr.com/ns/pubdate"; datetime="2009-07-21T00:00-00:00">July 21, 2009</time>.</p> |
| 09:51 | <Lachy> | the datetime attribute doesn't need to have the time specified |
| 09:51 | <Lachy> | just use datetime="2009-07-21" |
| 09:52 | <Lachy> | from http://damowmow.com/playground/microdata/001/flickr-annotated.html |
| 09:54 | <Lachy> | also, <img itemprop="about" src="/photos/05108321.jpeg"> -- the image is missing |
| 09:54 | <tantek> | indeed - and artificial precision is an anti-pattern (it implies data where there is none) |
| 09:54 | <tantek> | (regarding not needing to specify the time) |
| 09:54 | <othermaciej> | Hixie: http://www.sosmath.com/tables/trigtable/trigtable.html |
| 09:55 | <othermaciej> | if you think of sin(x), cos(x) and tan(x) as the items |
| 09:55 | <ttepasse> | Shouldn't be the rating in http://damowmow.com/playground/microdata/003/yelp-annotated.html a <meter>? |
| 09:55 | <Hixie> | Lachy: for the purposes of this study, i'm defining the datetime pattern as being the full datetime |
| 09:55 | <Hixie> | Lachy: just so there's less to explain |
| 09:55 | <tantek> | Hixie, why? |
| 09:55 | <Hixie> | othermaciej: thanks |
| 09:56 | <Hixie> | tantek: based on advice from our usability expert that each additional aspect of complexity makes the data harder to analyse |
| 09:57 | <Lachy> | Hixie, but requiring authors to add a meaningless and incorrect time to a time stamp, or some random date when they only want a time, makes things more complex |
| 09:57 | <Hixie> | ttepasse: yeah i'm trying to keep it to html4 as much as possible |
| 09:57 | <Hixie> | Lachy: good point. i'll make it be a specific time. |
| 09:57 | <Lachy> | unless you make sure that there are no dates without times or times without dates in any of the examples used |
| 09:58 | <Lachy> | how many points is that worth? :-) |
| 09:58 | <tantek> | Lachy's experience is with authors agrees with mine. |
| 09:58 | <tantek> | s/is with/with |
| 09:58 | <Hixie> | i agree that in the actual html5 spec we should make it possible for an itemprop="" to have as values either a date, time, or datetime |
| 09:59 | <Hixie> | (though god knows what that does to the rdf conversion) |
| 10:00 | <Hixie> | Lachy: that was 12 points, i think, based on the edits i had to do. :-) |
| 10:01 | <Lachy> | woo hoo! |
| 10:01 | <Hixie> | RE: the missing images, they're all missing |
| 10:01 | <Hixie> | not sure if we'll provide images or not on the day |
| 10:01 | <othermaciej> | if I am due 5 points then I think I must decline to avoid the appearance of bribery |
| 10:01 | <Lachy> | Hixie, also, requiring authors to specify a day when they only have a year and month, is equally wrong, and is why the spec should be more flexible with allowing less specific dates |
| 10:02 | <ttepasse> | Making meter/@value a possible microdata-value as in time/@datetime would be also too complex, wouldn't it? |
| 10:02 | <Hixie> | ttepasse: for the study? yeah, i don't want to go there for the study. |
| 10:03 | <ttepasse> | In general. |
| 10:03 | <Hixie> | ttepasse: might make sense to add to the language, though |
| 10:06 | <hsivonen> | http://stackoverflow.com/questions/1350741/html5-0-canvas-textfield |
| 10:09 | <othermaciej> | ick |
| 10:09 | <Hixie> | how horrifying |
| 10:10 | <tantek> | Lachy agreed: http://www.zeldman.com/superfriends/guide/#time |
| 10:12 | <Hixie> | Lachy: i don't understand the use cases for exposiing only a year and a month. Do calendars even support that? I didn't see anything like that in the iCal format. |
| 10:13 | <hsivonen> | tantek: what's your use case for exposing imprecise dates in a machine-readable format? |
| 10:14 | <hsivonen> | tantek: that is, I see why you might want to write only year and month on a Web site but why do those need to be machine-readable? |
| 10:15 | <hsivonen> | tantek: what apps actually support month-precision events in calendaring? |
| 10:15 | <hsivonen> | tantek: oops. sorry. I misread the superfrieds doc. nothing to see here. |
| 10:16 | hsivonen | confused Lachy's case and Super Friends' case |
| 10:17 | <tantek> | hsivonen - I've seen far fewer examples in the wild of month-precision "dates". Until I find sufficiently representative real world examples to justify a request, I'm withholding that specific request. |
| 10:18 | <tantek> | I would not be opposed to such an enhancement, but I don't think I can justify one myself. |
| 10:18 | <hsivonen> | tantek: the Super Friends date use cases do look a bit Semantic Webby, though |
| 10:18 | <tantek> | hsivonen - no triples here, move along. ;) |
| 10:19 | <othermaciej> | extracting birthdays without a year sounds plausible |
| 10:19 | <othermaciej> | and years without a day are indeed common on historical timelines |
| 10:20 | <Hixie> | google has shown that to do a timeline you don't need explicit markup |
| 10:20 | <annevk3> | not really |
| 10:20 | <hsivonen> | othermaciej: in the latter case, it seems Semantic Webby that timeline data and timeline creators would arise on that level of coupling |
| 10:20 | <hsivonen> | othermaciej: as opposed to Wikipedia-specific tools |
| 10:20 | <annevk3> | Google places my about page in 1986 |
| 10:21 | <annevk3> | as news article, last I checked |
| 10:21 | <Hixie> | annevk3: you think relying on authors to get markup right is going to be any better overall? :-) |
| 10:22 | <othermaciej> | hsivonen: I have a hard time gauging what is realistic in terms of extracting data from web pages |
| 10:22 | <annevk3> | mpilgrim, you should do the s/HTML 5/HTML5/ thingie as well |
| 10:23 | Hixie | doesn't understand why people care about that space |
| 10:23 | <ttepasse> | http://en.wikipedia.org/wiki/July_Crisis would be an example for yyyy-mm. |
| 10:23 | <Lachy> | Hixie, so you're saying that sites that want to do timelines incorporating vague moments in time, like YYYY-MM without a day, can do so, but are excluded from taking advantage of the <time> element? |
| 10:24 | <Hixie> | not just vague moments in time |
| 10:24 | <Hixie> | any timelines |
| 10:24 | <hsivonen> | Lachy: the time element is not for intra-site timelines |
| 10:24 | <hsivonen> | Lachy: <time> implies that you crawl someone else's content and build a timeline out ofthat |
| 10:25 | <Philip`> | Google News Timeline associates http://www.developerfusion.com/event/8137/the-last-mile-html-5-websockets-comet-free-event-with-jonas-jacobi/ with 01 January 1999 even though there's actually a correct machine-readable hCard date on the page |
| 10:25 | <Hixie> | lachy: i'm saying <time> is intended to allow calendar events to be marked up, to allow Atom feeds to be generated from HTML pages, and nothing else |
| 10:25 | <hsivonen> | Bugzilla uses MySQL data for bug trend graphs. It doesn't scrape its own HTML output. |
| 10:25 | <Hixie> | Lachy: (because nothing else has had a compelling argument made for it) |
| 10:26 | <tantek> | Hixie, Google has shown you can create a *lossy* timeline without explicit markup - just like nearly all "entity recognition" |
| 10:26 | <hsivonen> | people love to think up semantics and then invent use cases for the semantics. After all, we've been taught that Semantics are Good. |
| 10:27 | <tantek> | hsivonen people love to think up APIs and then invent applications for the APIs. |
| 10:27 | <tantek> | no difference |
| 10:28 | <tantek> | semantics are just really simple APIs |
| 10:28 | <tantek> | and they enable applications |
| 10:28 | <tantek> | shared semantics enable portable applications |
| 10:28 | <Hixie> | tantek: you can't create anything better than a lossy timeline even with markup, because of the error rate in authoring |
| 10:28 | <hsivonen> | I could buy the argument that including all Porter–Duff operations is a matter of completeness instead of solid use cases for each one |
| 10:28 | <tantek> | Hixie - nope. there are tons of problems with entity recognition. false positives etc. |
| 10:29 | <Hixie> | tantek: you can only get higher fidelity if you have a controlled environment, at which point you can just use microdata/microformats/rdfa/whatever and don't need explicit support from html itself. |
| 10:29 | <Lachy> | Hixie, what about, for example, the list that Opera maintains internally of upcoming web related conferences? That often lists events which are known to be held in a certain month, but the exact date has yet to be decided. |
| 10:29 | <tantek> | Hixie - artificial dichotomy |
| 10:29 | <Hixie> | tantek: your argument assumes that authors can write markup correctly, which is false |
| 10:29 | <Hixie> | Lachy: what about it? |
| 10:29 | <hsivonen> | Lachy: does iCal support that kind of data? where do you intent to import the data? |
| 10:30 | <tantek> | Hixie - tons of microformats on the web show plenty of data that authors can write markup correctly enough. |
| 10:30 | <ttepasse> | Hixie, not all applications deals with Googles scales and Googles possibilities. More often than not it's just a script, scraping data of a small part of the interweb. |
| 10:30 | <Lachy> | it just seems like you're imposing unnecessary restrictions |
| 10:30 | <hsivonen> | Lachy: do you want to be the one who implements per-month events in iCal and Outlook for HTML compat? |
| 10:31 | <Hixie> | tantek: well then authors can write microformats better than they can write html, in which case, again, use microformats, not html, to solve this problem. |
| 10:31 | <tantek> | Lachy - worse than just "unnecessary", but in contradiction of existing publishing patterns. |
| 10:31 | <tantek> | Hixie, <time> is *supposed* to be an improvement upon the way we markup dates and times in microformats. |
| 10:31 | <Hixie> | tantek: no, it's not |
| 10:31 | <tantek> | at least, last time I read HTML5 it said that. |
| 10:31 | <Hixie> | tantek: <time> is supposed to be a way to give a date to iCal and Atom convertors. that's all. |
| 10:32 | <tantek> | and those use cases came from hCalendar and hAtom |
| 10:32 | <othermaciej> | that seems like a pretty narrow set of use cases |
| 10:32 | <Lachy> | Hixie, time was inspired by the abuse of <abbr> in microformats |
| 10:32 | <Hixie> | othermaciej: those are the ones that have been put forward that can't be solved in other better ways so far. |
| 10:32 | <othermaciej> | no other format or application is interested in a time, besides those two? |
| 10:32 | <tantek> | Lachy, and even now with the improvements in the value-class-pattern, there are some cases where <time> is still better, from a markup simplicity perspective |
| 10:33 | <othermaciej> | very suspicious from a Zero, One, Infinity Rule perspective |
| 10:33 | <tantek> | othermaciej - e.g. the "bday" property in hCard |
| 10:34 | <Lachy> | Hixie, apps like iCal may not be suitable for representing such vague moments in time, but ruling out the possibility of other applications that might from the beginning seems short sighted |
| 10:35 | <tantek> | Lachy, agreed |
| 10:35 | <Hixie> | Lachy: we rule out an infinite number of applications from the beginning. |
| 10:36 | <Hixie> | Lachy: if there are specific applications that need to be handled, then they should be brought up as use cases for us to handle |
| 10:36 | <othermaciej> | FWIW iCal (the app) does let you make week-long or month-long events |
| 10:36 | <zcorpan__> | mpilgrim: "The <video> element is designed to be usable without any detection script at all." - this is true for canvas as well (it supports fallback) |
| 10:36 | <Hixie> | othermaciej: and you can mark those up with <time> and the vevent microdata format, using dtstart and dtend |
| 10:37 | <hsivonen> | othermaciej: yet, you posted a WebKit position casting doubt over the use cases for the large set of date-related widgets :-) |
| 10:37 | <Hixie> | othermaciej: providing a <time> format for just a year-month combination wouldn't actually work with the vevent format, we'd have to hard-code a mapping from that to a separate dtstart/dtend pair |
| 10:37 | <othermaciej> | hsivonen: I've never personally seen a Web app ask me for a month or a week, it is true |
| 10:38 | <hsivonen> | Lachy: "possibility of other apps" would be more convincing if you were clearly on the hook for writing a <time> to iCalendar converter |
| 10:38 | <Hixie> | othermaciej: every time you spend money online you're asked for a month (credit card expiry date) |
| 10:38 | <zcorpan__> | mpilgrim: s/HTML 5/HTML5/ ? |
| 10:38 | <Hixie> | othermaciej: (weeks though is mostly for europe) |
| 10:38 | <othermaciej> | Hixie: fair enough |
| 10:39 | <tantek> | Hixie, I'm not opposed to your suggestion to "use microformats, not html, to solve this problem." |
| 10:39 | <tantek> | I'm merely suggesting improvements to HTML that *help* authors use microformats to solve such problems. |
| 10:39 | <othermaciej> | Hixie: true, though it would be kind of awful to actually use a date picker widget for those... |
| 10:40 | <tantek> | Hixie is there an <input type=month> for the credit card expiry date case? |
| 10:40 | <Lachy> | tantek, yes |
| 10:40 | zcorpan__ | is used to just type the year/month of the credit card and would be annoyed to have to use a date picker |
| 10:40 | <othermaciej> | Hixie: because even though it's a month in theory, it's an arbitrary 4-digit number in the way it's used |
| 10:41 | <Hixie> | othermaciej: i'd expect type=month to be implemented in the way that works for credit card expiry dates |
| 10:41 | <Philip`> | For expiry dates you'd want it to show the month as a number rather than a name; are there are other cases where a name would be better? |
| 10:41 | <Lachy> | zcorpan__, it would help if the type=month control was implemented in a way that provided usability enhancements over having two text boxes |
| 10:42 | <othermaciej> | Hixie: if it's expected to be used for credit card dates, then indeed, it would need something significantly different from what other date/time widgets would use, to be usable |
| 10:42 | <zcorpan__> | Lachy: file a bug? :) |
| 10:42 | <Lachy> | zcorpan__, yeah. I might |
| 10:43 | <Lachy> | I recall seeing a nice javascript based implementation of a date picker that was optimised incredibly well for date selection |
| 10:43 | <Philip`> | "two text boxes" - I always see two <select> boxes |
| 10:43 | <Lachy> | Philip`, I've seen both |
| 10:43 | <Philip`> | and I can't think of any usability enhancements you could make to it |
| 10:44 | <Lachy> | Philip`, the one I've seen implemented in javascript before worked like this: When clicked, it brought up a row of years. When you hover over a year, a bar showed below that with all the months. Then, hovering over the month let you move down and select the date |
| 10:45 | <othermaciej> | the usability enhancement would be to associate it with a credit card number field and be able to enter both at once from a list of your credit cards |
| 10:45 | <Lachy> | so it made picking any date a 2 click operation, with just a little bit of hovering over the right bits |
| 11:02 | annevk3 | sighs |
| 11:02 | <Hixie> | sup? |
| 11:02 | <annevk3> | trying to figure out how MIME types are to be parsed |
| 11:02 | <zcorpan__> | mpilgrim: no need for !! in supports_local_storage() |
| 11:03 | <annevk3> | apparently not executing <script type="text/javascript " src="..."> is causing issues |
| 11:04 | <zcorpan__> | mpilgrim: window.name is an alternative to sessionStorage that works in legacy browsers |
| 11:06 | <annevk3> | Hixie, for "MIME type" HTML5 references RFC2046 and not RFC2045... |
| 11:07 | <annevk3> | Hixie, but RFC2045 defines the actual syntax afaict |
| 11:07 | <zcorpan__> | hmm, how would you know which videos to store for offline use if you're providing both ogg and mp4? |
| 11:08 | <eighty4> | is there number on how many people that need stuff like <label> and such? |
| 11:08 | <annevk3> | MIME specs make it clear why BNF is a bad idea |
| 11:08 | <annevk3> | christ |
| 11:09 | <eighty4> | oh, and this is probably the wrong channel to ask that, sorry... |
| 11:09 | <Hixie> | annevk3: yeah, that's intentional iirc |
| 11:09 | <annevk3> | Hixie, do you know if parsing a media type makes the whitespace go away? |
| 11:10 | <Hixie> | annevk3: i doubt that's defined anywhere |
| 11:10 | <annevk3> | Hixie, I'd assume you can write stuff like text/html ;charset=utf-8 but I don't know |
| 11:10 | <annevk3> | :/ |
| 11:10 | <Hixie> | annevk3: yeah, the 2046 is intentional; i reference http for the actual syntax (next paragraph) |
| 11:11 | <annevk3> | cheers |
| 11:11 | <Hixie> | hm, i really don't define how you parse mime types anywhere? |
| 11:11 | <Hixie> | that seems like a big ommission |
| 11:11 | <annevk3> | i guess whitespace is allowed then given that HTTP allows whitespace everywhere |
| 11:12 | <annevk3> | Hixie, I'm willing to file a bug :) |
| 11:13 | <annevk3> | Hixie, it could make the various things that accept mime types as arguments slightly less ambigious |
| 11:13 | <Hixie> | yeah |
| 11:13 | <annevk3> | if there's a proper dfn of how to get the mime type and parameters |
| 11:13 | <Hixie> | we have some algorithms for parsing the charset="" parameter |
| 11:14 | <Hixie> | (which has little to do with the right way to do things) |
| 11:14 | <Hixie> | (now in mimesniff, as the "algorithm for extracting an encoding from a Content-Type") |
| 11:15 | <Hixie> | http://tools.ietf.org/html/draft-abarth-mime-sniff-01 says to use the HTTP spec to parse the mime type itself |
| 11:15 | <annevk3> | done |
| 11:16 | <zcorpan__> | i thought philipj had complained about parsing mime types not being defined (for canPlayType and <source type>) |
| 11:16 | <annevk3> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7549 |
| 11:16 | <Hixie> | zcorpan__: any idea if i replied already? |
| 11:16 | <zcorpan__> | Hixie: don't remember |
| 11:16 | <annevk3> | if it's invalid that's ok too, if someone can explain how the HTTP BNF works and that it allows the trailing space |
| 11:17 | <zcorpan__> | annevk3: i thought there was a clause somewhere saying that whitespace is allowed between any and all tokens in the BNF, but i might be mistaken |
| 11:18 | <annevk3> | zcorpan__, yeah, something like that |
| 11:18 | <zcorpan__> | not that it matches what is implemented |
| 11:18 | <zcorpan__> | text / html |
| 11:18 | <annevk3> | zcorpan__, they plan on fixing the not being explicit part in HTTPbis |
| 11:18 | <annevk3> | zcorpan__, I doubt they'd fix that though |
| 11:19 | <annevk3> | zcorpan__, because of the gazillion non-browser implementations that can read gibberish |
| 11:19 | <zcorpan__> | interop++ |
| 11:19 | <Hixie> | i don't think the httpbis work is going to really fix much of what we think needs fixing |
| 11:20 | <Hixie> | throw it onto the pile of things for us to fix later |
| 11:20 | <annevk3> | i think we did before it started :p |
| 11:20 | <Hixie> | true |
| 11:31 | <Lachy> | I found this slightly improved date picker UI example. It's not the one I was looking for, though. http://onemarco.com/2008/12/13/improving-the-date-picker-user-interface-ui/ |
| 11:51 | <hsivonen> | tantek: does it need any changes except zapping axis? |
| 11:51 | <hsivonen> | (and border and summary) |
| 11:52 | <hsivonen> | or moving part of summary to <caption> |
| 11:52 | <hsivonen> | are there Super Friend-authored sites with real-world multidimensional tables? |
| 11:53 | jgraham | wonders what "it" is |
| 11:53 | <hsivonen> | jgraham: the sample table at http://www.w3.org/TR/html401/struct/tables.html#h-11.4.2 |
| 11:56 | jgraham | suddenly realises that must be the table that was supposed to correspond to the summary attribute example that bounced around public-html for a while |
| 12:01 | <hsivonen> | mercurial pulls in a ridiculous dependency tree |
| 12:01 | <hsivonen> | xorg-libXScrnSaver |
| 12:01 | <hsivonen> | is one of the deps... |
| 12:05 | <Hixie> | othermaciej: do you know if there is any way to turn off paging on mac os X? (i have a machine with plenty of ram and i'd rather fail hard when something leaks memory than fail to disk with the resulting massive slowdown) |
| 12:06 | <othermaciej> | Hixie: I think there is some way to configure the kernel not to swap, but I don't know offhand what it is |
| 12:06 | <Hixie> | k |
| 12:06 | <othermaciej> | my guess is that it would be a sysctl parameter |
| 12:07 | <zcorpan__> | hmm, there's a new "Profile" option in validator.nu, though it doesn't seem to do anything yet |
| 12:08 | <othermaciej> | I guess I'd add that even if you can turn off the use of swap space, it might not be possible to prevent discarding buffer cache pages that aren't dirty, so unused parts of your executable or shared libs could get tossed and reloaded later |
| 12:08 | <annevk3> | zcorpan__, see rubys' blog |
| 12:08 | <Hixie> | vm.swapusage maybe |
| 12:11 | <Hixie> | apparently i need to disable dynamic_pager |
| 12:11 | <Hixie> | i guess launchd will let me do that |
| 12:11 | <Hixie> | though god knows what the result will be! |
| 12:14 | <othermaciej> | OS X does run without paging on iPhone |
| 12:15 | <othermaciej> | but I don't know if Mac OS X is prepared for the consequences |
| 12:19 | <Hixie> | i have this other box - my partner's 2007 macbook - which has been paging like crazy ever since we installed snow leopard |
| 12:19 | <Hixie> | i think it's some issue with flash |
| 12:19 | <Hixie> | it happens a lot when my partner uses this game on facebook |
| 12:20 | <Hixie> | which of course is always left in the background in one of safari's tabs... along with gmail and calendar... |
| 12:22 | zcorpan__ | notes that <object type> doesn't interact so well with other form controls' .type when iterating .elements |
| 12:22 | <Hixie> | yeah, not much we can do about that |
| 12:26 | <annevk3> | what is the use case for iterating and calling the validation stuff anyway? |
| 12:28 | <Hixie> | checking each control is valid, finding all the controls that are required and not set, etc |
| 12:28 | <othermaciej> | Flash running in a separate process has mostly stopped it from taking down Safari, but it seems (anecdotally) like it might have increased the CPU hogging and such |
| 12:29 | <annevk3> | Hixie, but the UA already does that, no? |
| 12:29 | <Hixie> | annevk3: not if you, e.g., want to make a list of all the missing fields in your UI |
| 12:47 | <hsivonen> | awesome. my Typinator macro for the xlink namespace has a type |
| 12:47 | <hsivonen> | typo |
| 13:25 | <annevk3> | http://www.sitepen.com/blog/2009/09/02/json-namespacing/ -- "XML’s namespacing colon cancer" |
| 13:39 | <zcorpan__> | Hixie: the same <section> confusion: http://www.sitepoint.com/forums/showthread.php?t=636355 |
| 13:56 | <Lachy> | one thing that might help a little bit is if there was actually an example illustrating how to use <article> without <section>, in the #the-article-element section |
| 13:57 | <Lachy> | something like this: |
| 13:57 | <Lachy> | <article> |
| 13:57 | <Lachy> | <header><h1>Some Heading</h1></header> |
| 13:57 | <Lachy> | <p>A few paragraphs, maybe a list or something to illustrate the article content. |
| 13:57 | <Lachy> | </article> |
| 13:58 | <Lachy> | although, the <header> should probably be excluded from the example, or filled in with additional stuff too |
| 13:59 | <Lachy> | maybe <header><h1>...</h1><p>Published <time ...>...</time></header> |
| 14:08 | <zcorpan__> | Lachy: yes, that might help |
| 14:08 | <zcorpan__> | the definition of <section> probably also needs to be clearer |
| 14:09 | <Lachy> | bug filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=7552 |
| 14:21 | <boblet> | myakura: Vant? |
| 14:22 | <boblet> | myakura: hey :) |
| 14:23 | <Lachy> | #the-section-element already has an example illustrating what I just filed the bug about. |
| 14:23 | <Lachy> | And it's the example that I had written too :-) |
| 14:24 | <Lachy> | it wouldn't hurt to have additional example in the <article> element section too, I suppose |
| 14:40 | <myakura> | boblet: heya |
| 14:40 | <mpilgrim> | boblet: s/HTML 5/HTML5/g deployed |
| 14:41 | <mpilgrim> | hsivonen: i am aware of the patent issues, i even mention them in the video detection section |
| 14:41 | <mpilgrim> | and i'll mention them again in the video chapter |
| 14:42 | <boblet> | myakura: dude, how am I even gonna get into your HTML5 speech in Ginza? can I carry your bag or something? |
| 14:42 | <boblet> | mpilgrim: that was basically your only feedback from like 4 ppl huh :D |
| 14:43 | <myakura> | boblet: heh. |
| 14:43 | <mpilgrim> | i will have explicit instructions on encoding H.264Baseline+AAC/LC+MP4 that match the codec parameters given |
| 14:43 | <mpilgrim> | and copies notes on H.264 profiles and stuff |
| 14:44 | <boblet> | myakura: good to be popular! |
| 14:44 | <myakura> | boblet: well it seems that I have another one on the 10th of November in Digital Hollywood Tokyo. This one would be better for you, cuz it's the day before WDE. |
| 14:45 | <mpilgrim> | zcorpan__: it's true that <canvas> allows fallback content (and i should mention that), but i think it's a different situation than <video> |
| 14:46 | <mpilgrim> | 99% of the time, people put <video> on a page because they want to show a video and nothing more |
| 14:46 | <mpilgrim> | whereas 99% of the time, people put <canvas> on a page because they want to draw on it, and the fallback content is just going to be empty or next-to-useless |
| 14:46 | <boblet> | myakura: if this year is like last year I’ll have zero time then ;( that was a 18 hour day of cat herding |
| 14:46 | <boblet> | still good to know |
| 14:47 | <mpilgrim> | i should mention the capability anyway because of accessibility, and for the 1% case where you could actually provide a useful fallback |
| 14:47 | <mpilgrim> | but i suspect that the use cases will end up at opposite ends of the spectrum |
| 14:47 | <Rik|work> | mpilgrim: maybe a flash equivalent ? |
| 14:50 | <mpilgrim> | maybe |
| 14:50 | <mpilgrim> | but i think people who care enough to program a flash version will just use the flash version to the exclusion of anything else |
| 14:50 | <mpilgrim> | zcorpan__: extraneous !! will be removed in next checkin |
| 14:51 | <mpilgrim> | whew, i think that takes care of all the feedback from irc, twitter, and email |
| 14:51 | <zcorpan__> | mpilgrim: (i saw more unnecessary !! than the one i mentioned) |
| 14:52 | <mpilgrim> | yeah, they're fixed but not deployed |
| 14:52 | <mpilgrim> | they're all fixed and consistent now |
| 14:52 | <mpilgrim> | oh, the table-of-contents.html is still a 404 |
| 14:53 | <mpilgrim> | bah |
| 14:53 | <mpilgrim> | screw it, i'm writing a script to autogenerate it |
| 14:53 | <mpilgrim> | updating the TOC manually was the biggest PITA in "Dive Into Python 3" |
| 14:54 | <annevk2> | maybe you should use the document outline tool? |
| 14:54 | <mpilgrim> | second only to manually updating the next/previous links between chapters that i kept rearranging |
| 14:54 | <annevk2> | html5 ftw |
| 14:54 | <mpilgrim> | what a concept |
| 14:54 | <mpilgrim> | is there a standalone version? |
| 14:55 | <annevk2> | http://gsnedders.html5.org/outliner/ |
| 14:55 | <jgraham> | mpilgrim: Not afaik, but I could probably make you one this evening if you like |
| 14:55 | <annevk2> | oh, source code |
| 14:55 | <annevk2> | hmm |
| 14:55 | <jgraham> | s/this evening/maybe this evening maybe over the next couple of evenings/ |
| 14:56 | <mpilgrim> | html5lib doesn't do this yet? |
| 14:56 | <jgraham> | html5lib is just a parser. Well and a bunch of other things I wish I didn';t have to maintain |
| 14:57 | <jgraham> | But the anolis outline tool would be pretty easy to extract into a standalone product |
| 14:58 | <jgraham> | (I also wrote an outline tool but I don't suggest using it for anything) |
| 14:59 | <jgraham> | http://hg.hoppipolla.co.uk/hgwebdir.cgi/anolis/file/16550726fd0d/anolislib/processes/outliner.py is the code if you want to do it yourself |
| 15:03 | <zcorpan__> | hmm, maybe video and audio should support the url decomposition attributes so it's easy to set a fragment identifier for start and end position |
| 15:07 | <annevk2> | wouldn't a dedicated API be better? |
| 15:07 | <annevk2> | in fact, i'm not even sure how decomposition would work given that alternate resources could be selected |
| 15:07 | <TabAtkins> | jgraham: holy crap, you're right about that table being the one that the super-confusing @summary was designed for. |
| 15:08 | annevk2 | wonders if there's an assumption that all <source> resources are of equal length |
| 15:08 | <jgraham> | TabAtkins: Yeah. I would _never_ have got from that summary to that table layout |
| 15:09 | <TabAtkins> | Or vice-versa, to be honest. |
| 15:09 | <beowulf> | url? |
| 15:09 | <beowulf> | i mean, web address? |
| 15:09 | <jgraham> | heh |
| 15:10 | <jgraham> | http://www.w3.org/TR/html401/struct/tables.html#h-11.4.2 |
| 15:10 | <jgraham> | is the table |
| 15:10 | <beowulf> | haha |
| 15:10 | <beowulf> | i was so wrong, i suck |
| 15:11 | <TabAtkins> | Yeah, sorry beowulf. You lose. |
| 15:11 | <TabAtkins> | But so does everyone else IN THE ENTIRE WORLD. |
| 15:12 | <jgraham> | (the summary is in http://lists.w3.org/Archives/Public/public-html/2009Jun/0684.html for those following along at home) |
| 15:12 | <TabAtkins> | So that qualifies as an argument against @summary, right? ^_^ |
| 15:12 | <jgraham> | Can we please not use the words "argument" and "summary" in the same sentence? |
| 15:13 | <jgraham> | They make my email client tremble |
| 15:13 | <beowulf> | haha |
| 15:13 | <TabAtkins> | Hahaha |
| 15:16 | <TabAtkins> | I think part of the problem is that the table in question is organized somewhat confusingly. It has two levels of row headers - I'd probably move the city names to a column preceding the others, and @colspan them to cover the dates. |
| 15:17 | <TabAtkins> | By putting both levels of headers in the same table they make it hard to describe easily. |
| 15:21 | <TabAtkins> | Hrm. I'll also note that the first column does *not* contain merged table cells, unless they're referring to the issue I just brought up. |
| 15:32 | <beowulf> | Warnock's Dilemma should have another interpretation: Mail clients are scared of the responses |
| 15:35 | <jcranmer> | there's an easy solution to the issue... just use the relational database model which has been around for the past 20-30 years... |
| 15:44 | <TabAtkins> | jcranmer: Yeah, 'easy'. |
| 15:45 | <TabAtkins> | Relational databases *are* easy. Doesn't mean it's an easy solution for the average author. ^_^ |
| 15:46 | <jcranmer> | in a few years, I expect relational database to be standard course material at the collegiate if not the high school-level |
| 15:46 | <TabAtkins> | They're definitely standard at college level. I doubt they're standard at highschool. |
| 15:46 | <jcranmer> | well, my school system now requires people to learn GIS |
| 15:50 | <mpilgrim> | http://www.reddit.com/r/programming/comments/9ipvm/detecting_html_5_features_dive_into_html_5/ |
| 15:50 | <mpilgrim> | #3 in /r/programming and just 8 comments |
| 15:51 | <mpilgrim> | half of which are stupid |
| 15:51 | <mpilgrim> | i've seen better-quality discussions on scammy affiliate marketing articles |
| 15:52 | <mpilgrim> | maybe i'm in the wrong business |
| 15:53 | <annevk2> | maybe reddit is becoming digg |
| 15:53 | <mpilgrim> | apparently news.ycombinator.com is like the reddit of old |
| 15:53 | <mpilgrim> | and stackoverflow.com is like the new.ycombinator of old |
| 15:54 | <mpilgrim> | so hard to keep up |
| 15:56 | <TabAtkins> | I do loves me some stackoverflow, though. |
| 16:03 | <miketaylr> | mpilgrim: fwiw, i was excited to see your book linked on reddit today. |
| 16:03 | <mpilgrim> | me too! |
| 16:03 | <mpilgrim> | i was just disappointed to see the level of discussion |
| 16:03 | <miketaylr> | :) |
| 16:03 | <miketaylr> | yeah. |
| 16:03 | <mpilgrim> | i got much better discussions on "Dive Into Python 3" (in /r/python) |
| 16:03 | <miketaylr> | especially the modernizr salespitch part |
| 16:04 | <mpilgrim> | was tempted to respond to that. decided to bitch about it in irc instead. |
| 16:04 | <miketaylr> | funny how nobody complains that half of what's in /r/programming is a salespitch for jquery |
| 16:04 | <miketaylr> | :P |
| 16:04 | <mpilgrim> | reddit does pump a hella buncha traffic, though |
| 16:05 | <mpilgrim> | it swamps all other referrers |
| 16:05 | <jcranmer> | /.? |
| 16:06 | <mpilgrim> | i haven't been on slashdot in a long time, so i wouldn't know |
| 16:06 | <mpilgrim> | i should say, reddit is currently swamping all the other referrers to http://diveintohtml5.org/detect.html |
| 16:06 | <mpilgrim> | including the irc logs for this channel :) |
| 16:07 | <hendry> | mpilgrim: do you think you could please modify the geo link to s/OMTP/OMTP BONDI/ ? |
| 16:07 | <mpilgrim> | sure |
| 16:07 | <mpilgrim> | to what? |
| 16:07 | <mpilgrim> | oh |
| 16:07 | <mpilgrim> | i see |
| 16:07 | <mpilgrim> | i actually had that to begin with, then second-guessed myself |
| 16:07 | <mpilgrim> | fixing... |
| 16:08 | <hendry> | mpilgrim: 1.0 is also out-of-date, though there is no /stable redirect yet. :/ Their Web server isn't maintained v. well |
| 16:08 | <mpilgrim> | done |
| 16:09 | <mpilgrim> | i just searched for "bondi location" and used the first reasonable-looking url |
| 16:09 | <hendry> | mpilgrim: i'm surprised you don't capitalise Web ;) |
| 16:09 | <mpilgrim> | i'd be happy to change it |
| 16:09 | <mpilgrim> | "Web"? |
| 16:09 | <mpilgrim> | where? |
| 16:09 | <hendry> | mpilgrim: i did this geo detection example a while back called http://geo.webvm.net I should probably update it. |
| 16:11 | <hendry> | mpilgrim: there is lowercase web in your doc. I like to see capitalised Web. |
| 16:11 | <mpilgrim> | WONTFIX ;) |
| 16:11 | <annevk2> | you should lowercase the single uppercase Web then ;) |
| 16:12 | <annevk2> | (and I don't mean the one in the <h2>) |
| 16:13 | <mpilgrim> | that's a quote |
| 16:13 | hendry | notices http://code.google.com/p/geo-location-javascript |
| 16:13 | <mpilgrim> | from a spec that capitalized it |
| 16:13 | <mpilgrim> | so again, WONTFIX ;) |
| 16:13 | <annevk2> | aah, you win |
| 16:14 | <mpilgrim> | bbiab |
| 16:15 | <annevk2> | http://www.theinquirer.net/inquirer/news/1532879/microsoft-previews-silverlight-amsterdam -- "Silverlight works on PCs and the expensive PC clone, the Apple Mac." |
| 16:27 | <Lachy> | I found the control I was looking for earlier related to datetime control discussion http://haineault.com/media/jquery/ui-timepickr/page/ |
| 16:28 | <Lachy> | I reckon applying the same concept to date picking, as that one does for time picking, would be a major usability enhancement |
| 16:36 | <annevk2> | hmm, mpilgrim just regressed the removal of the space... |
| 16:36 | <annevk2> | maybe just in a few places |
| 17:16 | <rubys> | looks like html5lib's sanitizer exposes rather than omits unknown markup... any reason why I can't make that an option? |
| 17:17 | <annevk2> | if there's someone to maintain it |
| 17:17 | <annevk2> | iirc that's a problem with the current sanitizer already |
| 17:17 | <zcorpan__> | hsivonen: i get an internal error when i try to validate with the xml parser and xhtml 1.0 schemas |
| 17:23 | <rubys> | http://code.google.com/p/html5lib/issues/detail?id=62 |
| 17:30 | <jgraham> | rubys: I think you coded the original so you are certianly welcome to change it :) |
| 17:31 | <rubys> | jgraham: I get failures running python/tests/runtests ... is that expected? |
| 17:31 | <jgraham> | rubys: Some failures are pretty much expected because the spec changed under us and we have not kept pace with hsivonen in fixing issues |
| 17:31 | <rubys> | File "/var/lib/python-support/python2.6/simplejson/decoder.py", line 158, in JSONString |
| 17:31 | <rubys> | return scanstring(match.string, match.end(), encoding, strict) |
| 17:31 | <rubys> | ValueError: Invalid \uXXXX escape: line 121 column 48 (char 3997) |
| 17:32 | <jgraham> | Oh, and new versions of simplejson enforce valid UTF-8 and we have tests for invalid UTF8 in JSON format |
| 17:33 | <jgraham> | That badly needs fixing |
| 17:33 | jgraham | obviously has not been spending enough time on htis |
| 17:33 | <jgraham> | *this |
| 17:34 | <jgraham> | (there should be, iirc, something like 5 unique treebuilder tests that fail * the number of tree implementations that you have) |
| 17:34 | <jgraham> | (so typically 25 fails) |
| 17:44 | <rubys> | jgraham: I only get one failure... a hard one that stops testing. |
| 17:53 | <rubys> | Running on a machine with 2.5.2, I get FAILED (failures=173, errors=1) |
| 17:56 | <rubys> | just testing the sanitizer, I get 5 failures (on either 2.5.2 or 2.6.2) |
| 18:07 | <jgraham> | rubys: Oh. That seems much worse than I thought |
| 18:08 | jgraham | will investigate |
| 18:36 | <zcorpan__> | why is http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#offsets-into-the-media-resource marked as being considered for removal? |
| 18:36 | <zcorpan__> | is it an old annotation intended for the looping/start/end etc stuff that were removed before? |
| 18:37 | <annevk2> | prolly |
| 18:37 | <annevk2> | you edited it last |
| 18:38 | <zcorpan__> | yeah |
| 18:38 | <zcorpan__> | now i just need to figure out where to find the password for the annotation system |
| 18:39 | zcorpan__ | requests a new account |
| 18:42 | <zcorpan__> | fixed |
| 19:46 | <zcorpan__> | what is controversial about "HTML vs XHTML"? |
| 19:46 | <annevk2> | ? |
| 19:46 | <zcorpan__> | in the spec |
| 19:46 | <zcorpan__> | it's annotated as controversial |
| 19:47 | <tantek> | hsivonen, the example at http://www.w3.org/TR/html401/struct/tables.html#h-11.4.2 sans axis and border attributes, and with a suitable replacement for summary (whatever HTML5 suggests) would indeed be a good start for a multidimensional table example. |
| 19:47 | <annevk2> | zcorpan__, if your name is Dean Edridge I suppose it is |
| 19:49 | <zcorpan__> | changed it to LC |
| 19:50 | <gsnedders> | XHTML2 WG disagreed with it |
| 19:50 | <annevk2> | the annotation system is not section aware it seems |
| 19:51 | <annevk2> | e.g. annotations for 1.9 apply to 1.10 as well... |
| 19:55 | <zcorpan__> | annevk2: right. i think Hixie expects all sections to have annotations in the end |
| 19:55 | <Lachy> | zcorpan__, I think I just overwrote your change to the annotation. Although it was still marked controversial when I loaded the spec to see it |
| 19:55 | <zcorpan__> | gsnedders: i thought they disagreed with the relationship section |
| 19:55 | <Lachy> | didn't see your comment about marking it LC before I changed it |
| 19:56 | <gsnedders> | zcorpan__: both, IIRC |
| 19:56 | <zcorpan__> | oh well |
| 19:56 | <Lachy> | changed it back to CL |
| 19:56 | <Lachy> | LC |
| 19:56 | <annevk2> | isn't it widely implemented and deployed? |
| 19:57 | <zcorpan__> | annevk2: it just explains the differences. it can't be implemented :) |
| 19:58 | <zcorpan__> | also, xhtml isn't widely deployed ;) |
| 19:59 | <annevk2> | hmm, wide enough not to kill it apparently |
| 19:59 | <tantek> | just different interpretations of "deployed" :) |
| 20:07 | <rubys> | no, just different interpretations of "xhtml" :-) |
| 20:09 | <murr4y> | so, do you guys think it will be properly deployed (served as xml) in the future? |
| 20:09 | <murr4y> | or that the regular html syntax will prevail? |
| 20:10 | <rubys> | only by crazy people. (note: I'm one of them) |
| 20:21 | <annevk3> | rubys, what was the reason you did this again? just to show you can? |
| 20:21 | <tantekc> | annevk3 , what is "this"? |
| 20:21 | <rubys> | "this" being xhtml? |
| 20:23 | <rubys> | annevk3: if by "this" you mean application/xhtml+xml, I blame mpilgrim. |
| 20:35 | <annevk3> | rubys, is this similar to little game you had going on where he did semantic HTML and you did HTML scraping? |
| 20:41 | <rubys> | I assume that you are referring to Million Dollar markup and posts by citation. That's the right era (2002). He convinced me to clean up my markup. He since joined Google. |
| 20:42 | <annevk3> | I'm aware of the irony :) |
| 20:43 | <annevk3> | Anyway, I was just wondering if there's some kind of practical reason that required XHTML, but when asking that I forgot that not all browsers support embedded SVG and MathML just yet |
| 20:45 | <rubys> | and there is alway the "because I can" motivation. I have found that being demonstrably able to do it has provided me considerable street cred when talking to people who think that it is easy. |
| 21:12 | <jamesr> | why doesn't a MessagePort have an onclose or ondisentangle event? |
| 21:14 | <annevk3> | if you have a good use case I'm sure it can be added |
| 21:29 | <Hixie> | jamesr: because it would expose details of the garbage collector |
| 21:29 | <Hixie> | and we don't want to specify how GC works in that much detail |
| 21:30 | <jamesr> | what would it expose other than "the thing has to get collected eventually"? |
| 21:35 | <jamesr> | or is that too much? |
| 21:37 | <Hixie> | jamesr: it would expose when it was GC'ed |
| 21:42 | <jgraham> | (python has __del__ methods on objects and it is something of a disaster because they are not called reliably. As a consequence it's considered bad practice to use them even without the same kind of interoperability problems that you get on the web) |
| 21:42 | <jamesr> | upon reflection it wouldn't be very useful |
| 21:43 | <jamesr> | java finalizers are basically useless as well |
| 21:57 | <jgraham> | rubys: (in case you raed the logs) I just pushed some changes to html5lib that fix the sanitizer testcases |
| 21:58 | <annevk3> | Hixie, closing a bunch of HTML WG bugs btw |
| 21:58 | annevk3 | is a bit bored |
| 21:58 | <and> | annevk3: Did you test whitespace stripping in IE’s encoding matching algorithm on labels from both meta charset and HTTP header? (I am not sure how significant whitespace is supposed to be encoded in a HTTP header, and trailing literal whitespace will presumably be removed by the HTTP layer.) |
| 21:58 | <jgraham> | rubys: Actually no I didn't because it won't accept the push for some reason |
| 21:58 | <annevk3> | and, I got this info from someone on the IE Team |
| 21:59 | <and> | annevk3: OK. |
| 21:59 | <annevk3> | and, he also gave me this: http://lists.w3.org/Archives/Public/public-html-comments/2009Sep/0050.html |
| 21:59 | <annevk3> | and, list with encodings IE should support |
| 21:59 | annevk3 | hasn't looked at that in detail yet |
| 21:59 | <jgraham> | Oh it seems to have worked on the third attempt |
| 22:00 | <jgraham> | silly unreliable google |
| 22:01 | <gsnedders> | and: In HTTP leading and trailing LWS is insignificant |
| 22:06 | <and> | gsnedders: Thanks. What about, e.g., after the colon in "Content-Type: text/html; charset=ISO-8859-1"? |
| 22:06 | <gsnedders> | and: Insignificant |
| 22:07 | <and> | gsnedders: Yes, of course. Sorry, I meant after the equals sign. |
| 22:07 | <gsnedders> | and: Insignificant |
| 22:07 | <annevk3> | what gsnedders is saying here is all "in theory" btw |
| 22:07 | mpilgrim | pines for the good old days when the topic was in english |
| 22:07 | <gsnedders> | Yeah |
| 22:08 | <annevk3> | http://tools.ietf.org/html/draft-abarth-mime-sniff -- search for "extracting an encoding from a Content-Type" |
| 22:08 | <annevk3> | mpilgrim, feel free to change it back |
| 22:08 | <gsnedders> | That's only for meta@charset though |
| 22:08 | <gsnedders> | What's done for the actual HTTP header is difference |
| 22:08 | <annevk3> | gsnedders, I don't think so |
| 22:09 | <gsnedders> | annevk3: They are |
| 22:09 | <annevk3> | gsnedders, that's not the intent of that algorithm, iirc |
| 22:10 | <gsnedders> | IIRC it is |
| 22:11 | <annevk3> | did you read that section? |
| 22:11 | <annevk3> | oh well |
| 22:11 | <gsnedders> | I'm watching TV now :P |
| 22:12 | <mpilgrim> | no, i'd rather sit back and complain that the process is unfair |
| 22:14 | <annevk3> | if there's one thing the world needs, it's more armchair generals! |
| 22:15 | <mpilgrim> | 7,393 pageviews on http://diveintohtml5.org/detect.html since publishing it |
| 22:15 | <mpilgrim> | over 60% of those are from a single link on reddit |
| 22:16 | <mpilgrim> | which still has a very poor signal-to-noise ratio |
| 22:17 | <Philip`> | When I published something a while ago, I got tens of thousands of hits from StumbleUpon, which far exceeded Reddit and Slashdot and everywhere else |
| 22:18 | <mpilgrim> | my "how to install windows xp in 5 hours or less" article was/is on stumbleupon |
| 22:18 | <Philip`> | though it seems relatively few people from StumbleUpon got any further than looking at the front page, and the latter sites provided many more interested visitors |
| 22:18 | <mpilgrim> | i still get 900+ hits a day on that article |
| 22:18 | <Philip`> | Hmm, 5 hour install? |
| 22:19 | Philip` | has spent the past two days installing and setting up Gentoo on a new laptop |
| 22:19 | <jamesr> | i'm back with a use case! |
| 22:19 | <gavin> | 5 hours seems like a lot for a windows xp install |
| 22:19 | <mpilgrim> | i like comparing referrers based on "average time spent on site" |
| 22:19 | Dashiva | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- ???????????' |
| 22:19 | <Dashiva> | There |
| 22:20 | <GPHemsley> | ? |
| 22:20 | <Philip`> | Dashiva: Are those question marks, or have I not installed enough Unicode fonts yet? |
| 22:20 | <GPHemsley> | Does that mean I can bring my logic with me now? |
| 22:20 | <Dashiva> | Now it's equally cryptic to everyone |
| 22:20 | <jamesr> | there's a discussion on WHATWG about adding locks to protect shared resources (document.cookie, window.localStorage). it would be possible to implement that API in pure javascript by using a sharedWorker and postMessage to pass a token around _except_ that it's possible for a context to go away while holding the "lock" token and there's no way to know that it is gone |
| 22:20 | <mpilgrim> | Philip`: lol |
| 22:20 | <Dashiva> | Philip`: They are question marks |
| 22:21 | <and> | annevk3: Nice, looks like a complete list of labels. |
| 22:21 | <jamesr> | so it could be useful to have a port.onclose event that is spec'd such that after the onclose event fires on a Port there it is guaranteed that no more postMessage events will ever be fired on it |
| 22:21 | <mpilgrim> | reminds me of this: http://www.cafepress.com/nucleartacos.26721820 |
| 22:21 | Dashiva | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- 理を外に置いて下さい。' |
| 22:21 | annevk3 | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 22:23 | <Dashiva> | Philip`: The second one should have had symbols |
| 22:24 | <Philip`> | Dashiva: What language? |
| 22:24 | <Dashiva> | Japanese |
| 22:25 | <and> | On a completely different note, I had a quick look at tokeniser--treebuilder interaction, and found that CDATA/RCDATA/PLAINTEXT are dropped only inside <select> (as mentioned yesterday) and <frameset>. (I may have missed something, of course.) |
| 22:26 | <and> | The <select> case is slightly annoying since </select> may be implied inside a table, so tokenisation would then at least depend on table structure and nesting. |
| 22:26 | <Philip`> | Dashiva: Hmm, works in Opera but not in Konsole |
| 22:26 | Philip` | tries installing more fonts |
| 22:26 | <and> | Are unclosed CDATA/RCDATA elements inside <select> really a problem? |
| 22:27 | <annevk3> | and, you can probably get away with tokenizing somewhat correctly |
| 22:27 | <annevk3> | and, it sort of depends on your goals |
| 22:28 | <annevk3> | and, again though, Validator.nu is pretty fast |
| 22:28 | <Philip`> | Dashiva: Hooray, it works now |
| 22:29 | <and> | It would be nice to remove this special case and let an opening CDATA/RCDATA tag always imply CDATA/RCDATA tokenisation. |
| 22:33 | <annevk3> | and, usually just tokenizing is not enough anyway so I doubt it's worth trying to change impl here |
| 22:35 | <cardona507> | Firefox can't find the server at html5.validator.nu - whats up? |
| 22:37 | <and> | annevk3: It is sufficient for correct syntax colouring, conversion to UTF-8 without entities and probably quite a few other tasks, and *unnecessary* dependencies really should be avoided anyway. |
| 22:39 | <annevk3> | if you say so :) |
| 22:39 | <annevk3> | I'm not really interested in fighting that battle, but you could file a bug / write a comment |
| 22:45 | <and> | annevk3: Yes, I am probably going to do that. (I almost expected someone to point out that the current behaviour was essential for some obvious reason, in which case asking for a change would be pointless.) |
| 22:46 | <annevk3> | aah, well there could certainly be compat reasons |
| 22:46 | <annevk3> | e.g. pages having a stray <plaintext> inside <select> or some such |
| 23:59 | <jwalden> | syp__: does IE8 not support textContent? |