| 03:45 | <MikeSmith> | all right http://googlewebmastercentral.blogspot.jp/2012/12/introducing-data-highlighter-for-event.html seems pretty cool |
| 03:46 | <MikeSmith> | http://support.google.com/webmasters/bin/answer.py?hl=en&answer=2692911 |
| 03:46 | <MikeSmith> | Google Data Highlighter |
| 03:47 | <MikeSmith> | tantek: thoughts? |
| 03:48 | <tantek> | MikeSmith - whoa - sounds pretty cool |
| 03:48 | <tantek> | direct manipulation of visible content like that is potentially easier / more accessible than having to mark it up. |
| 03:49 | <MikeSmith> | yup |
| 03:49 | <tantek> | my guess is that it would be quite fragile to markup changes though |
| 03:49 | <MikeSmith> | yeah I would guess so too |
| 03:49 | <tantek> | so as soon as the site gets a redesign, or a developer updates a template, all the smart learning rules would likely break |
| 03:50 | <tantek> | one of the experiences we've had with microformats is that for long term data quality you really do need to engage with the design/development side of web sites |
| 03:50 | <tantek> | and as such, any kind of "data" markup like that needs to be super-easy to a) recognize that it exists at all, b) maintain / update. |
| 03:51 | <tantek> | some of that learned experience went into the design of microformats2 |
| 03:51 | <MikeSmith> | yeah this could kind of make it more of a designer task rather than a author/developer task |
| 03:51 | <tantek> | sort of |
| 03:51 | <tantek> | web designers already know microformats |
| 03:52 | <tantek> | the data highlighter is aimed at non-technical folks |
| 03:52 | <tantek> | designers tend to be technical today |
| 03:52 | <tantek> | data highlighter appears to be aimed at product manager types, or maybe SEO consultants |
| 03:53 | <tantek> | oh, and there is one *big massive problem* with data highlighter - it only helps your content look "richer" in *Google* search results, because *Google* holds onto the smarts about what parts of your web page mean what. |
| 03:53 | <scor> | problem is: this is only for Google, you explain to Google how your site is built… will other search engines come up with their own custom DH as well? |
| 03:53 | <tantek> | whereas semantic in HTML, microformats, microdata, RDFa are accessible to *all* search engines and tools |
| 03:53 | <scor> | granted, most SEO people care mostly about Google, |
| 03:53 | <tantek> | scor - precisely, it doesn't scale either |
| 03:53 | <Hixie> | would be cool if it handed you back a bash script you could run on your site that would apply edits to the pages to mark them up with microdata (or whatever) |
| 03:53 | <scor> | but in doing so, they're isolating the other search engines |
| 03:54 | <tantek> | Hixie - good luck |
| 03:54 | <tantek> | might as well ask for a a bash script you could run on your site that would apply edits to the pages to mark them up with HTML :) |
| 03:54 | <tantek> | scor - exactly |
| 03:54 | <scor> | sounds counter to the whole schema.org initiative which was meant to bring all search engines together :( |
| 03:54 | <Hixie> | i don't see why it'd be hard, i mean, they essentially do this |
| 03:54 | <MikeSmith> | I guess Google has no business incentive to help you make that data portable |
| 03:54 | <tantek> | scor - indeed |
| 03:54 | <scor> | MikeSmith: true |
| 03:54 | <tantek> | Hixie - no, Altavista essentially did that |
| 03:54 | <scor> | though they initiated schema.org :) |
| 03:54 | <tantek> | Google paid much more attention to all the explicit markup in the page, especially links |
| 03:55 | <tantek> | and thus crushed Altavista |
| 03:55 | <scor> | but I guess these two projects came from different people at Google |
| 03:55 | <tantek> | scor - different groups |
| 03:55 | <tantek> | exactly |
| 03:55 | <tantek> | there is a *very* strong automatic text-entity recognition/analysis group inside Google who don't believe in any explicit markup. mostly PhDs. |
| 03:55 | <Hixie> | tantek: ? |
| 03:55 | <tantek> | it's a cultural thing |
| 03:56 | <tantek> | anyway, I see the data highlighter as a useful UI experiment |
| 03:56 | <tantek> | Google-specific and all that |
| 03:57 | <tantek> | but think of it like a Labs thing (or what Labs tried to be - is it still around?) |
| 03:57 | <tantek> | but you're right scor, I'd expect data highlighter to piss off the other members of the schema-org oligopoly |
| 03:58 | <tantek> | will be interesting to see if there's any political fall out |
| 03:58 | <scor> | yes |
| 03:59 | <tantek> | MikeSmith - the general rule about distance between data and metadata applies too |
| 03:59 | <tantek> | and storing your metadata (in some proprietary Google-access-only database) that far from your data (in your web page) is likely to result in unreliability quite quickly |
| 04:00 | <tantek> | at best it's a slicker UI on top of the GoogleBase concept (which was similarly a proprietary Google-access-only database) |
| 04:01 | <tantek> | BTW, MikeSmith, Hixie, do you know where Google's documentation about Rich Snippets from semantic HTML tables is? |
| 04:01 | <tantek> | I've been looking for it and can't find it |
| 04:01 | <tantek> | despite the fact that I *know* that Google is using semantic HTML tables to display rich snippets |
| 04:02 | <MikeSmith> | tantek: no clue from me on that one |
| 04:21 | <tantek> | MikeSmith - here's the example Google RichSnippet from *just* a semantic table: http://www.flickr.com/photos/aaronpk/8000688018/in/photostream |
| 04:22 | <tantek> | (that first result) |
| 04:27 | <MikeSmith> | .window 25 |
| 04:27 | <MikeSmith> | oopws |
| 04:28 | <MikeSmith> | tantek: the "semantic HTML table" part is the table-like bit there? |
| 04:28 | <MikeSmith> | what's semantic about it? |
| 04:28 | <tantek> | the markup in the page |
| 04:29 | <tantek> | bbiab |
| 04:37 | <tantek> | Google is picking out the following information purely from the semantic HTML markup in that example: |
| 04:37 | <tantek> | 500+ items - from the number of <tr>s |
| 04:37 | <tantek> | grey text table headers - from the <th>s *with text content* (google skipped the column with images) |
| 04:38 | <tantek> | first two rows from the table with data |
| 04:41 | <tantek> | now obviously not all pages with tables with ths and tds look like that in Google results - so the question is, what did I do in that *very* simple page to get the nice looking Rich Snippet in Google results? |
| 04:51 | <MikeSmith> | tantek: maybe that's one of those things they are not going to tell you |
| 04:52 | <MikeSmith> | intentionally |
| 04:53 | <MikeSmith> | you gotta reverse-engineer it |
| 04:53 | <tantek> | sure, I found it *accidentally* |
| 04:53 | <tantek> | I just did simple clean minimal markup |
| 04:53 | <tantek> | and then magically got that result within 24 hours |
| 04:54 | <tantek> | I *think* I've seen similar things with lists? (<ol> <ul>) |
| 04:54 | <tantek> | maybe they have some secret sauce where if the vast majority of a page's content is a single semantic <table> then they treat it specially like that |
| 04:54 | <tantek> | that would be my guess |
| 04:56 | <MikeSmith> | yeah the more I think about that the more it makes me think they are never going to document that kind of stuff |
| 04:56 | <tantek> | but they document simpler things like rel |
| 04:56 | <MikeSmith> | because for one thing they need to be free to change it |
| 04:56 | <tantek> | rel=author, rel=me support for example |
| 04:56 | <MikeSmith> | yeah |
| 04:56 | <tantek> | sure, they're free to change any of this stuff |
| 04:57 | <tantek> | they have disclaimers of that sort all over the rich snippets docs |
| 04:57 | <MikeSmith> | ok |
| 04:57 | <tantek> | so why not document proper HTML table and list markup as a technique? what's the downside? |
| 04:57 | <tantek> | too many SEOs start using proper semantic table / list markup? ;) |
| 04:59 | <MikeSmith> | dunno but maybe be cause the conventions have not emerged |
| 04:59 | <MikeSmith> | they are sort of causing the conventions to be created |
| 05:00 | <tantek> | nah, the convention is just use <table> <tr> <th> <td> as simple as you possibly can |
| 05:00 | <MikeSmith> | as they have done for most other SEO jacking |
| 05:00 | <tantek> | *simply* |
| 05:00 | <MikeSmith> | ok |
| 05:00 | <tantek> | that's all I did! |
| 05:00 | <MikeSmith> | well that's nice then |
| 05:00 | <tantek> | and it "worked" |
| 05:00 | <tantek> | right |
| 05:00 | <MikeSmith> | that's how it should be |
| 05:01 | <tantek> | I'm tempted to document it myself just to try to force the issue |
| 05:01 | <tantek> | as an "SEO" technique |
| 05:01 | <MikeSmith> | tantek: hey they don't do the same thing for <dl> lists? |
| 05:01 | <tantek> | they might - I haven't seen an example of them doing anything like that for <dl> lists |
| 05:02 | <MikeSmith> | yeah "SEO" is the stinkbait |
| 05:02 | <tantek> | sorry, "search engine marketing" ;) |
| 05:03 | <MikeSmith> | tantek: so that suggests the technique of making content more AT-friendly by using <dl> lists instead of tables is not good if you want the search-engine juice |
| 05:05 | <tantek> | well who knows what *other* juice you'd be giving up |
| 05:05 | <tantek> | <dl>s aren't right for multiple (>2) columns anyway) |
| 05:05 | <tantek> | however, Google does have some odd "definition" logic |
| 05:06 | <tantek> | e.g. https://www.google.com/search?q=floorcraft+definition |
| 05:06 | <tantek> | click the tiny "More Info" under the big white definition box |
| 05:06 | <tantek> | note the two results |
| 05:07 | <tantek> | common pattern: |
| 05:07 | <tantek> | <p><b>floorcraft</b> - … </p> |
| 05:07 | <tantek> | rather than <dl><dt> …. </dt><dd>…</dd> </dl> |
| 05:07 | <tantek> | g2g |
| 05:07 | <tantek> | talk more laters! |
| 05:11 | <MikeSmith> | cheers |
| 07:02 | <MikeSmith> | Cray Computer joined the W3C |
| 07:05 | <othermaciej> | neat, though kind of retro |
| 07:05 | <othermaciej> | is Atari joining next? |
| 07:10 | <MikeSmith> | heh |
| 07:11 | <MikeSmith> | somebody should restart an Atari brand |
| 07:11 | <MikeSmith> | Cray now does "Big Data relationship analytics" |
| 07:11 | <MikeSmith> | whatever that is |
| 07:11 | <MikeSmith> | sounds pretty fishy to me |
| 07:13 | <MikeSmith> | anyway Cray is apparently still the big boy on the block |
| 07:14 | <MikeSmith> | https://twitter.com/billschrier/status/268221191163105281 |
| 07:14 | <MikeSmith> | "Seattle's @Cray_Inc now has the world's fastest supercomputer at 17.59 petaflops, beating Chinese and others @PSBJ - http://ow.ly/feTc4"; |
| 07:28 | <MikeSmith> | http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 |
| 07:38 | <othermaciej> | "Big Data relationship analytics" -- that shit cray |
| 07:41 | <MikeSmith> | hah |
| 07:42 | <MikeSmith> | good un |
| 07:53 | <zcorpan> | i find myself mostly agreeing with http://24ways.org/2012/responsive-images-what-we-thought-we-needed/ |
| 10:04 | <annevk_> | At some point we need to properly discuss and address the whether or not attributes are ordered question. Anyone suggestions for how to go about that? |
| 10:06 | <Ms2ger> | They're ordered. |
| 10:06 | <Ms2ger> | :) |
| 10:06 | <annevk> | Agreed, what's the order? |
| 10:06 | <annevk> | Document-order and then set order? |
| 10:07 | <jgraham> | That sounds likely |
| 10:07 | <annevk> | hsivonen: ^^ |
| 10:08 | <hasather> | annevk: Yes. That would be nice from an editing point of view too (devtools) |
| 10:08 | <annevk> | hasather: "perfect" editors are more complicated though, they'd also preserve inter-attribute whitespace and such |
| 10:09 | <hasather> | annevk: I was referring to the attribute not jumping somewhere else when you add it, which could be confusing |
| 10:11 | <annevk> | ah yeah |
| 10:13 | <odinho> | So all is well and shiny. Everyone happy. |
| 10:13 | <Ms2ger> | odinho, hey, did you guys fix my bug from yesterday already? :) |
| 10:15 | <odinho> | Ms2ger: Noone has jumped on it as a "OH MY WE'RE TOTALLY BREAKING THE WEB LETS FIX ASAP" yet, no :] |
| 10:18 | <odinho> | Ms2ger: I'd do it myself if I didn't really have too much to do already. Not to say anything I could possibly be doing could be more important than lowercasing too many weird characters in createElement, but well - I shouldn't continue starting on new things. ^_^ |
| 10:20 | <annevk> | That is actually worth fixing to crush the idiotic notion that simple identifiers should use anything other than case-sensitive or ASCII case-insensitive |
| 10:22 | <odinho> | It's def. worth fixing at one point, and probably quite easy. But I won't do it right now. |
| 10:23 | <odinho> | Watching it though, so I'll know if someone else does. |
| 10:26 | <hsivonen> | annevk: why do we need to overspec attribute order |
| 10:26 | <hsivonen> | ? |
| 10:26 | <hsivonen> | annevk: IE has done fine with a seemingly random attribute order |
| 10:26 | <annevk> | hsivonen: because DOM methods depend on the order |
| 10:27 | <hsivonen> | annevk: for example? |
| 10:27 | <annevk> | hsivonen: getAttribute() |
| 10:27 | <hsivonen> | annevk: xmlns crap? |
| 10:27 | <annevk> | hsivonen: yes |
| 10:27 | <hsivonen> | sigh |
| 10:27 | <hsivonen> | is it a Real Problem? |
| 10:28 | <Ms2ger> | odinho, if you've got someone else with copious free time I can pester... ;) |
| 10:28 | <annevk> | per the JavaScript guys, Maps are either ordered or random |
| 10:29 | <annevk> | they made theirs ordered, we could make the attribute map random I suppose |
| 10:29 | <annevk> | but I'm not sure that's better |
| 10:30 | <hsivonen> | I’m not convinced that constraining implementations by requiring a certain order is a good idea. |
| 10:30 | <hsivonen> | but attribute storage isn’t really my area |
| 10:30 | <hsivonen> | more like bz’s thing |
| 10:31 | <annevk> | well "order" is exposed via innerHTML, ele.attributes, getAttribute() |
| 10:31 | <hsivonen> | annevk: do WebKit and Presto always maintain order? Trident and Gecko don’t. |
| 10:31 | <hsivonen> | though Gecko might seem to most of the time. |
| 10:32 | <hsivonen> | annevk: does the getAttribute() thing ever get exposed for HTML parser-generated nodes? |
| 10:32 | <hsivonen> | lang vs. xml:lang on SVG nodes? |
| 10:32 | <annevk> | I'm not sure, but it only being random some of the time seems annoying |
| 10:33 | <annevk> | hsivonen: yeah, that'd be an example |
| 10:33 | <annevk> | hsivonen: actually no, that'd would work okay |
| 10:33 | <hsivonen> | well, Gecko’s unordering cases have to do with attributes that are CSS presentational hints, IIRC |
| 10:33 | <annevk> | hsivonen: getAttribute() takes a qualified name |
| 10:33 | <annevk> | hsivonen: so you'd hit problems with two namespaced attributes |
| 10:34 | <hsivonen> | annevk: I’m going to call this theoretical inelegance for the time being and not a Real Problem |
| 10:35 | <annevk> | feel free to reopen the bug; I'd appreciate some kind of suggestion of what the spec should say instead then |
| 10:37 | <zcorpan> | it seems more likely that sites rely on what innerHTML returns when there are presentational attributes than what getAttributes returns when there are namespaced attributes with the same name |
| 10:37 | <zcorpan> | or attributes[index] |
| 10:39 | <hsivonen> | annevk: I CCed bz on the bug |
| 10:39 | <annevk> | thanks |
| 10:39 | <zcorpan> | nevertheless, we usually require something instead of leaving it undefined even if there's no known example of sites breaking because of the lack of being defined, so that we don't have to spec whatever content ends up relying on in a few years |
| 10:41 | <hsivonen> | I wonder if IE’s hash function is a well-known one that could be identified by throwing enough data at it as a black box |
| 10:44 | <zcorpan> | exactly. :-) i'd rather IE implemented ordered attributes than having to reverse engineer their order when finding a site that relies on IE's order |
| 11:14 | <SimonSapin> | Twitter doesn’t like @ in URLs :/ |
| 11:15 | <zcorpan> | how do people sign up to contribute to http://wiki.ecmascript.org/doku.php?id=strawman:error_stack ? |
| 11:18 | <jgraham> | You might need to be in TC39? |
| 11:18 | <annevk> | so you have objects and such and expose the stack trace as a formatted string? |
| 11:19 | <annevk> | is there a reason for that? |
| 11:19 | <zcorpan> | maybe https://github.com/jsfixed/jsfixed is a better venue for feedback without joining |
| 11:20 | <jgraham> | "Having the stack be a string that has to be manually parsed is really silly. However, Safari tried to return an array of stuff and it turned out that it broke things. We could provide an alternative API to extract relevant details but at this point we should strive to make implementations compatible." |
| 11:20 | <jgraham> | Which is pretty enlightened behaviour for TC39 |
| 11:21 | <zcorpan> | having just the same string in all browsers seems like a huge improvement over the current situation |
| 11:22 | <annevk> | ta jgraham |
| 11:25 | <Stevef> | darobin: ping me if there are any publication issues with https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html |
| 11:33 | <hsivonen> | annevk, jgraham: OK if I upload <main> tests to the html5lib test suite if I put them in a separate file? |
| 11:35 | <annevk> | sure |
| 11:35 | <jgraham> | Yup |
| 11:37 | <hsivonen> | thanks |
| 11:39 | <darobin> | Stevef: cheers, will do |
| 12:09 | <zcorpan> | darobin: why waste time with votes about naming instead of just one person picking arbitrary names and stick to that? |
| 12:10 | <darobin> | zcorpan: I'd be delighted with that model, but you back to the issue of picking the person |
| 12:10 | <zcorpan> | darobin: i pick you :-) |
| 12:11 | <darobin> | zcorpan: haha, thanks — the names for the branches are therefore set to be "unicorn" and "dahut" |
| 12:11 | <darobin> | that was easy |
| 12:11 | <zcorpan> | excellent. glad we could settle this |
| 12:12 | <darobin> | when there's an editor the logical choice is to just leave it up to the editor; failing that it could be the chair, but in this case he's one of the proponents of an option that's not making people happy... |
| 12:13 | <darobin> | I guess we could just nominate a test suite editor |
| 12:13 | <jgraham> | I think having a vote is silly, but I also think that having non-default names for the master branch is silly |
| 12:13 | <darobin> | zcorpan! I hear you have plenty of time going spare. |
| 12:13 | <darobin> | jgraham: I think the whole thing is silly; hence my proposal to use whatever silly means to get the fuck over it |
| 12:14 | <zcorpan> | darobin: you misunderstand. i wanted to *not* spend time on this |
| 12:15 | <jgraham> | I don't think anyone disagrees that it's silly, just on exactly what is silly |
| 12:15 | <darobin> | I wish I had a device to send <blink style='font-size: 100vh; color: red'>JFDI</blink> to arbitrary people's screens |
| 12:15 | <jgraham> | So far the only proponent of the non-master-master is kris |
| 12:15 | <jgraham> | and he is also against git and github |
| 12:15 | <jgraham> | So we apparently aren't letting him block us in general |
| 12:16 | <darobin> | indeed |
| 12:16 | <jgraham> | I haven't even heard a single reason for favouring non-default names |
| 12:16 | <zcorpan> | should we register his objection and show it to the Director when we transition to CR (never?)? |
| 12:17 | <darobin> | lol |
| 12:17 | <darobin> | I reckon that we can just wait until next Tuesday and simply all argue in the same direction there |
| 12:18 | <darobin> | then call it a day and move on |
| 12:28 | <hsivonen> | btw, what’s the current status of ffmpeg vs. libav? |
| 19:23 | <rillian> | hsivonen: I don't think ffmpeg vs libav has changed much since earlier this year |
| 19:23 | <rillian> | they're still parallel forks |
| 20:18 | <TabAtkins> | zcorpan: If you want to give feedback on es stuff, just join es-discuss⊙mo |
| 20:18 | <TabAtkins> | That's the official mailing list, and you don't have to be a tc39 member to contribute there. |