| 06:40 | <a-ja> | TabAtkins: ping (re: colors 4 nit) |
| 06:46 | <a-ja> | TabAtkins: s/constrast/contrast/ in section 10.5 header (and in toc) |
| 09:28 | <Ms2ger> | "Started work on the next version of http://HTML5test.com . First addition is [bits not in the HTML spec]" |
| 10:36 | <MikeSmith> | Ms2ger: you're making the common beginner mistake of misinterpreting that stylized ampersand character as a five |
| 10:58 | <smaug____> | is there somewhere a list of css box types, or how to call them. inline, block, replaced inline etc |
| 11:05 | <smaug____> | or is the whole concept of replaced still not properly defined |
| 11:59 | <IZh> | It seems that on web-developer's version of the document visited links lasts only minutes on my Adnroid device. It's strange... |
| 12:05 | <zcorpan> | jgraham: critic didn't like https://github.com/w3c/web-platform-tests/pull/959 |
| 12:30 | <mathiasbynens> | would it make sense to move `atob`/`btoa` to ECMAScript? http://esdiscuss.org/topic/native-base64-utility-methods → would be good if some WHATWG folks chimed in |
| 12:52 | <zcorpan> | mathiasbynens: Claude Pache's attitude makes me sad and want to not read through the whole thing :-( |
| 12:53 | <zcorpan> | read anyway |
| 12:54 | <mathiasbynens> | zcorpan: tbh i don’t get his point at all. why can “raw binary strings” not be fed to atob? octets only go up to 0xFF |
| 12:54 | <mathiasbynens> | which is exatly what `atob` supports |
| 12:55 | <zcorpan> | whatever happened to base64 string <-> TypedArray ? i thought someone proposed extending atob/btoa to do that |
| 12:56 | <zewt> | was that mixed in with the encoding api stuff? since you also want streaming for base64 |
| 12:56 | <zewt> | i forget where that left off (it's comparable to string encodings, but not quite a direct fit, iirc) |
| 12:57 | <zcorpan> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-August/040364.html |
| 13:00 | <foolip> | away |
| 13:01 | <zewt> | yeah, that morphed into "make it part of TextEncoder/TextDecoder" later in the thread, with the oddity that array->base64 is a "decoder" instead of an "encoder" |
| 13:07 | <zewt> | seem to recall some discussion since then but can't think of where |
| 14:20 | <zcorpan> | Hixie: can you have a look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25542 ? |
| 15:30 | <Domenic_> | High rest time isn't exposed in web workers!? |
| 15:31 | <Domenic_> | Where do I file that bug? (Who manages that spec?) |
| 15:32 | <Ms2ger> | Hixie |
| 15:32 | <zcorpan> | there's high rest time? i want in! |
| 15:32 | <zcorpan> | could use some rest |
| 15:32 | <Ms2ger> | Oh, I was going to send zcorpan chocolate |
| 15:33 | <zcorpan> | oh, nice |
| 15:34 | Ms2ger | should find his way to a post office |
| 15:35 | <darobin> | Domenic_: you probably want to email http://lists.w3.org/Archives/Public/public-web-perf/ |
| 15:36 | <Domenic_> | darobin: sounds good. Given that the spec is already a Rec, will this cause large amounts of work to happen? ("Performance timing v2"?) |
| 15:37 | <darobin> | Domenic_: not necessarily; the last time someone found a bug with a WebPerf Rec they spinned a new Rec out in 6 days |
| 15:38 | <Domenic_> | Woah, didn't know that was possible. |
| 15:38 | <Domenic_> | Cool, thanks. |
| 15:38 | <darobin> | Domenic_: that's why I often say that the Process isn't the problem, you can do a hell of a lot with it; the problem is mostly with the culture |
| 15:40 | <zcorpan> | WebPerf++ for creating a new Rec in 6 days |
| 15:41 | <Ms2ger> | We should publish HTML in WebPerf |
| 15:43 | <Domenic_> | :D |
| 15:43 | <darobin> | Ms2ger: I think that could join the suggestion I made that the HTML WG would use the WHATWG mailing list for technical discussion at that big party with interesting designer drugs :) |
| 15:43 | <Domenic_> | Is the syntax [Exposed=Window,Worker]? |
| 15:43 | <Domenic_> | #lazyirc |
| 15:44 | <Ms2ger> | darobin, by the time the HTMLWG notices and starts flam^Wdiscussing, the Rec will have been shipped |
| 15:44 | <darobin> | Ms2ger: my thoughts exactly *MUAHAHAHAHA* |
| 15:45 | <zcorpan> | Domenic_: yeah, but there's an open spec bug about the comma |
| 15:45 | <Ms2ger> | [Exposed=Window`Worker] |
| 15:47 | <zcorpan> | [Exposed=Window┏(°.°)┛Worker] |
| 15:52 | <Domenic_> | zcorpan++ |
| 16:11 | <zcorpan> | Hixie: intentional that <video><source><script></script><source></video> is not allowed in the content model? |
| 16:15 | <dglazkov> | good morning, Whatwg! |
| 17:25 | <TabAtkins> | zcorpan: There were also requests for string->TypedArray (assuming the default 16-point code units of JS strings). Strings are the most compact way to ship binary data inline in scripts. |
| 17:26 | <TabAtkins> | a-ja: Fixed typo, thanks. |
| 17:49 | <Hixie> | zcorpan: dunno. yet more reasons i hate multi-element designs. |
| 17:50 | <zcorpan> | Hixie: i filed a bunch of bugs about script-supporting elements and content models |
| 17:50 | <Hixie> | great |
| 17:50 | <Hixie> | :-P |
| 17:51 | <zcorpan> | you're welcome :-) |
| 17:51 | <zcorpan> | maybe you should have made template="" an attribute |
| 17:51 | <zcorpan> | and script="" |
| 17:55 | <zewt> | hello, i'm sitting around at work twiddling my thumbs hitting f5 once ina while as google docs 502s for me |
| 17:55 | <zewt> | welcome to cloud |
| 17:57 | <zewt> | TabAtkins: i'm not sure exactly what you're describing, but it sounds horrible |
| 17:57 | <zewt> | incidentally, i think base64 deflates down to basically its original size, which makes it a silly way to send nontrivial amounts of binary data, but not an uncompact one |
| 17:58 | <TabAtkins> | zewt: Interesting. It makes sense that it should compress to roughly its original size, I guess - you're only using 6 bits of each byte, after all. |
| 18:00 | <zewt> | i don't recall how deflate's algorithm works, but if it's bitwise rather than bytewise, it'd probably pick up the encoding pretty precisely, too |
| 18:01 | <TabAtkins> | Pretty sure it's bitwise. |
| 18:01 | <TabAtkins> | But I could be wrong. |
| 18:01 | <zewt> | 1048576 bytes of random data becomes 1076467 bytes, so about 3% overhead |
| 18:03 | <zcorpan> | doesn't google images do that? |
| 18:03 | <zcorpan> | for instant cats |
| 18:07 | <TabAtkins> | Yeah, I think so. |
| 18:12 | <Hixie> | zcorpan: what about https://www.w3.org/Bugs/Public/show_bug.cgi?id=25542 ? |
| 18:13 | <zcorpan> | Hixie: if you remember how the spec comment 4 talks about came into being (if it was there when you edited the spec) |
| 18:13 | <Hixie> | i'd have to look at the blame |
| 18:14 | <Hixie> | i don't recall off the top of my head |
| 18:14 | <zcorpan> | ok |
| 18:30 | <zcorpan> | i guess we shouldn't tell @PointedEars2 about the quirks spec |
| 18:32 | <Ms2ger> | Might go all pointed ears about it |
| 18:50 | <jgraham> | zcorpan: Uh, yeah seems to be broken |
| 18:50 | <jgraham> | I have never understood that particular error :( |
| 18:51 | <zcorpan> | jgraham: context? |
| 18:51 | <zcorpan> | oh the PR |
| 18:51 | <jgraham> | 12:05 < zcorpan> jgraham: critic didn't like https://github.com/w3c/web-platform-tests/pull/959 |
| 18:52 | <jgraham> | Invalid history rewrite: No commit on the rebased branch references |
| 18:52 | <jgraham> | remote: the same tree as the old head of the branch. |
| 18:53 | <jgraham> | Which I guess suggests a move-type rebase is being misinterpreted as a in-place rebase |
| 18:54 | <jgraham> | Which does suggest a way to fix it… |
| 18:56 | <SamB> | does "move type" mean you put the results in a different ref or something? |
| 18:57 | <jgraham> | SamB: By "Move type" I mean you go from A-B-C-B1-B2 -> A-B-C-D-E-B1'-B2' |
| 18:57 | <SamB> | jgraham: oh |
| 18:58 | <SamB> | why does it even try to notice the latter? |
| 18:58 | <jgraham> | The latter? |
| 18:58 | <SamB> | in-place |
| 18:59 | <SamB> | which I assume means more like -> A-B-C-B2'-B1' ? |
| 18:59 | <jgraham> | In-place is typically like A-B-C-B1-B2 -> A-B-C-B12 |
| 18:59 | <SamB> | whatever |
| 18:59 | <jgraham> | It needs to know that the branch history doesn't match what's in git |
| 19:00 | <SamB> | ah |
| 19:01 | <zcorpan> | jgraham: btw is there some unstable test you want me to look at? |
| 19:01 | <jgraham> | Critic has a truly immutable history of the branch because all the previous commits have extra data attached to them like comments |
| 19:02 | <SamB> | so I guess it'd want to notice if you reorder commits too, so that it can reattach the comments? |
| 19:02 | <jgraham> | zcorpan: I had to disable the tests in http://w3c-test.org/workers/semantics/structured-clone/ because they were playing merry hell with the next test |
| 19:03 | <SamB> | what, you can't get a fresh instance of the thing-under-test? |
| 19:03 | <jgraham> | Also, they behave differently on my local computer compared to infrastructure |
| 19:03 | <SamB> | eeinteresting |
| 19:03 | <zcorpan> | jgraham: intredasting |
| 19:03 | <jgraham> | SamB: I could, but there is a tradeoff between isolation and performance |
| 19:03 | <SamB> | jgraham: true |
| 19:04 | <jgraham> | (I could probably add a restart-after feature to the test harness so that tests known to behave badly could still be run, but I haven't, yet) |
| 19:05 | <zcorpan> | jgraham: do you think it would help if it was split up to lots of separate files? |
| 19:07 | <jgraham> | zcorpan: Well then at least I could just disable the subset that actually cause problems |
| 19:07 | <zcorpan> | yep. might also be easier to figure out what the problem actually is |
| 19:08 | <jgraham> | I *suspect* there is a gecko bug here, but I am *so* close to getting a complete set of green testruns that I haven't wanted to investigate everything |
| 19:08 | <zcorpan> | or maybe the problem goes away altogether when splitting, which is both good and bad |
| 19:08 | <jgraham> | Yeah |
| 19:08 | <jgraham> | Well I guess we still have the old version if it does, although people will be less motivated to care |
| 19:09 | <zcorpan> | yeah |
| 19:09 | <zcorpan> | maybe i should dress it up as an acid test instead :-P |
| 19:40 | <Hixie> | my kittens it's depressing seeing the number of changes the htmlwg make to the spec that are just bogus |
| 19:40 | <jtcranmer> | dare I ask? |
| 19:40 | <Hixie> | not just thing i disagree with, i mean, things where the change is not even what the htmlwg intends |
| 19:40 | <Hixie> | jtcranmer: i'm going through bug mail looking at old checkins |
| 19:41 | <SamB> | any choice examples? |
| 19:41 | <Hixie> | https://github.com/w3c/html/commit/d601f6af9914aa0dadd3277c8771ed46995f61de is my favourite so far |
| 19:42 | <Hixie> | replaces "must" with "need", so it's no longer normative |
| 19:42 | <Hixie> | if read literally, it actually gives the wrong effect (e.g. if the contents are "\n\n\n", it suggests that the markup should be "\n\n", whereas it should be "\n\n\n\n") |
| 19:43 | <Hixie> | plus it talks about intent rather than describing the mapping normatively (referring to the actual contents) |
| 19:43 | <Hixie> | etc |
| 19:43 | <Hixie> | it's just a microcosm of error |
| 19:45 | <jtcranmer> | so... htmlwg is run by a bunch of phenomenal idiots |
| 19:45 | <jtcranmer> | good to know that I don't have to worry about it |
| 19:46 | <othermaciej> | I’m not clear on how the previous MUST is a reasonable author conformance requirement |
| 19:46 | <jtcranmer> | unless someone tries to convince me that I need to write an HTML parser to process email |
| 19:46 | <othermaciej> | it tells you conditionally what to do if you want a certain effect |
| 19:46 | jtcranmer | stares at the change |
| 19:46 | <othermaciej> | that is a description of implementation behavior, not of author requirements |
| 19:46 | <Hixie> | othermaciej: that section is essentially telling you how to serialise a DOM |
| 19:48 | <othermaciej> | Oh, I can’t tell what section - I assumed the “by the author” meant its an authoring requirements section |
| 19:48 | <Hixie> | it's the syntax section, describing how you serialise a DOM |
| 19:48 | <Hixie> | as opposed to the parsing section |
| 19:48 | <Hixie> | so it's for "authors" as opposed to "UAs" but it's still normative :-) |
| 19:49 | <jtcranmer> | the original statement was mildly problematic |
| 19:50 | <othermaciej> | mmm, nope, its in 12.1 Writing HTML documents, nothing about serializing a DOM there |
| 19:50 | <jtcranmer> | the new statement is slightly unclear as well |
| 19:50 | <othermaciej> | afaict this is the section conformance checkers should use to check conformance of any document |
| 19:50 | <othermaciej> | Section 12.3 is Serializing HTML Fragments |
| 19:50 | jtcranmer | sighs |
| 19:50 | <Hixie> | othermaciej: 12.1 is a description of how you serialise a dom |
| 19:51 | <jtcranmer> | this is why I like C++'s method of explictly including [Note: ] fragments |
| 19:51 | <zcorpan> | othermaciej: "conformance checkers must use the requirements given in the next section ("parsing HTML documents")." |
| 19:51 | <Hixie> | jtcranmer: we have "note" fragments too. in green, even. |
| 19:52 | <jtcranmer> | so you could say [Note: to make a <pre> that starts with an empty line, two linebreaks would be inserted, as the first one is semantically invisible.] |
| 19:52 | <Hixie> | othermaciej: e.g. "The next few characters of a start tag must be the element's tag name" |
| 19:52 | <Hixie> | othermaciej: an element is something from a DOM |
| 19:52 | <othermaciej> | Hixie: come on, there’s enough genuine errors that you don’t have to make bad faith arguments |
| 19:52 | <Hixie> | ? |
| 19:52 | <Hixie> | this isn't a bad faith argument |
| 19:53 | <Hixie> | just happened to be my favourite of the run i had looked at |
| 19:54 | <othermaciej> | 12.1 is not about serializing a DOM, its authoring conformance requirements for correct syntax; there is literally no mention of serialization |
| 19:54 | <othermaciej> | it is true that a serializer would also be required to output correct syntax |
| 19:54 | <othermaciej> | but there’s no reference to a source DOM anywhere in there |
| 19:54 | <Hixie> | the word "serialialisation" isn't used, sure. but that's what it's describing nonetheless. |
| 19:55 | <Hixie> | the whole section is phrased in terms of how you describe a tree of elements |
| 19:55 | <Hixie> | elements only exist in DOMs |
| 19:56 | <zcorpan> | if you're writing markup from scratch, do you first imagine the DOM and then serialize that? :-) |
| 19:56 | <othermaciej> | its restrictions on valid syntax, not specifically instructions for serializing |
| 19:56 | <mathiasbynens> | annevk: are you aware of any test cases for the Encoding Standard? specifically for the legacy encodings |
| 19:57 | <annevk> | mathiasbynens: http://dump.testsuite.org/encoding/ has tests |
| 19:57 | <annevk> | mathiasbynens: needs a lot more though, darobin might have written some more maybe? |
| 19:58 | <annevk> | (those tests need to be checked for accuracy by the way) |
| 19:59 | <zcorpan> | and port to web-platform-tests? |
| 19:59 | <othermaciej> | you could argue that any time you make a document from scratch you are implicitly serializing an imaginary DOM, but that would not be the way most folks think about it |
| 19:59 | <othermaciej> | speaking of which, I am having trouble figuring out what this means: “A table element must not contain tr elements, even though these elements are technically allowed inside table elements according to the content models described in this specification. (If a tr element is put inside a table in the markup, it will in fact imply a tbody start tag before it.)” |
| 19:59 | <mathiasbynens> | annevk: ta |
| 19:59 | <othermaciej> | on whom is that must requirement? |
| 19:59 | <Ms2ger> | Authors |
| 19:59 | <othermaciej> | but authors are allowed to write <table><tr> |
| 20:00 | <Ms2ger> | Yeah |
| 20:00 | <Ms2ger> | But that doesn't lead to a table containing a tr |
| 20:00 | <Ms2ger> | At least not if "contain" means "child" |
| 20:00 | <othermaciej> | is it an obscure way to say your document is invalid if you use DOM methods to insert a <tr> as a direct child of a <table>? |
| 20:01 | <annevk> | othermaciej: you can also use XML |
| 20:01 | <zcorpan> | no, that section doesn't apply to DOM methods |
| 20:01 | <othermaciej> | that section specifically does not apply to XML |
| 20:01 | <Ms2ger> | Then what is it talking about? |
| 20:01 | <Hixie> | othermaciej: it's saying that a DOM that is serialised according to that section cannot have a <tr> in a <table> |
| 20:02 | <Hixie> | othermaciej: it's an additional restriction on the content model |
| 20:02 | <Hixie> | othermaciej: specifically for DOMs that are serialised per this section |
| 20:02 | <zcorpan> | you're not allowed to imagine <tr> as a child of <table> when writing your text/html |
| 20:02 | <Hixie> | yeah, the DOM you're serialising is usually just an imagined one, that's a good way to view this |
| 20:02 | <zcorpan> | you have to imagine <tr> as child of <tbody> as child of <table>, and then it's ok to write it as <table><tr> :-) |
| 20:02 | <othermaciej> | So any serializer is required to output <table><tbody><tr> instead of Mtable><tr>? |
| 20:03 | <Hixie> | no, it means if you pass a DOM to this section, it cannot have a TR as a child of a TABLE |
| 20:03 | <Hixie> | what zcorpan said |
| 20:03 | <Hixie> | you have to imagine <tr> as child of <tbody> as child of <table>, and then it's ok to write it as <table><tr> |
| 20:03 | <othermaciej> | having a conformance requirement on the input to an algorithm makes no sense (assuming arguendo that this even describes an algorithm) |
| 20:04 | <othermaciej> | how would you even check if someone’s imaginary DOM is valid? |
| 20:04 | <Hixie> | content models are nothing but conformance requirements on the inputs to algorithms |
| 20:04 | <Hixie> | well it might not be imaginary |
| 20:04 | <othermaciej> | content models are requirements for correct syntax of a textual representation of HTML |
| 20:05 | <zcorpan> | othermaciej: it's planned for the next iteration of Google Glasses |
| 20:05 | <othermaciej> | a content model requirement that can’t be checked in the serialized output has no effect |
| 20:07 | <SamB> | so basically, you run the parser FIRST then worry about the content model ... |
| 20:07 | <SamB> | othermaciej: you run their imaginary DOM through a validator, obviously |
| 20:09 | <othermaciej> | if it fails your imagination validator, are you allowed to correct the imaginary error? (and then write exactly what you would have if you hadn’t fixeed the error?) |
| 20:09 | <zcorpan> | of course |
| 20:10 | <othermaciej> | I guess it’s saying that you are allowed to write <table><tr>, but you MUST imagine there is a <tbody> there |
| 20:11 | <zcorpan> | othermaciej: <html><head><body> and <colgroup> are similar actually |
| 20:12 | <zcorpan> | but they happen to have the same content model in xhtml and text/html |
| 20:12 | <othermaciej> | so in XHTML, you are allowed to write <table><tr> without imagining the <tbody>? |
| 20:13 | <zcorpan> | yes |
| 20:13 | <SamB> | wait you mean text/html has its own content models, not just quirky parsing rules? |
| 20:13 | <zcorpan> | SamB: yeah there are a few differences between text/html and xhtml content models |
| 20:13 | <zcorpan> | <table><tr> is one |
| 20:13 | <Ms2ger> | And noscript |
| 20:13 | <zcorpan> | <iframe>'s content is another |
| 20:14 | <SamB> | oh, right, noscript |
| 20:14 | <SamB> | forgot about that |
| 20:15 | <SamB> | it's really the wrong approach nowadays because whether scripts run is not that simple anymore |
| 20:15 | <SamB> | aside from the parsing nightmare, I mean |
| 20:16 | <zcorpan> | SamB: do you mean noscript should be disallowed in text/html also? |
| 20:16 | <SamB> | it's not marked obsolescant? |
| 20:17 | <zcorpan> | not quite sure what that word means but it's not marked as such |
| 20:19 | <SamB> | I think I should have just said "obsolete" |
| 20:19 | <SamB> | and I'm not actually sure what difference (if any) there is between those words other than spelling/pronunciation |
| 20:20 | <mathiasbynens> | annevk: can haz `single-octet-raw.phps`? |
| 20:21 | <annevk> | mathiasbynens: I think that's a loop from 0 to 255 and just does chr(n) |
| 20:21 | <annevk> | mathiasbynens: maybe it starts at 127 |
| 20:21 | <annevk> | 128* |
| 20:22 | <mathiasbynens> | and then `content-type:text/html;charset=label`, i suppose |
| 20:23 | <annevk> | maybe text/plain, but yeah |
| 20:23 | <mathiasbynens> | oh, right |
| 20:24 | <zcorpan> | mathiasbynens: what do you want the tests for, out of curiosity? |
| 20:24 | <Hixie> | tantek: (c/o annevk) see w3c bugs 24840-24843 |
| 20:26 | <annevk> | How does https://github.com/w3c/html/commit/9d699201cb034e495c46e6120811599b93cba7da even make sense? Anyway, I got other things to do |
| 20:26 | <mathiasbynens> | zcorpan: writing encoders/decoders for the legacy single-byte encodings in the Encoding standard, to use as part of another hobby project |
| 20:28 | <zcorpan> | mathiasbynens: would it be troublesome to convert them to w-p-t format? :-) |
| 20:29 | <mathiasbynens> | zcorpan: i might just do that |
| 20:30 | <zcorpan> | splendid |
| 20:30 | <zcorpan> | but don't get too excited or Ms2ger will be sending chocolate your way |
| 20:30 | <mathiasbynens> | that sounds terrible |
| 20:31 | <Ms2ger> | Probably cheaper than to zcorpan, too |
| 20:31 | <zcorpan> | yes. also darobin will be concerned about your health eating all that chocolate |
| 20:31 | <mathiasbynens> | annevk: if you’re ever pushing to the encoding standard server again, consider either enabling CORS for http://dump.testsuite.org/encoding/single-octet-raw.php or just adding http://dump.testsuite.org/encoding/single-octet-raw.phps |
| 20:31 | <zcorpan> | and your significant other will post pictures on facebook about said chocolate |
| 20:31 | <Ms2ger> | Now I'm sad I missed that |
| 20:32 | <Ms2ger> | I can send chocolate for said significant other too, of course |
| 20:34 | <annevk> | mathiasbynens: dump.testsuite.org is not that server, but yeah, maybe if you ping me in a couple of weeks during the day or so |
| 20:34 | <mathiasbynens> | will do, thanks :) |
| 20:41 | <zcorpan> | Hixie: btw i think it's time soon to take over <img> |
| 20:41 | <Hixie> | k |
| 20:42 | <Hixie> | i haven't gotten to the loading refactoring yet unfortunately |
| 20:43 | <zcorpan> | ok. i guess i can fix that |
| 20:47 | <Hixie> | zcorpan: that would certainly be fine by me. Happy to help with it, too. I didn't mean to dump it in your lap. |
| 20:47 | <zcorpan> | Hixie: ok cool |
| 20:48 | <zcorpan> | Hixie: how do you envision the split to work? you take in source text that is inserted in `source` before running anolis? |
| 20:48 | <Hixie> | yeah |
| 20:48 | <Hixie> | there's some <!-- --> markers in the <img> section already |
| 20:49 | <Hixie> | so my plan is to just replace those with a thing that imports a file from you |
| 20:49 | <Hixie> | which i would grab via HTTP from somewhere, probbaly |
| 20:49 | <Hixie> | that part is up to you |
| 20:49 | <estellevw> | Is the capture attribute going to be a separate attribute, or part of the value of the accept attribute. I see it in the discussions but not the HTML5 spec. |
| 20:49 | <zcorpan> | Hixie: how can i generate the spec to see that the xrefs and stuff work? |
| 20:49 | <estellevw> | I did find it here: http://www.w3.org/TR/html-media-capture/#the-capture-attribute |
| 20:50 | <zcorpan> | is it enough to run vanilla anolis? |
| 20:50 | <Hixie> | zcorpan: and as far as <source> goes, if you really are gonna use <source>, we'll try to make it work, and if it ends up being too many changes, we can do the same for that |
| 20:50 | <Hixie> | zcorpan: hmm |
| 20:50 | <Hixie> | zcorpan: probably need to stick a generic header on the top |
| 20:50 | <Hixie> | zcorpan: but yeah, that should work |
| 20:50 | <estellevw> | as a separate attribute, but am wondering where it's going to land, if at all |
| 20:50 | <Hixie> | zcorpan: however i'm planning on moving away from anolis in the medium term. |
| 20:50 | <zcorpan> | Hixie: to what? |
| 20:50 | <Hixie> | zcorpan: something of my own creation |
| 20:51 | <zcorpan> | that's why you're writing an html parser? |
| 20:51 | <Hixie> | yeah |
| 20:51 | <Hixie> | anolis is just too slow for my needs at this point |
| 20:51 | <zcorpan> | ok |
| 20:51 | <Hixie> | it's becoming painful |
| 20:51 | <Hixie> | anyway i'm sure i'll be able to provide you a tool you can use |
| 20:51 | <Hixie> | either a cgi script or a native app or something |
| 21:07 | <zcorpan> | Hixie: i think i'll put the file in https://github.com/ResponsiveImagesCG/picture-element (which means a few other people will have ability to change it) |
| 21:09 | <Hixie> | so long as you have ultimate responsibility, how you do it is up to you :-) |
| 21:11 | <zcorpan> | Hixie: what is the <!-- --> marker? |
| 21:11 | <Hixie> | <!-- START OF PICTURE SECTION --> and <!-- END OF PICTURE SECTION --> |
| 21:13 | <zcorpan> | ok, i'll take a look at this tomorrow. thx |
| 21:13 | <Hixie> | thank _you!_ |
| 21:14 | <zcorpan> | welcome :-) |
| 22:11 | <TabAtkins> | zcorpan: I'm happy to put the quirk into Selectors. |
| 22:11 | <zcorpan> | TabAtkins: great! |
| 22:12 | <TabAtkins> | Though, hm. Is this *all* Selectors-based matching (including querySelector() et al) or just stylesheets? |
| 22:12 | <zcorpan> | all |
| 22:13 | <TabAtkins> | kk |
| 22:13 | <TabAtkins> | Just making sure it belonged in Selectors and not, I guess, Syntax. |
| 22:14 | <TabAtkins> | Isn't tagname CI too? |
| 22:14 | <zcorpan> | no, tagname is lowercased |
| 22:14 | <zcorpan> | for html elements |
| 22:14 | <zcorpan> | in html documents |
| 22:15 | <zcorpan> | that's specced in html |
| 22:15 | <TabAtkins> | Hm, I was pretty sure that "P { color: green; }" matched. |
| 22:15 | <TabAtkins> | Yes. |
| 22:15 | <zcorpan> | yes, the selector is lowercased |
| 22:15 | <zcorpan> | and the tag in html parsing is lowercased |
| 22:16 | <TabAtkins> | ...where is that tagname lowercasing specified? |
| 22:16 | <zcorpan> | but it won't match document.createElementNS(html_ns, 'P') |
| 22:16 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#case-sensitivity |
| 22:16 | <TabAtkins> | Ah, that is an HTML-specific quirk. Gotcha. |
| 22:17 | <TabAtkins> | I should probably add a note reffing that section, though. |
| 22:17 | <zcorpan> | yeah, everything else is case sensitive |
| 22:17 | <zcorpan> | you could make Selectors say that stuff is case-sensitive unless the host language specifies something else |
| 22:19 | <TabAtkins> | Well, everything's CS by default unless specified otherwise. |
| 22:20 | <zcorpan> | TabAtkins: http://dev.w3.org/csswg/selectors4/#case-sensitive says the host language has to define whether it's CS |
| 22:21 | <TabAtkins> | Bah, I forget all the things that Selectors defines. I'll tweak that. |
| 22:22 | <zcorpan> | ok good :-) |
| 22:22 | zcorpan | -> sleep |
| 22:25 | <zewt> | Your download will start in 5 seconds... <- dear internet, stop that |
| 22:58 | <zewt> | having to deal with libraries so old they require setjmp makes me unhappy |
| 23:07 | <SamB> | zewt: you think they should have switched to C++ just for exceptions? |
| 23:07 | <SamB> | (not that I would argue otherwise or anything!) |
| 23:21 | <zewt> | better off just having error returns everywhere than using that |
| 23:21 | <zewt> | setjmp is massively evil |
| 23:23 | <SamB> | zewt: I guess I better not mention gdb |
| 23:24 | <zewt> | not sure what that has to do with setjmp, heh |
| 23:55 | <Hixie> | MikeSmith, hsivonen: which instance of the validator is the most up to date? |