| 02:09 | <sebasmagri> | Hi guys, I've been looking for a non-java alternative to w3c css and markup validators which supports css3 and html5... Do someone knows any? |
| 02:11 | <sebasmagri> | I want to have it running in my development machine... I'm looking at the validate.cgi in html5lib sources, could it be what I'm looking for? |
| 02:12 | <sebasmagri> | the cgi's docstring answers part of my question... |
| 09:05 | <hsivonen> | cool. Opera Mobile support @font-face even on S60 |
| 09:08 | <annevk> | was there some blog post last week that should be mentioned on WHATWG Weekly? |
| 09:08 | <annevk> | I have a section "The Wider Web" for that this time around |
| 09:12 | <Hixie> | annevk: added some unfinished stuff to 140, also asked smylers if he could contribute his recent e-mail to 140 |
| 09:13 | <Smylers> | Hixie: Sure. Will do that now. |
| 09:13 | <Hixie> | oh, speak of the devil :-) |
| 09:13 | <Hixie> | didn't realise you were here, or would have asked you here instead :-) |
| 09:13 | <Hixie> | thanks dude |
| 09:14 | <Smylers> | I wasn't — first time I've logged in in months and the first message I saw mentioned me! |
| 09:14 | <Hixie> | hah |
| 09:14 | <annevk> | I can send out rev 1 of the proposals later today |
| 09:14 | <annevk> | unless someone wants to wait a little longer |
| 09:14 | <Hixie> | there's no deadline yet is there? |
| 09:15 | <hsivonen> | annevk: I'm not sure I understood your validation versioning proposal |
| 09:16 | <hsivonen> | annevk: surely it is appropriate to pose the question "is this document valid HTML + SVG + MathML" specifying snapshots for each |
| 09:17 | <annevk> | you mean like asking is this "valid CSS 2.1"? |
| 09:17 | <hsivonen> | whether anyone provides validator software for the exact snapshot dates you want is another question |
| 09:17 | <annevk> | authors have been annoyed with that forever |
| 09:17 | <annevk> | they want to use teh Selectors |
| 09:17 | <Hixie> | what's the use of checking for validity for HTML and NOT SVG and MathML? |
| 09:18 | <hsivonen> | Hixie: maybe you want to make sure your fractions are dumb text fractions that interop with UAs that don't support MathML |
| 09:18 | <hsivonen> | Hixie: i.e. want to make sure there's no accidental MathML there |
| 09:19 | <Hixie> | well then what you need is not "is this valid HTML without MathML" , but "does this contain any features unsupported by browsers X, Y, and Z" |
| 09:19 | <hsivonen> | Hixie: sure |
| 09:19 | <Hixie> | which isn't conformance (e.g. it shouldn't call out <marquee> really), and has nothing to do with specific versions of specs nor what is suggested in the 140 CP |
| 09:25 | <annevk> | Hixie, your issues/data.html is wrong it says "Estimated date for last e-mail based on the data above: 2009-08-17" |
| 09:25 | <Hixie> | that's because the line is increasing currently :-( |
| 09:25 | <Hixie> | it's not wrong :-( |
| 09:25 | <annevk> | when looking at all the data it is "Estimated date for last e-mail based on the data above: 2013-01-07" |
| 09:26 | <Hixie> | it's based on what you draw |
| 09:26 | <annevk> | mkay |
| 09:28 | <zcorpan> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/complete/ has two doctypes |
| 09:28 | <Hixie> | good times |
| 09:28 | <Smylers> | annevk: Re blog posts, Mike Cardwell's garnered a lot of attention last week (though was actually published a little earlier): https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 09:28 | <Hixie> | i wonder why |
| 09:28 | <hsivonen> | anyway, I tend to agree with Noah that it's definitionally odd to define conformance without being clear about what's included in the definition by reference |
| 09:29 | <hsivonen> | I haven't yet examined what further conclusions or changes Noah has proposed |
| 09:30 | <Hixie> | hsivonen: all that matters is whether the document conforms to the specs you care about |
| 09:31 | <Hixie> | hsivonen: why would we need any other definition? |
| 09:31 | <Hixie> | zcorpan: looks like it's Philip`'s fault. Or at least, I don't see anything on my end that could do that. |
| 09:31 | <zcorpan> | Philip`: ^ |
| 09:31 | <hsivonen> | Hixie: and if you want to establish a common understanding with someone else so that the two of you know you are talking about the same thing (so that you can collaborate)? |
| 09:32 | <Hixie> | hsivonen: write a spec |
| 09:32 | <Hixie> | it can be as simple as the "Specs" wiki page |
| 09:33 | <jgraham> | hsivonen: I doubt many of these "common understanding" scenarios map neatly onto spec divisions anyway |
| 09:33 | <Hixie> | i doubt any do actually |
| 09:33 | <hsivonen> | jgraham: that's very possible |
| 09:33 | <Hixie> | except maybe the theoretical future "what we should implement" one |
| 09:34 | <hsivonen> | I wonder if I should point out that validators are software just like browsers and validators are incomplete, buggy and changing, too |
| 09:34 | <Hixie> | yes |
| 09:34 | <jgraham> | hsivonen: Only if you can deal with the responsibility of shattering a thousand illusions |
| 09:34 | <Hixie> | maybe point out that the HTML4 conformance checkers never complied to the spec :-) |
| 09:34 | <jgraham> | ;) |
| 09:36 | <Hixie> | jgraham: added that point to http://wiki.whatwg.org/wiki/Objections_against_CPs_for_ISSUE-140 |
| 09:37 | <Hixie> | ok i should sleep |
| 09:37 | <Hixie> | nn |
| 09:37 | <jgraham> | gn |
| 09:43 | <annevk> | I have nothing about Change Proposals last week |
| 09:44 | <annevk> | did not seem interesting enough and I already have quite a long post |
| 09:47 | <zcorpan> | hmm. not sure what to think of IndexedDB using window.onerror |
| 09:50 | <annevk> | hmm |
| 09:50 | <annevk> | that shorturl was meant to read weekly-extensibility |
| 09:50 | <annevk> | WordPress keeps munging it or something |
| 09:50 | <annevk> | anyway |
| 09:50 | <annevk> | http://blog.whatwg.org/whatwg-extensibility |
| 09:52 | <zcorpan> | annevk: workers already had navigator.onLine |
| 09:52 | <annevk> | yeah, but not the events |
| 09:53 | <zcorpan> | right |
| 09:53 | <annevk> | I guess I could change it |
| 09:53 | <annevk> | I noticed that after I wrote the sentence and decided to not care |
| 09:53 | <annevk> | but I guess people might |
| 09:54 | zcorpan | cared just enough to point it out :) |
| 09:55 | <annevk> | fixed |
| 10:03 | <jgraham> | annevk: Your tense is inconsistent (at least) in the "on the List" section |
| 10:03 | <jgraham> | eg. "put forward a proposal" vs "finds an inconsistency" |
| 10:03 | <annevk> | hmm yeah |
| 10:03 | <jgraham> | Should all be past tense, I think |
| 10:04 | <annevk> | my English has not progressed beyond high school it seems, as I made the same mistakes back then! |
| 10:04 | <jgraham> | I expect my English has got worse since then |
| 10:06 | <annevk> | fixed I think |
| 10:06 | <annevk> | I did leave "figuring out" as I suspect that is still ongoing |
| 10:11 | <zcorpan> | hey, English is ever-changing! Maybe next week it'll be valid to mix tenses |
| 10:55 | <Philip`> | Hixie: Where is the multipage splitter for that version being run? (and what version of lxml does that machine have?) |
| 11:02 | <matjas> | annevk, thanks for writing about @csscommits :) |
| 11:39 | <annevk> | Philip`, I am running it |
| 11:40 | <annevk> | Philip`, could it be 2.7.8? |
| 11:40 | <annevk> | oh, 2.2.8 |
| 11:42 | <hsivonen> | has anyone had time to check if Chrome shipped the script execution code that broke LABjs into the stable channel? |
| 11:43 | hsivonen | wonders how Debian expects to be able to maintain Chromium 6.0.x over the Squeeze life time |
| 11:44 | <Philip`> | annevk: Oh, hmm, it looks like I made a change to the script when I updated lxml (probably to 2.2.8) |
| 11:44 | <Philip`> | to exclude the duplicate doctype |
| 11:45 | <Philip`> | but forgot to commit it |
| 11:45 | <annevk> | okay |
| 11:45 | <annevk> | I think my version of your script has local modifications too... |
| 11:47 | <Philip`> | http://code.google.com/p/html5/source/detail?r=182 |
| 11:49 | <annevk> | so lxml emits the HTML DOCTYPE? |
| 11:49 | <annevk> | interesting |
| 11:49 | <Philip`> | It puts the doctype in the DOM so the html5lib serialiser emits it, or something, I think |
| 11:50 | <Philip`> | but only with recent enough versions of lxml |
| 11:50 | <Philip`> | (Maybe they changed it to start recognising <!doctype html>) |
| 11:50 | <annevk> | I guess I should have covered http://lists.w3.org/Archives/Public/public-html/2011Feb/0113.html -- added for next week |
| 11:51 | <Philip`> | (This patch is kind of a hack but it seems to work) |
| 11:55 | <hsivonen> | heycam: the reason why I didn't find the single-page version of SVG 1.1 2nd ed. is that it isn't linked from http://www.w3.org/TR/SVG/ |
| 11:55 | <hsivonen> | I fail for reading /TR/ |
| 11:56 | <hsivonen> | must. never. read. /TR/ |
| 11:57 | <annevk> | Philip`, only if you use the html5lib serializer |
| 11:58 | <annevk> | Philip`, but I found out how I could fix this |
| 11:58 | jgraham | is considering writing a userjs that redirects you away from /tr/ if you accidentially end up there |
| 11:58 | <jgraham> | Or maybe just replaces the page with a big red FAIL message |
| 11:58 | <annevk> | duplicate DOCTYPE removed |
| 11:58 | <annevk> | yay |
| 11:59 | <annevk> | Smylers, hey, thanks |
| 11:59 | <annevk> | Smylers, I believe you are not supposed to refer directly to the other change proposal though |
| 11:59 | <annevk> | Smylers, they are meant to be standalone |
| 12:00 | <Smylers> | Huh? |
| 12:00 | annevk | checks |
| 12:00 | <Smylers> | A ‘counter’ change proposal can't explain what it's countering? |
| 12:01 | <Smylers> | Anyway, I'm still hacking on that page — I'll let you know here when I've finished playing with it. |
| 12:01 | <Philip`> | annevk: Oh, yeah, it won't help if you use the lxml serialiser, though I vaguely remember the lxml serialiser being buggy anyway |
| 12:01 | <annevk> | I guess it's okay |
| 12:02 | <annevk> | Philip`, well then complete/ is buggy |
| 12:02 | <annevk> | I have not installed html5lib |
| 12:02 | Philip` | doesn't remember what the bugs were, or if he's just imagining it |
| 12:02 | <Philip`> | Easiest way to test is to run it both ways and diff the output, I guess |
| 12:03 | <annevk> | I'll take the lazy approach and fix bugs as they are reported |
| 12:08 | <Philip`> | Hmm, I don't see any obvious differences except for character escaping style |
| 12:08 | <Philip`> | and attribute order |
| 12:09 | <Philip`> | and escaping "{" and "}" in URL attributes |
| 12:10 | <Philip`> | (and defaulting to emitting optional tags) |
| 12:46 | <Smylers> | annevk (and anybody else): http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-140 now includes everything I wish to say on ISSUE-140 |
| 12:47 | <Smylers> | Please edit, revert, and make less verbose at will. |
| 12:47 | <Smylers> | annevk: Thank you for starting this. I was planning on writing it anyway, so your start was a good help. |
| 12:47 | <Smylers> | hixie: And thank you for prodding me into actually doing it. |
| 12:48 | <Smylers> | I've left the summary alone, but am not sure it's now an accurate summary of the rest of the page. |
| 12:48 | <annevk> | feel free to change it |
| 12:53 | <hsivonen> | Smylers: what's the "Putting a Version Indicator in ‘Conforming Documents’ " section about? |
| 12:54 | <hsivonen> | I don't see Noah suggesting version indicators |
| 12:54 | <hsivonen> | oh. a version number in speech. not in the file |
| 12:54 | <Smylers> | Yeah. |
| 12:55 | <Smylers> | I don't like that heading either. |
| 12:55 | <Smylers> | But since Noah made a few separate changes, I felt the counter-proposal needed to address each of them separately. |
| 12:57 | <Smylers> | I meant literally putting a number in the middle of the term “conforming documents” as currently described by the spec. |
| 12:58 | <hsivonen> | fwiw, Noah's proposed changes match the current practice in the UI of Validator.nu |
| 12:59 | <Smylers> | Well for something other than the HTML spec to use the phrase “conforming HTML5 document” isn't tautologous. |
| 13:00 | <jgraham> | hsivonen: That may be taken as evidence that this is angels-on-the-head-of-a-pin stuff |
| 13:01 | <hsivonen> | jgraham: maybe, but the pushback surprises me |
| 13:03 | <Smylers> | I initially marked the proposal as one I wished to counter because of its attempt to replace the description of an applicable specification with something fictional. |
| 13:03 | <Smylers> | I'm guessing that isn't the part of Noah's proposal that Validator.nu is in accordance with? |
| 13:05 | <Smylers> | While I also don't agree with the ‘conforming document’ changes, at least they wouldn't be attempting to assert something that simply can't be. |
| 13:06 | <Smylers> | So I considered writing a separate counter change proposal, but I didn't want to think about what W3C process would do if there were two different zero-edit proposals to consider ... |
| 13:06 | <hsivonen> | Smylers: back when HTML5 did not have a normative reference to ARIA, Validator.nu started having a HTML5+ARIA validation target |
| 13:07 | <Smylers> | Indeed. And I don't think anything in the current draft spec contradicts that being a sane thing to do. |
| 13:07 | <hsivonen> | I don't see how that was different from AutomotiveExtension except for not being a fictional example |
| 13:08 | <hsivonen> | Smylers: there's nothing contradicting it. It just isn't clearly said that that's how "applicable specs" work |
| 13:08 | <Smylers> | OK. |
| 13:09 | <Smylers> | I think it is clear, but that's clearly a matter of judgement. |
| 13:09 | <karlcow> | http://www.gabrielweinberg.com/blog/2011/02/usability-issues-with-adding-search-engines-to-web-browsers.html |
| 13:10 | <Smylers> | And the parts I find clearest are the ones Noah's proposal cuts! |
| 13:20 | <webr3> | ''HTML5 redefines HTML, such that when it is published it obsoletes previous definitions: it will define a conforming document written in HTML, and indeed will be the only current definition of an HTML document.'' |
| 13:21 | <webr3> | is "HTML5" fully backwards compatible, or will the previously "conforming" documents no longer be "conforming" ? |
| 13:23 | <gsnedders> | Previous conforming documents will cease to be conforming. Previously conforming documents will be processed the same way as by existing UAs. |
| 13:23 | <hsivonen> | webr3: backwards-compat in the HTML context means that stuff "works" not that it validates |
| 13:24 | <Smylers> | Won't most previously conforming documents continue to conform? |
| 13:24 | <hsivonen> | Smylers: no. assuming that "most" previously conforming documents are Transitional |
| 13:25 | <webr3> | but if there's no such thing as "conforming", how can they be non conforming? |
| 13:25 | <karlcow> | webr3: validation is for writing/authoring documents, html parsing for reading/interpreting. |
| 13:26 | <karlcow> | the rules for writing are not the same than the rules for reading |
| 13:26 | <hsivonen> | it's not really clear to me why people care about old documents continuing to validate if they aren't updating the documents in any way |
| 13:26 | <karlcow> | http://www.w3.org/QA/2008/09/fixing-html-with-html5 |
| 13:26 | <hsivonen> | I understand that people don't want to change a lot of stuff if they update an old doc a bit and then validate |
| 13:26 | <webr3> | karlcow, cheers and yup, i can see that in 1.2 of html5-diff |
| 13:41 | <webr3> | so, given all the specs that can affect things, the different versions of each (even if that's just hg revision up), it's not really possible to define what one would even be conforming to? html r.11425 + css 2.1 r.2342 + js r.185 + ... |
| 13:44 | <annevk> | hsivonen, HTML5+ARIA as a temporary experimental setting seems fine, but eventually I would expect that option to disappear |
| 13:44 | <annevk> | hsivonen, I do not think that standards need to give advice on temporary experimental validator UI |
| 13:46 | <karlcow> | http://jeremie.patonnier.net/post/2011/02/07/Why-are-SVG-Fonts-so-different |
| 13:49 | <hsivonen> | karlcow: so the use case for SVG fonts is animated fonts??? |
| 13:49 | <jcranmer> | not quite my thought |
| 13:50 | <jcranmer> | I basically read it as "the use cases for SVG fonts require what the implementors don't support" |
| 13:50 | <karlcow> | hsivonen: not what the article says. |
| 13:50 | <hsivonen> | jcranmer: if the use cases are what aren't now supported, seems all the more reason not to get on the slippery slope! |
| 13:51 | <hsivonen> | annevk: I expect HTML5+SVG *1.1* (rather than 1.2) to stick around for quite a while |
| 13:53 | <karlcow> | the article says: SVG Fonts very good for custom fonts design such as logos. Possible to do amazing things with animation but not necessary wise (aka design-wise), possibility to modify the font on the fly (styling, dom) through scripting. |
| 13:54 | <annevk> | hsivonen, SVG 1.2 is also not widely implemented by browsers so that seems natural |
| 13:55 | <hsivonen> | annevk: natural, yes, but my point is that one needs to say "1.1" to avoid ambiguity |
| 13:55 | <annevk> | hsivonen, I would expect the validator to sit somewhere between the features authors want and the features users agents supply |
| 13:56 | <annevk> | hsivonen, in the UI? I doubt most authors would care |
| 13:56 | <zcorpan> | karlcow: do browsers support changing the font on the fly? |
| 13:57 | <hsivonen> | annevk: yes, in the UI |
| 13:59 | <annevk> | I hope it evolves into something like "is my markup conforming?" "well yes, it is" |
| 13:59 | <annevk> | with a "more details" link for when I really cared |
| 14:01 | <hsivonen> | annevk: interesting. that's totally contrary to the rhetoric I used when arguing against syntax-level versioning |
| 14:05 | <annevk> | I like to view it how I use CSS. With CSS there's a bunch of features among disparate specs that I like to use. I do not care about how/where/why. I just want to know whether I use CSS correctly given the large intersect of specifications. |
| 14:05 | <hsivonen> | ITYM s/intersect/union/ |
| 14:05 | <hsivonen> | right? |
| 14:05 | <annevk> | sorry, yeah |
| 14:45 | <annevk> | fyi: http://annevankesteren.nl/2011/02/leave-of-absence |
| 14:49 | <wilhelm> | What's the planned route (if any)? (c: |
| 14:52 | <jgraham> | wilhelm: You planning to send runners after annevk to make him work? |
| 14:53 | <wilhelm> | No, I very much approve of a long leave of absence for travel. I'm just curious. I haven't explored that continent yet. (c: |
| 14:53 | <Peter`> | antti_s, so who's going to take over the last week posts? :-) |
| 14:53 | <Peter`> | Uh. annevk ^ |
| 14:54 | <jgraham> | Peter`: Are you volunteering? ;) |
| 14:54 | <Peter`> | I already write last week posts :) |
| 14:55 | <jgraham> | Peter`: Right, so you are an expert :) |
| 14:55 | <Peter`> | I won't have time for it, sorry :( |
| 14:56 | <jgraham> | :) I wasn't really trying to pressure you into it |
| 14:57 | <annevk> | wilhelm, Bogotá - Buenos Aires |
| 14:57 | <annevk> | wilhelm, and some places inbetween :) |
| 14:57 | <annevk> | but really that is all that is certain |
| 14:57 | <annevk> | Peter`, nobody volunteered so far |
| 14:58 | <annevk> | Peter`, so it might be that just as when markp stopped doing them there will be another gap |
| 14:58 | <wilhelm> | annevk: Fun. (c: |
| 14:59 | <Peter`> | Your blog post hints that you won't be active between June 16th and the end of June either, that would certainly a nice period of time to fill the gap! |
| 15:00 | <Peter`> | A large part of the people who read it will receive public-html/whatwg mail anyway |
| 15:00 | <annevk> | I expect to be catching up then, so yeah I suppose I might write a longish entry |
| 15:01 | <annevk> | a first "WHATWG Quarterly Results" |
| 15:01 | <annevk> | well, maybe not results :p |
| 15:02 | <Peter`> | hah |
| 15:03 | <karlcow> | https://wiki.mozilla.org/File:Firefox2011RoadmapImage1.png |
| 15:03 | <Philip`> | The spec bug reporting form seems to be getting much more abused recently :-( |
| 15:04 | <Peter`> | karlcow, "Ship Firefox 4, 5, 6 and 7 in the 2011 calendar year" |
| 15:05 | <karlcow> | yep from https://wiki.mozilla.org/Firefox/Roadmap |
| 15:05 | <jgraham> | I was about to say, the containing document is way more interesting |
| 15:05 | <Lachy> | Philip`, the spec bug reporting form is a constant annoyance that has several problems that need to be fixed. |
| 15:07 | <jgraham> | If it rejected things that look like markup it would cut down the spam greatly |
| 15:07 | <Peter`> | http://blogs.msdn.com/b/interoperability/archive/2011/02/04/the-indexeddb-prototype-gets-an-update.aspx |
| 15:07 | <jgraham> | Of course spammers might just work around that |
| 15:08 | <Ms2ger> | Then I wouldn't be able to paste the graduation example into it! |
| 15:08 | <Philip`> | jgraham: Hmm, it seems kind of a bad idea to ban HTML markup from HTML spec bug reports |
| 15:09 | <jgraham> | Philip`: s/look like/starts with text that looks like/ maybe |
| 15:10 | <gsnedders> | Peter`: What's the tl;dr? |
| 15:11 | <Lachy> | jgraham, the form should simply not submit bugs directly to bugzilla anonymously, but rather open up bugzilla with the fields filled out ready to be submitted by logged in users. |
| 15:11 | <Philip`> | gsnedders: The IndexedDB prototype got an update |
| 15:11 | <Lachy> | gsnedders, tl;dr is "too long; didn't read" |
| 15:11 | <gsnedders> | Philip`: Oh, okay. :P |
| 15:11 | <gsnedders> | Lachy: I know. |
| 15:11 | <Lachy> | oh, then I misunderstood what you were asking |
| 15:12 | <jgraham> | Lachy: Is that even possible? |
| 15:12 | <Peter`> | gsnedders, just updated to a newer version of the specification |
| 15:12 | <Peter`> | e.g. updates that other vendors who are implementing IndexedDB barely mention |
| 15:12 | <Peter`> | (as far as I can see, WebKit already adopted these changes) |
| 15:13 | <Lachy> | jgraham, I was looking at the wrong link and thought gsnedders was asking about the tl;dr in the Firefox roadmap. |
| 15:13 | <jgraham> | Lachy: "the form should simply not submit bugs directly to bugzilla anonymously" |
| 15:14 | <jgraham> | etc. |
| 15:14 | Philip` | finds it mildly amusing that the "tl;dr" acronym contains a semicolon |
| 15:15 | <Lachy> | oh, right. Yes, that should be possible. bugzilla has ways to provide values for the fields via the query string |
| 15:15 | <Philip`> | given the contrast between the gratuitously obscure grammar and the intentional ignorance/laziness implied by the statement |
| 15:16 | <Lachy> | so when you write a summary in the box and click the button, it should open up bugzilla within an iframe with various fields pre-filled based on what you enter, and then within that you can amend it and submit when ready |
| 15:17 | <Philip`> | Lachy: The avoidance of needing to register and log in, and the avoidance of the Bugzilla UI, seem like most of the value the bug reporting form provides, and it'd be pretty pointless if you got rid of those |
| 15:18 | <Ms2ger> | ^ |
| 15:18 | <Philip`> | Filling in a few drop-down boxes is a fairly trivial part of the process, if you're having to do it through Bugzilla anyway |
| 15:18 | <Lachy> | Philip`, the form provides convenience and simply staying logged in should not be a hassle |
| 15:19 | <Lachy> | the other alternative would be to continue allowing anonymous posts, but require that the anonymous posts go through a moderation queue first |
| 15:20 | <karlcow> | tl;dr is "too long; didn't read" is the recent new black in acronym world. geek fashionistas and coders tabloids |
| 15:31 | <jgraham> | And purple sprouting broccoli is the new asparagus |
| 15:31 | <jgraham> | (except it isn't, of course) |
| 15:33 | <annevk> | Opera is not part of the Web Platform per Mozilla? teehee |
| 15:35 | <Ms2ger> | Opera? What's that? |
| 15:35 | <jgraham> | It's the thing where fat ladies sing |
| 15:36 | <Ms2ger> | Oh |
| 15:36 | <Ms2ger> | Not sure why that'd be part of the Web Platform |
| 15:36 | <karlcow> | annevk: Opera is the green box labeled the Web Platform. |
| 15:36 | <gsnedders> | jgraham: So when Opera ships something, it's outdated and over? |
| 15:37 | <jgraham> | karlcow: So everyone else is built atop Opera? |
| 15:37 | <karlcow> | jgraham: exactly ;) |
| 15:37 | <jgraham> | gsnedders: No, it's just that Opera is a precondition for armageddon |
| 15:40 | <karlcow> | the browser icons also give a very limited view of the Web platform |
| 15:59 | <jgraham> | Anyone know of any tests for the mimesniff draft? |
| 16:00 | <Ms2ger> | Submission welcome ;) |
| 16:01 | <jgraham> | Well yes, but maybe someone did it already :) |
| 16:01 | <annevk> | I suspect abarth has some |
| 16:01 | <annevk> | and Hixie wrote tests |
| 16:08 | jgraham | wishes said tests were trivial to find |
| 16:08 | <jgraham> | unrelated observation that was already discussed some months ago: ln.hixie.ch is more ugly now |
| 16:16 | <annevk> | http://hixie.ch/tests/adhoc/http/content-type/sniffing/ |
| 16:16 | <annevk> | https://github.com/abarth/ietf-websec does not look like adam has tests though he must have written some when implementing it in WebKit |
| 16:16 | <annevk> | Gecko must have tests too |
| 16:18 | <annevk> | I deleted over 700 emails today |
| 16:18 | <annevk> | progress |
| 16:19 | <jgraham> | annevk: Thanks |
| 16:20 | <jgraham> | Hmm, Hixie's tests don't cover what I want (specifically feed sniffing) |
| 16:20 | <jgraham> | I feel like I am going to end up reinventing the wheel here |
| 16:21 | <Ms2ger> | Make sure you reinvent the wheel somewhere it can be found, then ;) |
| 16:25 | <annevk> | can't find tests in Gecko |
| 16:25 | <annevk> | just patches without tests |
| 16:25 | <annevk> | climbing time |
| 16:52 | <TabAtkins> | I volunteer to moderate the anonymous queue. I agree that the spam is getting worse, at several per day. I think the spam volume is roughly on par with the legitimate volume now. |
| 16:57 | <miketaylr> | I can help moderate as well |
| 16:57 | <TabAtkins> | We just need to actually make a queue, as I imagine right now it just autosubmits to Bugzilla. |
| 17:02 | <TabAtkins> | Wow, we got a ton of new people giving feedback in the csswg list over the weekend. |
| 17:02 | <TabAtkins> | I wonder if something in particular caused it? |
| 17:08 | <Ms2ger> | TabAtkins, weren't those old mails that got stuck in some moderation queue? |
| 17:08 | <TabAtkins> | Ms2ger: Were they? |
| 17:09 | <Ms2ger> | Some were, afaict |
| 19:15 | <TabAtkins> | Phew. Two hours later, done with replies to a single thread. |
| 19:16 | <espadrine> | Are iframes bad? Someone just told me he was afraid of using them. |
| 19:16 | <Ms2ger> | No |
| 19:17 | <TabAtkins> | No, though I've certainly seen them misused. |
| 19:17 | <espadrine> | Ah, good. I can feel good about myself then. |
| 19:21 | <espadrine> | Is the srcdoc element of iframe implemented somewhere? |
| 19:21 | <TabAtkins> | I don't think it's public yet, but it implemented somewhere in Chrome. |
| 19:21 | <Ms2ger> | Don't think so |
| 19:25 | <espadrine> | How exactly is <iframe srcdoc="<p>hello"></iframe> different from <iframe src="data:text/html,<!doctype html><title></title><p>hello"></iframe> ? |
| 19:25 | <TabAtkins> | Simpler escaping requirements, mainly. |
| 19:26 | <espadrine> | ah, good. thanks! |
| 19:26 | <AryehGregor> | Also, we're hoping that all browsers that implement srcdoc will implement sandbox. |
| 19:26 | <TabAtkins> | The only character you need to escape for security in @srcdoc is " (you need to escape & as well to keep from accidentally swallowing small bits of content, but it's not important for security). |
| 19:26 | <AryehGregor> | So if you do <iframe sandbox srcdoc="<p>hello"></iframe>, you're hopefully guaranteed that it will be sandboxed if it appears at all. |
| 19:27 | <TabAtkins> | Yup. |
| 19:27 | <TabAtkins> | Note that escaping requirements is the big advantage over things like <sandbox></sandbox>, too. |
| 19:48 | <estellevw> | is the w3.org website down, or is it just me? |
| 19:49 | <estellevw> | back up, never mind |
| 20:42 | <AryehGregor> | Hixie, what sorts of tests should I write for createContextualFragment()? It seems like any tests would necessarily test the text/html parser to some extent, but I don't actually know much of anything about the text/html parser, so those tests should probably be written about someone else (and be put somewhere else, like in the HTML5 test suite). |
| 20:42 | <AryehGregor> | Perhaps I could compare behavior to innerHTML, or only test simple cases where the parsing is clear? |
| 20:43 | <AryehGregor> | Actually, in some cases it tests the XML fragment parsing algorithm, too. |
| 20:49 | AryehGregor | has no idea what "Unmark all scripts in new children as 'already started'." means |
| 21:04 | <Ms2ger> | AryehGregor, that means that scripts will run when inserted into the doc |
| 21:04 | <AryehGregor> | Okay, that sounds testable. |
| 21:04 | <Ms2ger> | hsivonen probably has tests |
| 21:04 | <AryehGregor> | How can I determine a Node's namespace from JavaScript? |
| 21:04 | <Ms2ger> | Node.namespaceURI |
| 21:05 | <Ms2ger> | Actually, that's on Element in Web DOM Core |
| 21:05 | <AryehGregor> | Oh, I was looking at Node and that's on Element. |
| 21:05 | <AryehGregor> | Well, that makes my life easier. |
| 21:05 | <AryehGregor> | Although I think I found a bug in the spec while I was at it, so let me report that. |
| 21:05 | <AryehGregor> | Or maybe not. |
| 21:05 | <Ms2ger> | Which? |
| 21:05 | <AryehGregor> | Maybe it's only a WebKit bug? |
| 21:05 | <othermaciej> | I don't think non-Element Nodes have a namespace URI |
| 21:05 | <Ms2ger> | Attrs, too |
| 21:05 | <AryehGregor> | data:text/html,<!doctype html><script>alert(document.createElement("test").lookupNamespaceURI(null));</script> |
| 21:06 | <AryehGregor> | Spec says that should alert null, WebKit alerts the namespace. |
| 21:06 | Ms2ger | knows nothing about lookupNamespaceURI |
| 21:06 | <othermaciej> | what does lookupNamespaceURI do? |
| 21:06 | <Ms2ger> | annevk might remember |
| 21:06 | <AryehGregor> | But the definition of isDefaultNamespace() seems to suggest that calling lookupNamespaceURI(null) should return a string in some cases: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-isdefaultnamespace |
| 21:06 | <heycam> | it either looks up a namespace uri based on a prefix |
| 21:06 | <heycam> | or the reverse |
| 21:06 | <heycam> | i can never remember |
| 21:07 | <AryehGregor> | But the definition of lookupNamespaceURI() implies that passing null should always return null, at least for an element . . . |
| 21:07 | AryehGregor | files a spec bug |
| 21:08 | <othermaciej> | is lookupNamespaceURI(null) supposed to give you the default namespace, or always null? |
| 21:08 | <annevk> | AryehGregor, the spec says it should return the namespace actually |
| 21:08 | <annevk> | AryehGregor, because if you pass null and namespace prefix of the node in question is null, the argument and namespace prefix match |
| 21:09 | <annevk> | AryehGregor, and you can return the namespace |
| 21:09 | <AryehGregor> | Oh. |
| 21:09 | <AryehGregor> | Confusing. |
| 21:09 | <annevk> | it's like the first step |
| 21:09 | <annevk> | "If its namespace is not null and its namespace prefix is prefix return namespace and terminate these steps." |
| 21:09 | <AryehGregor> | Yeah, I didn't realize namespace prefixes could be null. |
| 21:09 | <AryehGregor> | I assumed they'd just be the empty string or something. |
| 21:09 | <AryehGregor> | Anyway, I'll use namespaceURI. |
| 21:09 | <annevk> | "Unless explicitly given when an Element node is created, its namespace and namespace prefix are null" |
| 21:09 | <Dashiva> | I had the fortune to be using the tidy java implementation of org.w3c.dom today. |
| 21:10 | <Dashiva> | public boolean hasAttribute() { return false; } |
| 21:10 | <AryehGregor> | Now, is there any official way to figure out if a Document is an HTML or XML document? Or should I just test something like whether tagName gets uppercased? |
| 21:10 | <AryehGregor> | . . . |
| 21:10 | <annevk> | no official way |
| 21:10 | <othermaciej> | it would be kind of convenient to have an official way but there is not |
| 21:11 | <Dashiva> | Apparently it's not tidy enough to throw UnsupportedOperationException(), instead you put "not implemented" in the javadoc that nobody's going to see because it's hidden by the interface doc |
| 21:11 | <Ms2ger> | AryehGregor, whether we're going to use the XML parser for all these things is still up in the air |
| 21:11 | <AryehGregor> | For all which things? |
| 21:12 | <Ms2ger> | createContextualFragment and friends |
| 21:12 | <AryehGregor> | Oh. |
| 21:12 | <AryehGregor> | So currently it always uses the HTML parser? |
| 21:12 | <AryehGregor> | Should I just not test the XML case? |
| 21:12 | <AryehGregor> | The spec should probably say that in a note, if so. |
| 21:12 | <Ms2ger> | Probably |
| 21:12 | <AryehGregor> | (Also, someone should update this page to point to the spec: https://developer.mozilla.org/en/DOM/range.createContextualFragment ) |
| 21:25 | <AryehGregor> | Oh look, createContextualFragment() behaves totally differently in WebKit, Gecko, and Opera. |
| 21:25 | <AryehGregor> | Hurrah. |
| 21:25 | <annevk> | film at 11 |
| 21:25 | <AryehGregor> | Actually, WebKit just throws NOT_SUPPORTED_ERR, so maybe it just throws unconditionally. |
| 21:25 | <Ms2ger> | Nah |
| 21:26 | <othermaciej> | WebKit has createContextualFragment() |
| 21:26 | <othermaciej> | I added it myself! |
| 21:26 | <othermaciej> | in, like, 2002 |
| 21:26 | <annevk> | -> naptime |
| 21:26 | <AryehGregor> | Why does it throw NOT_SUPPORTED_ERR here, then? http://aryeh.name/spec/dom-parsing-and-serialization/test/createContextualFragment.html |
| 21:27 | <AryehGregor> | Ms2ger, what's the practical difference between <html> and <body> being the context element? |
| 21:27 | AryehGregor | wonders why he's writing tests for this when he doesn't have any idea how the HTML parser works |
| 21:28 | <Hixie> | to learn how it works :-) |
| 21:29 | <AryehGregor> | Should I spend a few days reading the text/html parser algorithm? It doesn't seem to have to do with anything else I'm doing right now. |
| 21:29 | <Ms2ger> | Then we've got four people who understand it |
| 21:29 | <Hixie> | sure |
| 21:29 | <Hixie> | the more people understand it the better |
| 21:29 | <Hixie> | and if you're gonna be working on stuff related to it, best to know it |
| 21:30 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=585819 |
| 21:30 | <Ms2ger> | AryehGregor, ^ |
| 21:30 | <AryehGregor> | I'd think it would be more useful if I stuck to DOM Range and contenteditable, since there's mounds of stuff to do there and it has nothing to do with text/html parsing. |
| 21:30 | <AryehGregor> | But I could read the parser algorithm if you like. |
| 21:30 | <AryehGregor> | Ms2ger, ah, makes sense. |
| 21:31 | <AryehGregor> | Actually, that was the first thing I tried, but I wasn't sure I should be testing it specifically. But if it broke a site, then clearly that's what should be tested. |
| 21:32 | <Ms2ger> | The patch includes a test, fwiw |
| 21:32 | <AryehGregor> | Even easier. |
| 21:32 | <Ms2ger> | And https://bugzilla.mozilla.org/show_bug.cgi?id=599588 has one for scripts |
| 21:33 | <Hixie> | AryehGregor: it's up to you |
| 21:33 | <AryehGregor> | Okay. |
| 21:34 | <Hixie> | AryehGregor: but if you do want to learn the parser, you can definitely consider it part of the work |
| 21:34 | <AryehGregor> | Sure. |
| 21:37 | jgraham | suggests that reading the parser algorithm is not the most effective way to understand it |
| 21:38 | Philip` | suggests that implementing it is a good way |
| 21:39 | <jgraham> | AryehGregor: So you have the whole universe of languages to chose from except python, PHP and java |
| 21:39 | <jgraham> | choose |
| 21:40 | <AryehGregor> | Too bad that includes a) my favorite language, b) the only language I'm really familiar with. |
| 21:40 | <Dashiva> | And ocaml |
| 21:40 | <AryehGregor> | Maybe I can take it as an opportunity to learn Haskell! |
| 21:40 | <AryehGregor> | I can learn two things at once that way. |
| 21:40 | <Dashiva> | Why not go? |
| 21:40 | <TabAtkins> | It's an official Google language now! |
| 21:40 | <Dashiva> | \hipstercat |
| 21:42 | <jgraham> | A Haskell implementation would be awesome |
| 21:42 | <Philip`> | Some of the spec's algorithms really don't map very well onto functional languages |
| 21:42 | <jgraham> | I occasionally think it would be a good way to learn haskell |
| 21:42 | <Philip`> | but if you reverse-engineer them to figure out what they're actually doing, you can reimplement them and check it at least passes the test cases |
| 21:42 | <jgraham> | Then I realise what I really mean is "challenging" |
| 21:43 | <TabAtkins> | jgraham: Hahaha. |
| 21:44 | <Dashiva> | jgraham: Okay, fine, do it in FORTRAN then |
| 21:45 | <jgraham> | Dashiva: I know a fair amount of Fortran 90... but yeah the idea isn't making me happy :) |
| 21:45 | <Dashiva> | 90? Bah, humbug |
| 21:45 | <Dashiva> | 77 is all you need |
| 21:47 | <jgraham> | Well only if you are a masochist^Wacademic |
| 21:47 | <Dashiva> | But honestly, I didn't find it that bad |
| 21:48 | <jgraham> | Hmm, maybe doing it in F90 wouldn't be so hard |
| 21:48 | <Dashiva> | I think people just overrate it because it's often mentioned in the same sentence as COBOL |
| 21:48 | <jgraham> | But supremely pointless |
| 21:48 | <TabAtkins> | This frightens me: "@var $b Roman"; p { font-family: "Times New $b; }" |
| 21:48 | <jgraham> | Oh, for numerics Fortran is nicer than C |
| 21:49 | <Ms2ger> | TabAtkins, and it should! |
| 21:49 | <jgraham> | TabAtkins: Why? |
| 21:51 | <AryehGregor> | TabAtkins, that should be illegal. |
| 21:52 | <AryehGregor> | (just on principle) |
| 21:52 | <TabAtkins> | AryehGregor: Indeed, and it is. Holy god, it is. |
| 21:52 | <TabAtkins> | jgraham: Variables as character-level macros are an abomination. |
| 21:52 | <Ms2ger> | TabAtkins, http://krijnhoetmer.nl/irc-logs/whatwg/20101230#l-326 |
| 21:53 | <TabAtkins> | Ms2ger: Huh, wonder how I missed that last year. |
| 21:53 | <TabAtkins> | Um, that might work. pending() still confused me a bit. |
| 21:53 | <Ms2ger> | Marvelous Hixieisms |
| 21:53 | <TabAtkins> | Also: nobody implements it. display:marker is a much more restricted form, and probably easier to implement. |
| 21:54 | <Hixie> | pending() is a terrible idea |
| 21:54 | <Hixie> | please find a better solution |
| 21:54 | <TabAtkins> | Will do. |
| 21:55 | <Ms2ger> | :( |
| 21:55 | <TabAtkins> | When I pick up G&RC I'll be ripping out most of it so it can just function as a place to specify already-existing things better. |
| 21:55 | <TabAtkins> | Then I'll review what was ripped out for G&RC 2. |
| 21:55 | <TabAtkins> | s/2/4/, I guess. |
| 21:56 | <TabAtkins> | Our numbering is confusing on purpose. |
| 21:56 | <TabAtkins> | Anyway, I'm off to a meeting. bbl |
| 21:56 | <Ms2ger> | It is the Garbage Collection Placeholder Module, after all |
| 22:02 | <othermaciej> | what's G&RC? |
| 22:02 | <Peter`> | Generated and Replaced Content |
| 22:02 | <Peter`> | http://www.w3.org/TR/css3-content |
| 22:40 | <othermaciej> | ah |
| 22:49 | <TabAtkins> | Ms2ger: You're confusing G&RC with GPCM. |
| 22:49 | <TabAtkins> | s/GPCM/GCPM/ |
| 23:26 | <key> | hello |
| 23:27 | <Hixie> | hello |
| 23:27 | <key> | i've been developing since '97, the 3.2 days. i've been involved in the evolution of the digital world ever since. i feel <article> is good in concept, but poor in name. article implies syndication, journalism, etc written work. whereas the semantic purpose is more for the 'main content' of a page. i suggest <content> instead |
| 23:28 | <key> | section and content are perfectly dialectic. 1 syntactic, 1 semantic |
| 23:28 | <Hixie> | <article> is for syndication |
| 23:28 | <Hixie> | see the spec :-) |
| 23:28 | <hober> | But <article> can be used in secondary, non-main-part-of-the-page places |
| 23:28 | <TabAtkins> | Syndication is more-or-less the semantic you want for <article>, though. <article> is a section that is appropriate for linking to individually. |
| 23:28 | <key> | see, this is the ambiguity i'm talking about |
| 23:28 | <AryehGregor> | It's probably too late to change the names. Some of them aren't quite right, but we'll never have a stable spec if we keep on arguing about them. |
| 23:29 | <hober> | and, of course, you can have multiple first-level <article>s |
| 23:29 | <hober> | there's no ambiguity |
| 23:29 | <Hixie> | the word "syndication" is in the first sentence of the definition of <article> in fact |
| 23:29 | <AryehGregor> | Not that we'll ever have a stable spec anyway. |
| 23:29 | <AryehGregor> | Nor do we want one. But this part could be stable. |
| 23:29 | <key> | if a corporate site uses a menu for site structure + context, the main content of the page would not be proper for syndication |
| 23:29 | <hober> | so you shouldn't use <article> in that case |
| 23:30 | <key> | yet it would still be helpful to denote the 'main content' of the page |
| 23:30 | <hober> | the main content is everything besides the non-main content |
| 23:30 | <key> | what, so we have use-speicific tags now? TBL be damned |
| 23:30 | <key> | yes |
| 23:30 | <hober> | if you must, call it <div id="main"> |
| 23:30 | <key> | and it should have a semantic identity |
| 23:31 | <key> | uh, weak. i literally know a whole camp of html 5 developers who are using the perceived looseness of article to refer to their main content, even if not intended for distribution |
| 23:31 | <key> | i don't even see why there's a tag for content on the basis of syndication or not |
| 23:31 | <key> | again, <article> should be renamed <content> |
| 23:31 | <AryehGregor> | People misuse everything. |
| 23:32 | <hober> | There are lots of web pages on which it's semantically appropriate to use <article> for what you're calling the main content. There are many web sites where that's inappropriate from a semantic standpoint. It just depends on the page. |
| 23:32 | <key> | and this is why the web is a toilet to dev for; lazy spec developers |
| 23:32 | <key> | let me ask this: do you expect large corporations to wrap their page specific content in <article>? |
| 23:33 | <hober> | no. I expect them to wrap articles in <article>. |
| 23:33 | <tantek> | if they would syndicate it as an independent item of content in a feed - then yes, I would expect them to wrap it in an <article> |
| 23:33 | <key> | corporate web sites are not intending to distribute their page content sans context. you and i both know this. |
| 23:33 | <TabAtkins> | tantek: And that's equivalent to what hober said. ^_^ |
| 23:33 | <key> | do you guys not see the gap i'm shining light on? |
| 23:33 | <Hixie> | key: if we rename <article> to <content>, people will think it's for their main content, when it is in fact for syndication. |
| 23:33 | <hober> | key: we see that there's currently no eelemtn for "the main section of the page" |
| 23:33 | <key> | the syndication attribute of article needs to be removed, leaving a generic <content> |
| 23:33 | <tantek> | TabAtkins - no hober said articles in <article> - that's a tautology :P |
| 23:33 | <hober> | but that has nothing to do with <article. |
| 23:34 | <key> | no, <content> would be for any unit of content |
| 23:34 | <key> | whole and complete |
| 23:34 | <tantek> | key - that's what <section> is for |
| 23:34 | <Hixie> | we already have a generic "main content of page" element, it's <body> |
| 23:34 | <key> | heh |
| 23:34 | <hober> | Hixie: indeed, I misspoke |
| 23:34 | <key> | yea, the spec sure is tight and clean. |
| 23:34 | <TabAtkins> | tantek: Only if you claim that the "article-ness" of a piece of content is defined solely through what it's wrapped in. |
| 23:34 | <tantek> | and now you understand the difference between <body> <section> and <article> |
| 23:34 | <key> | hixie, there is a difference just as there is HEAD and HEADER |
| 23:34 | <TabAtkins> | tantek: If you assume that article-ness if an independent quality, then it makes sense. |
| 23:35 | <tantek> | congratulations - quick, write it up in an FAQ :) |
| 23:35 | <key> | 1 is for message, the other is semantic |
| 23:35 | <hober> | tantek: it's probably already in there |
| 23:35 | <Hixie> | <head> is a historical artefact, <header> is to help authors not have to use <div> for a common class="header" case |
| 23:35 | <tantek> | hober - if so, point to it :P |
| 23:35 | tantek | is not particularly fond of <head> either |
| 23:36 | <key> | hixie, there is the structure of the message, then there is the semantic partitioning of the content (body) of the message |
| 23:36 | <key> | uh |
| 23:36 | <key> | you guys should /not/ be developing specs for the web |
| 23:36 | <Hixie> | you are welcome to do it in our stead :-) |
| 23:36 | <tantek> | key - you're welcome to fork and do a better job :P |
| 23:36 | <tantek> | lol |
| 23:36 | <key> | i'm actually working on it |
| 23:36 | <Hixie> | the spec is under a license that allows forking for exactly this reason |
| 23:37 | <Hixie> | all you have to do is convince the browser vendors that you're doing a better job, and your spec will be the official one :-) |
| 23:37 | <Hixie> | or at least, as official as the whatwg's one today |
| 23:37 | <key> | i'm sorry you guys want to squeeze everything web into the character of a blog. |
| 23:37 | <tantek> | key - no need to strawman - https://secure.wikimedia.org/wikipedia/en/wiki/Straw_man |
| 23:38 | <key> | i know what strawman means, and i did not ply that scheme |
| 23:38 | <hober> | tantek: looks like it's not in there. Hence my 'probably' :) |
| 23:38 | <key> | having a tag so semantically rigid as article is in fact a poor choice |
| 23:39 | <hober> | Hey, it sure beats <address> |
| 23:39 | <AryehGregor> | This is why open-source licenses are neat. They give you a way to tell people to shut up while at the same time feeling smug and self-righteous about it. |
| 23:39 | <key> | i like most of the idea behind it, but it shouldn't imply anything re syndication! |
| 23:39 | <hober> | HTML has lots of weird elements, <article> is on the less weird end of things |
| 23:39 | <key> | so we lower our standards vs increasing them hober? |
| 23:39 | <key> | i mean, wtf does that comment even mean? |
| 23:39 | <hober> | key: then just think of it being an independent section, and forget anyone said anything about syndication |
| 23:39 | <hober> | key: see the topic |
| 23:39 | <AryehGregor> | key, the fact is, you're not the one deciding what goes into the WHATWG's HTML spec. So you can either try to convince people, or agree to disagree. Just telling us we're wrong is not really very useful. |
| 23:40 | <tantek> | key - your statement "you guys want to squeeze everything web into the character of a blog" is a misrepresentation of our positions |
| 23:40 | <key> | hober, but you damn well know the 'syndication' reference will give cover to people who want to scrape and rape ppl's content |
| 23:40 | <Hixie> | key: the idea behind <article> is exclusively to allow syndication, so if you don't like that, you don't like the idea behind <article>. Which is fine, but you'll find it easier to convince us if you start from the standpoint of what you actually want than saying you agree to something you actually disagree with. |
| 23:40 | <hober> | wait, what? |
| 23:40 | <tantek> | ergo strawman |
| 23:41 | <AryehGregor> | I'd call it more like a "flame". |
| 23:41 | <AryehGregor> | A straw man is really more when you *counter* an argument that your opponent doesn't hold. |
| 23:41 | <key> | nah. moment, let me ponder |
| 23:41 | <TabAtkins> | key: Your entire conversation so far has been a massive pile of insult, distortion, and flame. This is not how you conduct conversations. |
| 23:41 | <AryehGregor> | Not when you merely accuse them of holding it. |
| 23:41 | <key> | AryehGregor: yep you got it |
| 23:41 | <AryehGregor> | The whole point of the analogy is that straw men are easy to defeat, because they don't fight back. |
| 23:41 | <TabAtkins> | At least, not if you want to actually accomplish anything besides getting ignored. |
| 23:42 | <Hixie> | wait what? now we're condoning rape? |
| 23:42 | <AryehGregor> | If they aren't trying to counter the argument, it's not really appropriate to call it a straw man, IMO. |
| 23:42 | <jcranmer> | . . . ? |
| 23:42 | <Hixie> | man, this conversation went sour fast |
| 23:42 | <key> | relax |
| 23:42 | <jcranmer> | I just happened to look here and we're talking about rape? |
| 23:42 | <key> | there seems to be 2 sides to article |
| 23:42 | <jcranmer> | what kind of logic is... oh |
| 23:42 | <key> | 1. syndication being implied. 2. unit of content; whole and complete |
| 23:42 | <key> | i like 2, i think 1 is less useful |
| 23:43 | <hober> | ok, so just don't worry about 1 then |
| 23:43 | <hober> | how does it affect you? |
| 23:43 | <key> | <content> would be semantically organizational, whereas <section> would be structurally organizational |
| 23:43 | <key> | because we need a tag like it, semantically, but better |
| 23:43 | <key> | hence <content> |
| 23:43 | <hober> | the semantic of what you think of as <content> is different from <article>, and this is orthogonal to the syndication thing |
| 23:43 | <key> | if it's about syndication, <article> should inherit from <content>, not <section> |
| 23:44 | <hober> | no, because it's sensible for a page to have many <article>s on it |
| 23:44 | <key> | yes and? |
| 23:44 | <hober> | and, assuming I understand you when you talk about the nonexistent <content> tag, it would only be once a page |
| 23:44 | <key> | it's also sensible for an article to be spread over multiple pages |
| 23:44 | <key> | not necessarily |
| 23:44 | <key> | the same as article, just with no implication re syndication; which is just odd |
| 23:45 | <key> | i mean fuck, why don't you guys just make a <lolcats> tag? would compliment well your blog tags |
| 23:45 | <hober> | I give up. |
| 23:46 | <AryehGregor> | key, are you trying to be constructive here? |
| 23:46 | <key> | yes |
| 23:46 | <AryehGregor> | Then I regret to inform you that you're not very good at it. |
| 23:47 | <key> | k |
| 23:47 | <key> | takes ears to hear |
| 23:47 | <TabAtkins> | Uh, yeah. /ignore, dude. |
| 23:47 | <AryehGregor> | I'm pretty sure that whoever's listening, cursing at them and telling them they're incompetent is an ineffective rhetorical strategy. |
| 23:47 | <key> | i tried reason, fell on deaf ears |
| 23:48 | <AryehGregor> | Well, that's why I asked you if you were trying to be constructive. |
| 23:48 | <AryehGregor> | The alternative would be that you had given up and were just venting. |
| 23:48 | <key> | slightly |
| 23:48 | <key> | it's frustrating to me. the web has so much promise that has yet to be realized |
| 23:48 | <key> | we're decades into it now, it should be better than this |
| 23:49 | <key> | the tag set should be complete and abstract, and not imply things irrelevant |
| 23:49 | <jcranmer> | if you ask me, the semantic web is mostly going to be a failure |
| 23:49 | <Hixie> | future tense? |
| 23:49 | <TabAtkins> | jcranmer: No need to use the future tense. The "Semantic Web" was a failure. |
| 23:49 | <key> | jcranmer: you're probably right. the temptation to try to create a tag for everything will overwhelm it |
| 23:50 | <key> | should be a complete set of abstract tags, not tags for every kind of thing |
| 23:50 | <jcranmer> | maybe the Semantic Web was something I didn't think it was |
| 23:50 | <TabAtkins> | It punted on all the hard issues like trust in favor of solving the more theoretically interesting ratholes. |
| 23:50 | jcranmer | goes to check Wikipedia |
| 23:50 | <AryehGregor> | I don't think trust was the big issue. |
| 23:50 | <Hixie> | trust is a huge issue |
| 23:50 | <key> | eg, <nav>. i mean wtf, took me 3 minutes of thinking to come up with <menu> being superior |
| 23:50 | <AryehGregor> | I don't think it was the fatal one, though. |
| 23:50 | <Hixie> | it's also known as "spam" |
| 23:51 | <TabAtkins> | You *must* solve trust. If you don't, the entire thing falls down immediately from the weight of spam. |
| 23:51 | <AryehGregor> | I think the big issue was almost no one actually produced useful machine-readable data repositories. |
| 23:51 | <Hixie> | the other huge issue is that it's nigh on impossible to get authors to write good machine-readable content |
| 23:51 | <jcranmer> | the basic problem is that once you define content as being unstructured |
| 23:51 | <Hixie> | the SW has punted on both of these issues in avour of syntax bikesheds. |
| 23:51 | <jcranmer> | you can never go back and decide that it can be structable |
| 23:51 | <jcranmer> | er, structurable |
| 23:51 | <Hixie> | i maintain a hope that NLP will save the day |
| 23:52 | <Hixie> | cos god knows we're out of other options :-P |
| 23:52 | <key> | NLP? |
| 23:52 | <jcranmer> | I don't think you need to do full NLP |
| 23:52 | TabAtkins | has to force himself to not read that as "neurolinguistic programming". |
| 23:52 | <jcranmer> | key: Natural Langage Processing |
| 23:52 | <key> | oh |
| 23:52 | <key> | heh, what do you think orwell's newspeak is for? |
| 23:52 | <key> | reduce the speech-base, you make it easier to implement NLP |
| 23:53 | <jcranmer> | although my attempt to extract HTML text by how the HTML was structured did turn out to be mildly failtastic |
| 23:53 | <jcranmer> | now, granted, having about a weekend to implement it didn't help things |
| 23:55 | <Hixie> | jcranmer: oh i'm not saying you need full AI. With each step along the NLP path, you get results. The better the NLP the more impressive the results can be. |
| 23:56 | <AryehGregor> | NLP is more or less AI-complete, though. |
| 23:56 | <Hixie> | an example of incomplete NLP: translate.google.com |
| 23:56 | <key> | "The article element represents an independent section of a document, page or site. It is suitable for content like news or blog articles, forum posts or individual comments." from http://www.alistapart.com/articles/previewofhtml5 |
| 23:56 | <TabAtkins> | Full NLP, sure. Google gets by pretty decently without AI, though. |
| 23:56 | <key> | see how people are interpreting this tag guys? |
| 23:56 | <Hixie> | key: correctly? |
| 23:57 | <key> | they aren't discussing the issue of implied syndication |
| 23:57 | <Hixie> | that's fine |
| 23:57 | <key> | implied syndication is a perversion of this semantic need |
| 23:58 | <key> | we need a way to denote a part of a web page as the main content area of the page, sans menu, extras, etc |
| 23:58 | <key> | what we don't need, is to have implied syndication along for the ride |
| 23:58 | <key> | i don't even mind the name article, rather the spec definition including said implied syndication |
| 23:59 | <key> | we have rss if people want to syndicate their content, why wedge that kind of stuff into html? |
| 23:59 | <hober> | you keep saying "a way to denote a part of a web page as the main content area of the page" |
