| 00:48 | <stvs> | Why is the topic inviting us to leave our logic :/ ? |
| 00:58 | <waldir> | Hi, I think i found a typo on a W3C page. Is there anyone who can quickly check that (and hopefully fix it if it's really a typo)? |
| 01:01 | <Lachy_> | waldir, unless you're talking about the HTML5 spec, or other related spec, this channel doesn't work on the W3C website |
| 01:01 | <waldir> | I thought so, but someone pointed me here on the #html5 channel when I asked about how to contact w3c people |
| 01:01 | <waldir> | Lachy: can you point me in the right direction? |
| 01:03 | <webben> | waldir: Doesn't the page have contact details? |
| 01:03 | <Lachy> | not sure, possibly #sysreq on irc.w3.org |
| 01:04 | <Lachy> | depends, what page is it? |
| 01:04 | <waldir> | Lachy: thanks. I was on #w3c on that server but it was empty |
| 01:05 | <waldir> | Lachy: http://www.w3.org/TR/css3-multicol/ |
| 01:10 | <waldir> | webben: I can't find any specifically on that page |
| 01:12 | <webben> | waldir: ah in that case "return comments to the (archived) public mailing list www-style⊙wo" |
| 01:14 | <waldir> | aren't those implementation-related comments they're referring to? |
| 01:15 | <webben> | waldir: Yes, but www-style is the appropriate general mailing list. |
| 01:16 | <waldir> | webben: ok, I'll do that. But do i need to be subscribed to it? |
| 01:16 | <waldir> | seems so: "To post messages, you have to be subscribed." |
| 01:16 | <waldir> | argh |
| 01:17 | <webben> | waldir: it's an open subscription model |
| 01:17 | <webben> | you can always join and leave ;) |
| 01:17 | <waldir> | ah, wait: "Messages from non-subscribers are diverted to a human moderator and may appear with a delay." |
| 01:17 | <waldir> | I think I'll do that and bookmark the archives page :P |
| 01:17 | <webben> | yeah, I think that's more cumbersome than joining and leaving but suit yourself :) |
| 01:17 | <waldir> | I got already way too much email to deal with |
| 01:18 | webben | knows the feeling. |
| 01:18 | <waldir> | :) |
| 01:18 | <waldir> | btw, I'm reading that page, haven't even left the first half and I've already found half a dozen typos! Is that a normal thing? |
| 01:19 | <waldir> | I thought a candidate rec. would have been reviewed many times over by now :/ |
| 01:20 | <webben> | waldir: mmm ... I think the amount of CSS spec editing to be done significantly exceeds the available time of spec editors. |
| 01:21 | <bga_> | grammar nazi :) |
| 01:24 | <waldir> | bga_: guilty as charged :P fortunately I have wikipedia to escape my urges :D |
| 01:24 | <stvs> | I really want to discuss the language int he HTML5 spec under "Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout." |
| 01:24 | <stvs> | Under tables, I mean. |
| 01:25 | <stvs> | Such strong language is best left for the blogs of the various CSS "gurus" which aren't familiar the HTML4 spec itself suggested at one point using tables for layout (of forms, for example). |
| 01:26 | <stvs> | While ideally we shouldn't rely, and normally we don't have to, unless with complex layouts, "must not" is inappropriate language considering there is no CSS alternative beside the still incomplete CSS3 grids module. |
| 01:27 | <stvs> | This remark is also inaccurate for any screen reader of at least a decade back: "In particular, users of accessibility tools like screen readers are likely to find it very difficult to navigate pages with tables used for layout." |
| 01:28 | <stvs> | I urge the authors to update their screen reader software... |
| 01:29 | <Lachy> | waldir, don't trust moderators to approve messages from non-subscribers. |
| 01:29 | <Lachy> | it's likely that the moderation queue is flooded with spam and your message would be lost |
| 01:31 | <webben> | stvs: "This remark is also inaccurate for any screen reader of at least a decade back". What is that claim based on? |
| 01:33 | <waldir> | Lachy: then, I must say this feedback system is not very friendly to the random passerby who just wants to report a typo as is the case. I suspect many such helping hands must have been wasted because of process... |
| 01:41 | <stvs> | webben, I've tested Jaws and few more readers back then to see how they handle table sites, say amazon, ebay, google among others. |
| 01:41 | <stvs> | It worked good. |
| 01:41 | <stvs> | Some earlier readers had hilarious way of interpreting data in tables I admit |
| 01:41 | <stvs> | but that was in the 90-s |
| 01:41 | <stvs> | Such as flattening text lines and reading line by line |
| 01:42 | <stvs> | across table cells |
| 01:42 | <stvs> | no reader in wide use does this today |
| 01:42 | <webben> | stvs: That's not an especially exhaustive test. |
| 01:42 | <stvs> | and it was always more a reader fault than faul of html |
| 01:42 | <stvs> | webben, ok, I did some. What is that claim the spec based on? |
| 01:42 | <webben> | stvs: Please provide an algorithm for distinguishing data and layout tables. |
| 01:43 | <stvs> | webben, simple, I'll cite w3c from back then: if the table has no thead/th or other tabular data semantics but just plain td cells, it's to be treated as content without any assumptions. |
| 01:43 | <stvs> | Naturally IF it's a table that works by its nature again |
| 01:44 | <stvs> | But special handling is only needed to correlate headers and data, if you have no headers you have nothing to correlate |
| 01:44 | <stvs> | Therefore, there is no issue. |
| 01:44 | <webben> | stvs: I think you'll find that algorithm does not work in practice. |
| 01:44 | <stvs> | webben, I think I just said I tested it with actual readers. |
| 01:44 | <webben> | stvs: In particular, real-world algorithms for this task are rather more complex. |
| 01:44 | <stvs> | Again, which reader did you test in "practice"? |
| 01:46 | <webben> | stvs: I think the test is in applying said algorithm in bulk and seeing how many misidentifications you get. |
| 01:46 | <stvs> | webben, what computer do you have in front of you right now |
| 01:47 | <webben> | macbook |
| 01:47 | <stvs> | Great. Open safari and open ebay.com |
| 01:47 | <webben> | stvs: Dude. That isn't a sufficient test, as I've just explained. |
| 01:47 | <stvs> | Select all, now use the TTS to read the page |
| 01:47 | <stvs> | I'm trying to make you BEGIN to test |
| 01:48 | <stvs> | Because you assume problems without making any test. |
| 01:48 | <webben> | stvs: You realize that the behaviors you're seeing are actually dependent on applying more complex algorithms right? |
| 01:48 | <stvs> | I realize that you're trying to redefine the original issue. |
| 01:48 | <stvs> | Are tables a huge problem for layout. No. |
| 01:48 | <stvs> | Modern software handles it. |
| 01:49 | <webben> | stvs: Your testing is not sufficient to make that claim. |
| 01:49 | <webben> | Sorry. |
| 01:50 | <stvs> | So the deal is this: you do not test. Assume there's a problem. Anyone who actually tests is called to have not sufficient tests. |
| 01:50 | <webben> | stvs: If we can standardize a reliable algorithm for distinguishing data tables and layout tables, that would be useful regardless of the conformance status of layout tables. |
| 01:50 | <stvs> | Are you #whatwg's McCain or something? |
| 01:50 | <stvs> | Need more tests? |
| 01:50 | <stvs> | Need to test the tests? |
| 01:50 | <webben> | stvs: No. You've described the tests you've done and I don't think they're sufficient. |
| 01:51 | <webben> | stvs: And they don't give us a way to standardize an effective behavior. |
| 01:52 | <stvs> | webben, I think you're inversing the problem. |
| 01:52 | <stvs> | The spec cites vague issues which it can not support. |
| 01:53 | <stvs> | You can't cite any specific issues either. |
| 01:53 | <stvs> | So how was that conclusion made? |
| 01:53 | webben | sighs. |
| 01:54 | <stvs> | The fact is many of the most popular sites out there use tables, for good or bad reasons, and while not all of them are optimal for blind users, I've never seen the TABLE itself making it worse |
| 01:54 | <stvs> | The readers don't read out "table cell" |
| 01:54 | <webben> | stvs: Maybe people have been encountering misidentifications that you did not run across in your limited testing. |
| 01:54 | <stvs> | They read the content in the page. |
| 01:54 | <stvs> | "maybe"? |
| 01:54 | <stvs> | Is that your well argumented and supported position |
| 01:57 | <webben> | stvs: http://lists.w3.org/Archives/Public/public-html/2010Dec/0140.html |
| 01:58 | <stvs> | Thanks for the reference, webben |
| 01:58 | stvs | reads |
| 02:00 | <stvs> | webben, role="presentation" <- would you comment on this |
| 02:02 | <webben> | stvs: I have commented on it. (I'm Benjamin Hawkes-Lewis in that thread.) See also my concerns at http://lists.w3.org/Archives/Public/public-html-a11y/2010Dec/0267.html |
| 02:02 | <webben> | stvs: See also http://lists.w3.org/Archives/Public/public-html/2010Dec/0141.html for references to some of the complex algorithms deployed on the browser side. |
| 02:03 | <webben> | stvs: I believe these interact with additional algorithms on the AT side. |
| 02:04 | <webben> | stvs: I thinking testing with immensely popular sites like Ebay is problematic as these are a) more likely to have been tested by their developers to work with the current round of AT. |
| 02:04 | <webben> | and b) it's entirely possible that UAs/AT have specific behavior encoded for exceptionally popular sites |
| 02:04 | <stvs> | limiting that attribute to tables (for now) and only to elements that exhibit situation like tables seems to be a good solution, like you yourself said..? |
| 02:04 | <webben> | (e.g. Opera I believe does patches for particular sites - not for this issue, but generally.) |
| 02:05 | <webben> | stvs: Currently the spec allows role="presentation" on everything. |
| 02:05 | <stvs> | The issue of using it on other elements isn't the issue I'm trying to clarify in particular though |
| 02:05 | <stvs> | I'm saying, we have nothing to make flexible grids in HTML right now |
| 02:06 | <stvs> | Except tables. |
| 02:06 | <webben> | stvs: Are you talking about IE6-7 compat? |
| 02:06 | <stvs> | So an attribute hint, and saying "should avoid using tables for layout" instead of "must not" |
| 02:07 | <stvs> | I am, because they're still relevant, and using display:table on arbitrary elements is outright horrible, not to mention lack or row/colspan |
| 02:07 | <webben> | Yeah, I think HTML5 has bigger problems for IE6/IE7 compat than whether layout tables are conforming or not. |
| 02:08 | <stvs> | When the spec dispenses tips like "must not use" they should either reflect the reality, or if they reflect some ideal, at least have a note on how to deal with it in reality today |
| 02:08 | <webben> | I disagree using display:table on arbitrary elements is horrible. Not sure about impact of colspan/rowspan missing from the CSS model. |
| 02:08 | <stvs> | role="presentation" + td-only light tables seem completely harmless to me |
| 02:09 | <stvs> | And so I'm not misunderstood, I actually quite rarely use tables for layout in practice. |
| 02:09 | <webben> | Would be useful to have examples of popular layouts that cannot be achieved with colspan/rowspan. |
| 02:09 | <stvs> | It's not that I'm stuck in 95 and want my table mess. |
| 02:10 | <webben> | To some extent, I think role="presentation" is a red herring in so far as the people who need to use it probably won't. |
| 02:10 | <stvs> | webben, that is circular logic as you can't have popular table-only layouts when everyone is destroying you if you even mention table layouts. |
| 02:11 | <webben> | I'm more interested in adding features to CSS to support impossible layouts and standardizing algorithms for differentiating data/layout tables in the corpus. |
| 02:11 | <stvs> | I am too. But so far I'm not impressed with the grids module. |
| 02:11 | <stvs> | and when exactly will it be ready and widely available. I wonder if I'll be alive. |
| 02:11 | <stvs> | Literally |
| 02:12 | <webben> | stvs: I don't believe enabling layouts that aren't popular is a more important goal than keeping presentation out of markup. |
| 02:12 | <stvs> | Again, circular logic. |
| 02:12 | <webben> | It's not actually. |
| 02:13 | <stvs> | Let me demonstrate. The web circa 92-93, w3c is arguing images on the web are not popular, so enabling a popular feature is less important that providing good semantics for technical papers. |
| 02:13 | <stvs> | Of course it won't be popular when you *can't do it* |
| 02:13 | <stvs> | you need to provide it then if it's useful, it becomes popular. |
| 02:14 | <stvs> | We have no lack of such popular layouts outside the web |
| 02:14 | <stvs> | in .NET apps, iPad magazines are popping up |
| 02:14 | <webben> | stvs: by popular you mean "desired", by popular I mean "practiced" |
| 02:14 | <stvs> | And various layout frameworks in GUI toolkits |
| 02:14 | <stvs> | Same deal. |
| 02:14 | <stvs> | You can't practice something that you can't do in a browser. |
| 02:15 | <stvs> | So to see what can improve the web, again, you need to look outside the web |
| 02:15 | <webben> | "improve" is very much in the eye of the beholder there ;) |
| 02:15 | <stvs> | People are struggling every day with abusing floats for layout. |
| 02:15 | <stvs> | To me floats for layout is almost as bad as tables. |
| 02:16 | <stvs> | It's a poor tool for the job. |
| 02:16 | <stvs> | If the endless stream of "css tutorials" with 3000px wide transparent gifs and absolute in relative with negative margins inside a centers with and so on and so on CSS layouts don't bother you, they bother me. |
| 02:16 | <stvs> | They identify a clear need for simple layout tools. |
| 02:17 | <webben> | I'm concerned to preserve the sanity of the markup layer because that's where the service is. I can just about live with the insanity beyond that. |
| 02:17 | <stvs> | Oh well. |
| 02:17 | <stvs> | It's really too bad more people in w3c don't realize the code is the means and not the goal. |
| 02:18 | <webben> | stvs: I'd say it's a shame more people don't realize the service not the look is the goal. |
| 02:19 | <stvs> | It looks like w3c is in conflict with those who made the web what it is then. |
| 02:19 | <stvs> | No wonder XHTML2 failed |
| 02:20 | <webben> | stvs: "what it is" ... superficial, broken, inconsistent? ;) |
| 02:20 | <stvs> | Rich, capable. |
| 02:20 | <stvs> | A platform. |
| 02:21 | <webben> | Then I don't think your claim follows. |
| 02:22 | <stvs> | And I still don't know why role="presentation" on a table doesn't solve your particular grudge with layout tables |
| 02:24 | <webben> | stvs: 1. The people who need to use it won't use it. 2. It's not a substitute for a differentiating algorithm. 3. It will break if UAs provide any sort of interactivity for tables. |
| 02:24 | <webben> | (As I explained in those threads.) |
| 02:24 | <stvs> | 1. is a bogus point |
| 02:25 | <webben> | I disagree. |
| 02:25 | <stvs> | How often do you give up recommending a correct solution at the doubt people won't accept it? |
| 02:26 | <stvs> | Have you given up on recommending no tables for layout because people will use tables anyway? |
| 02:26 | <stvs> | Either is that attribute correct and you can recommend it, or it is not. |
| 02:26 | <webben> | stvs: If we're going to recommend the right thing, we might as well recommend the right thing. |
| 02:26 | <stvs> | Otherwise it's circular logic again |
| 02:26 | <stvs> | People won't use because I don't recommend it so I won't recommend it because people won't use it. |
| 02:27 | <stvs> | No improvement whatsoever can be done this way as I can rationalize any change as pointless using the same argument |
| 02:27 | <stvs> | So is role="presentation" the right thing or the wrong thing? |
| 02:28 | <stvs> | Point 2, also bogus |
| 02:28 | <webben> | I suspect it's less evil than the alternative of a unmarked layout table. |
| 02:28 | <stvs> | It's a direct substitute as it removes the need to detect what's explicitly pointed out |
| 02:28 | <webben> | Only if applied. So it's irrelevant to most of the corpus. |
| 02:29 | <stvs> | If it's less evil, is it not worth recommending it *until* a capable grids module for CSS is finalized |
| 02:29 | <stvs> | And available |
| 02:29 | <stvs> | Or is proving a point that tables are bad more important that the experience of people on the web? |
| 02:30 | <webben> | You assume I agree that various grid layouts are more important for that experience than a sane markup layer. |
| 02:31 | <stvs> | HTML is quite far from a "sane" markup layer any way you look at it. |
| 02:31 | <webben> | It's certainly ugly. |
| 02:31 | <stvs> | It's deeply flawed on so many planes. So preserving some imaginary perfection that was never there is misguided. |
| 02:31 | <webben> | But it's the best we've got for the moment. |
| 02:31 | <stvs> | Instead be practical |
| 02:31 | <stvs> | And address real world needs. |
| 02:32 | <stvs> | It may be shocking but people want to layout their sites. |
| 02:32 | <webben> | I am being practical and addressing real world needs - however, my prioritization of those needs is different to yours. |
| 02:32 | <webben> | This happens in the world. Hence politics. |
| 02:32 | <stvs> | It's not a matter of prioritization. |
| 02:33 | <stvs> | You can spend days arguing your objections, rather than spending an hour improving it with that attribute. |
| 02:33 | <stvs> | It's a matter of misplaced idealism if you ask me. |
| 02:34 | <webben> | It only ceases to be a matter of priorization when people's chasing after their desires interferes with delivery on those needs. |
| 02:35 | <webben> | Which is why the concrete questions about: why are people using table layouts today? what layouts are not possible with CSS today? are important |
| 02:35 | <webben> | from my perspective. |
| 02:35 | <stvs> | I answered that above. |
| 02:36 | <webben> | Not really. I actually do mean real examples. I was hoping some might be appended to the change proposal but no such luck. |
| 02:37 | <stvs> | Just like you calling my tests insufficient, I don't really think you want an answer. You want to ask enough questions so that you hope you don't get enough answers. |
| 02:37 | <stvs> | But this is honestly not a way to support your argument. |
| 02:37 | <stvs> | If you honestly think the attribute improves the situation, support it. |
| 02:37 | <stvs> | In 10 years when the grids module is out, change notes and ask people to phase it out |
| 02:37 | <stvs> | It's that simple. |
| 02:37 | <webben> | Imputing dishonesty to interlocutors doesn't really help your case... |
| 02:38 | <webben> | stvs: Ultimately, it's not /me/ you have to convince. |
| 02:38 | <stvs> | I am not saying you're dishonest. |
| 02:38 | <stvs> | I'm just saying you are really doing it anyway. |
| 02:39 | <stvs> | You are defending your position by whatever means necessary. |
| 02:40 | <roc> | FWIW I think a lot of browser implementors and other standards people agree that CSS desperately needs better layout tools |
| 02:40 | <webben> | I didn't come to this position overnight. You haven't presented me with data that's new to me, so … |
| 02:40 | <webben> | roc: Yep. |
| 02:41 | <stvs> | roc, well that's some light in the tunnel. And past the desire where are we :P ? |
| 02:41 | <webben> | stvs: I think it's a hard thing to spec. |
| 02:41 | <webben> | stvs: And we've had a backlog of catching up on more basic interoperability. |
| 02:42 | <stvs> | It's hard when you think there's a right solution. |
| 02:42 | <stvs> | There's a saying "there are no answers, only choices" |
| 02:42 | <roc> | a lot of things compete for attention |
| 02:42 | <stvs> | the primitives are obvious from other languages and frameworks, or even XUL of Mozilla. |
| 02:42 | <stvs> | vbox, hbox, grids, edge binding, proportional scaling |
| 02:43 | <webben> | stvs: It's not /just/ a case of picking one or a selection of those. |
| 02:43 | <roc> | e.g. alongside better layout primitives, there's better typography control, animation, accelerated graphics, various I18N features (e.g. vertical text), and so on |
| 02:43 | <stvs> | webben, it really is |
| 02:43 | <webben> | stvs: It's also a case of specifying how they interact with all the other CSS layout features. |
| 02:43 | <webben> | stvs: And then producing test suites etc. |
| 02:43 | <webben> | It's a /lot/ of work. |
| 02:44 | <stvs> | Well it's somehow a lot of work for CSS, while frameworks that implement such features grow up like mushrooms every day |
| 02:44 | <roc> | The flexbox spec is making progress both as a spec and in implementations |
| 02:44 | <stvs> | So, more action and less pondering might be the way |
| 02:44 | <webben> | stvs: And it's not like designers don't want flashy things like animations, etc. |
| 02:44 | <stvs> | webben, again, don't scope creep the issue at hand in attempt to make it seem impossibly hard. |
| 02:45 | <roc> | there is really no comparison between the difficulty of implementing a new CSS layout model and, say, a Swing or SWT layout manager |
| 02:45 | <stvs> | If you do that, walking out of bed will become extremely hard every morning, considering 360 degrees of freedom where you can step out. |
| 02:45 | <webben> | stvs: Defining interactions and writing tests is not "scope creep". |
| 02:45 | <webben> | stvs: And it's not impossibly hard, it's just time consuming things |
| 02:45 | <stvs> | rule based layouts are inherently animatable |
| 02:46 | <webben> | Or as Hixie's sig goes: "Impossible things just take longer" |
| 02:46 | <stvs> | because they are parametric. animate a parameter and they animate |
| 02:46 | <stvs> | that's hardly the issue here |
| 02:47 | <webben> | stvs: Well, all I can say is I recommend you contribute to the specs/implementations/tests. :) |
| 02:47 | <stvs> | roc, and why is that you'd say |
| 02:47 | <stvs> | roc, the current model works well for small parts of a page: a blurb summary, article, toc. |
| 02:47 | <roc> | Defining the interactions with all the other parts of the Web |
| 02:47 | <stvs> | it doesn't work well for the higher level blocks. |
| 02:48 | <stvs> | Not saying I solved the Issue, but here's a quicky solution: position:dynamic. |
| 02:48 | <roc> | Getting performance right |
| 02:48 | <stvs> | Now we have a new type of position with its own isolated rules. |
| 02:48 | <roc> | Handling all the edge cases acceptably for both performance and correctness |
| 02:48 | <stvs> | And we can put statis/relative/absolute elements *inside* it |
| 02:49 | <stvs> | Now dynamic can take the best of any of the hundreds layout kits out there that works. |
| 02:49 | <stvs> | And tommorow we'll wake up with a better web. |
| 02:49 | <stvs> | As if ;) |
| 02:53 | <stvs> | roc, what I find very puzzling, and yet educational, is that the w3c has always been extremely careful to not introduce inconsistent, limited, or complicated features in html/css. |
| 02:53 | <stvs> | And yet, if you think about it, compared to just about any other GUI layer, html/css is the most limited, complicated and inconsistent one. |
| 02:53 | <stvs> | And took longest to happen. |
| 02:54 | <stvs> | that's why thinking too much is ultimately a bad thing |
| 02:54 | <roc> | it's not at all true that "the w3c has always been extremely careful to not introduce inconsistent, limited, or complicated features in html/css" |
| 02:54 | <webben> | indeed! |
| 02:54 | <roc> | also, a lot of the features of HTML and CSS were introduced by browser vendors, not the W3C |
| 02:55 | <roc> | often in very undisciplined ways |
| 02:55 | <stvs> | why is this you think :) |
| 02:55 | <roc> | various reasons |
| 02:55 | <roc> | but things are getting better |
| 02:55 | <stvs> | may it be because browser vendors, being closer to the consumers and producers in the web can sense actual needs better. |
| 02:55 | <stvs> | Such as: we need layout tools |
| 02:56 | <stvs> | They are |
| 02:56 | <roc> | sure, but that doesn't excuse a lot of the crap that ended up in the Web platform due to vendors doing crazy things |
| 02:56 | <stvs> | Despite not being quite the engineering achievement, it works as a platform, and I like HTML5 as an effort for the most part. |
| 02:56 | <stvs> | It's practical, which is my kind of thing |
| 02:56 | <stvs> | Except for that blurb on "must not" for tables :/ |
| 02:57 | <roc> | I missed the beginning of the argument |
| 02:57 | <roc> | can't everyone just use "display:table" and be happy? |
| 02:57 | <stvs> | roc, <stvs> I really want to discuss the language int he HTML5 spec under "Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout." |
| 02:57 | <stvs> | <stvs> Such strong language is best left for the blogs of the various CSS "gurus" which aren't familiar the HTML4 spec itself suggested at one point using tables for layout (of forms, for example). |
| 02:57 | <stvs> | <stvs> While ideally we shouldn't rely, and normally we don't have to, unless with complex layouts, "must not" is inappropriate language considering there is no CSS alternative beside the still incomplete CSS3 grids module. |
| 02:58 | <roc> | ok |
| 02:58 | <roc> | er |
| 02:58 | <webben> | roc: I believe the argument is a) IE6-IE7 so no. and b) display: table doesn't have spans which are required for some layouts (what layouts?) |
| 02:58 | <stvs> | roc, webben mentioned role="presentation" which solves the "what is this table about" issue but he doesn't really support it |
| 02:58 | <roc> | display:table IS a CSS alternative |
| 02:58 | <stvs> | check webben's notes :P |
| 02:59 | <stvs> | furthermore is honestly recreating table, rows and cells via arbitrary tags the long sought solution? |
| 02:59 | <roc> | the IE<8 argument is not relevant. If you have to do something that works in IE<8 then don't even discuss modern CSS. Just use <table> because that's all you've got, and apologize. |
| 02:59 | <stvs> | It only makes code less maintainable. |
| 02:59 | <stvs> | you *need* to arrange these elements as you would a table |
| 02:59 | <stvs> | Except they're not a table. |
| 02:59 | <roc> | for screenreaders etc, it's helpful |
| 03:00 | <stvs> | role="presentation" is a much more comprehensible solution with the same outcome |
| 03:00 | <roc> | to not use <table> |
| 03:00 | <roc> | also, avoiding the insane HTML DOM construction rules for tables is a win |
| 03:00 | <stvs> | What about that attribute? |
| 03:00 | <roc> | whatever |
| 03:00 | <roc> | I'm not stickler for markup purity |
| 03:00 | <stvs> | :| |
| 03:01 | <roc> | just saying, if you want a CSS alternative to <table>, display:table is it |
| 03:01 | <roc> | unless you need spans I guess |
| 03:01 | <stvs> | And readable code :P |
| 03:01 | <stvs> | and IE6/7 support :P |
| 03:02 | stvs | .oO <div class="table"><div class="tr"><div class="td">...</div> <-- that's the bright future :P ? |
| 03:02 | <webben> | I don't think baking presentational expectations into the markup layer makes for more readable code. |
| 03:02 | <roc> | you can't have a serious conversation about the evolution of Web standards and throw in "oh it needs to work in IE<8" |
| 03:02 | <stvs> | webben, there are always presentational expectations in the markup |
| 03:03 | <stvs> | while CSS's goals are one of separation it's certainly not ideal |
| 03:03 | <stvs> | And it can't possibly be |
| 03:03 | <stvs> | It's instead "sufficient" |
| 03:03 | <webben> | stvs: I think minimizing those expectations is preferable. |
| 03:04 | <stvs> | You won't minimize anything by appointing a set of different tags for a table. |
| 03:04 | <webben> | (I also think it's plausible to imagine more complete separations than we have now.) |
| 03:04 | <stvs> | they need to be arranged exactly as a table would be |
| 03:04 | <stvs> | In fact that makes the markup even more dependent on CSS for interpretation |
| 03:04 | <webben> | stvs: well for one thing you could use classes for your bits of page that reflect the bit of page they are, not the position they hold |
| 03:04 | <stvs> | Which goes back to my point: separation is never ideal. |
| 03:04 | <stvs> | webben, that's not how display:table works |
| 03:05 | <stvs> | I need a table, in it rows, in it cells |
| 03:05 | <stvs> | Cells go from left to right |
| 03:05 | <stvs> | Rows top to bottom |
| 03:05 | <stvs> | So we solved nothing basically. |
| 03:05 | <roc> | it depends on what you're trying to do |
| 03:05 | <stvs> | A layout ;) |
| 03:05 | <roc> | for some kinds of markup, display:table is a good fit |
| 03:05 | <roc> | for others it's not |
| 03:05 | <stvs> | 8shrug* |
| 03:06 | <roc> | not knowing what you're trying to do, I can't say what the right solution is |
| 03:06 | <roc> | flexbox solves a good number of the use cases where tables aren't quite right |
| 03:06 | <stvs> | To me using display:table is just the exit strategy of those who realize they need grids but spend years hating tables. |
| 03:06 | <stvs> | The new strategy is: let's pretend it's not a table, but make it one |
| 03:07 | <stvs> | I saw flexbox, it's an interesting thing |
| 03:07 | <stvs> | Based on XUL right? |
| 03:08 | <roc> | roughly |
| 03:09 | <webben> | stvs: Nothing in display:table stops you using content-appropriate class names. I agree it might lead you to add containers for "rows" of content that with better CSS facilities you might not need |
| 03:10 | <stvs> | webben, the problem is one of arranging content, less so of naming. |
| 03:10 | <stvs> | We'll see. |
| 03:11 | <stvs> | Looks like I have to go, thanks for the talk, roc, webben |
| 03:11 | <webben> | yw - thanks for your thoughts |
| 03:45 | <oojacoboo> | if you do something like td {border-right: 3px solid #000;} td.last-child {border-right: 0;} |
| 03:45 | <oojacoboo> | why is it that the table wouldn't paint itself properly |
| 03:46 | <oojacoboo> | in other words, it counts that 3px into the width of the table cell/column |
| 03:46 | <oojacoboo> | instead of calculating it without that 3px, it just adds it to the width of that column instead of repainting, this appears to be happening in both firefox and chrome too :/ |
| 03:47 | <oojacoboo> | is this common behavior? I mean, in most cases this would result in a correct looking table, but if you are using a background image without repeating it in one of the cells in the column, you will clearly have a width issue, and trying to override the width calculating doesn't seem to help |
| 03:48 | <oojacoboo> | in my case I was able to solve the issue by using border-left and first-child, but I figured I would bring this up here to see if anyone knew/gave-a-shit |
| 08:04 | <zcorpan> | Hixie: could you remove the "..." in live dom viewer? :) |
| 09:53 | <jgraham> | hsivonen: Agreed that not changing unpaired surrogates in document.write might be simpler to implement, although it is conceptually harder to understand, and harder to test (because I can't just reuse parser tests as document.write tests) |
| 10:08 | <jgraham> | People really use "non-shortest form"? That seems unnecessarily mealy-mouthed |
| 10:24 | <zcorpan> | if you quote "overlong form" and "non-shortest form" in google search, the difference is even greater |
| 10:28 | <Philip`> | "non-shortest form" seems more accurate and unambiguous |
| 10:29 | <Philip`> | since it's not clear what length is considered overlong |
| 10:29 | <Philip`> | unless you already know that only the shortest form is allowed |
| 10:30 | <jgraham> | Which, in context seems like an entirely reasonable thing to assume |
| 10:37 | <zcorpan> | "utf-8 overlong" - 12600 results. "utf-8 "overlong"" - 80900 results |
| 10:38 | <zcorpan> | "utf-8 non-shortest" - 25000. "utf-8 "non-shortest"" - 5690 |
| 10:38 | <zcorpan> | conclusion: ??? |
| 10:39 | <Philip`> | Google's result counts are extremely rough approximations and should not be taken seriously? |
| 10:51 | <jgraham> | Anyone know of a testsuite for XSLT in HTML? |
| 11:03 | <Ms2ger> | Yay, -webkit-linear-gradient |
| 11:13 | <hsivonen> | jgraham: if you find a test suite for XSLT in HTML, please let me know |
| 11:14 | <hsivonen> | (if you write one, please let me know in that case, too) |
| 11:14 | <jgraham> | hsivonen: Writing one is what I really want to avoid :) |
| 11:53 | <david_carlisle> | jgraham: only public xslt test suite I know of is http://www.w3.org/Style/XSL/TestSuite/ |
| 11:53 | <david_carlisle> | unfortunately xslt2 one is w3c only |
| 11:53 | <david_carlisle> | not sure how much work would be to convert that for html input |
| 11:57 | <david_carlisle> | er no that's mainly xsl-fo there is an xslt collection somewhere... |
| 11:58 | <jgraham> | david_carlisle: Thanks. I am also (perhaps mostly) interested in tests using the DOM APIs for XSLT https://developer.mozilla.org/en/using_the_mozilla_javascript_interface_to_xsl_transformations since that seems to be the main way one can pass a text/html-created DOM into a transform |
| 11:59 | <jgraham> | Unless there is some other way to do that I can't think of right now |
| 11:59 | <jgraham> | which is likely given my relationship with XSLT |
| 12:02 | <david_carlisle> | jgaraham, yes i figured you's want that input, but given a pile of xslt scripts and expected output, calling it with a particular APi is just a matter of munging it with perl or something isn't it:-) |
| 12:02 | <david_carlisle> | http://www.oasis-open.org/committees/workgroup.php?wg_abbrev=xslt |
| 12:02 | <david_carlisle> | appears to be the most recent attempt at a public xslt 1 test suite |
| 12:02 | <jgraham> | david_carlisle: Yeah, probably |
| 12:06 | <jgraham> | "This Group Has Been Deactivated" — that totally makes it sound like it was comprised of rouge killing machines from the future |
| 12:16 | <Workshiva> | jgraham: Who else would design xslt? |
| 12:20 | <david_carlisle> | Workshiva: xslt people are nice people, not killing machines (and most of them don't wear rouge) |
| 12:32 | <Workshiva> | david_carlisle: I don't think they wear rouge, they kill rouge |
| 12:45 | <stvs> | I still don't know why it says "Please leave your sense of logic at the door" :D |
| 12:46 | <annevk> | sounds like you didn't follow the advice |
| 12:47 | <stvs> | :( |
| 12:50 | <zcorpan> | stvs: it's because if you try to apply logic to html, you end up with MULTIFAIL |
| 12:55 | <stvs> | zcorpan :( |
| 12:56 | <stvs> | The web is working so what does this mean then :) |
| 12:56 | <stvs> | Logic is irrelevant to the things working. |
| 12:56 | <stvs> | And there's some truth in that. |
| 13:06 | <hsivonen> | stvs: btw, if you want to argue the layout table thing, the correct procedure is to join the HTML WG and to submit a Change Proposal for http://www.w3.org/html/wg/tracker/issues/130 |
| 13:44 | <stvs> | hsivonen, I might check it out. Thanks |
| 13:46 | <annevk> | stvs, didn't want to put you off |
| 13:46 | <annevk> | stvs, it basically means that browsers are crazy pieces of software full of holes and the web somehow still works great |
| 13:46 | <stvs> | annevk, nah, I see your point :) |
| 13:46 | <annevk> | stvs, and that you typically should not approach what browsers do rationally |
| 13:47 | <stvs> | I am becomig increasingly convinced that the criteria for success of technology we find intuitive are not quite correct. |
| 13:47 | <annevk> | I have wondered about that too |
| 13:48 | <annevk> | it seems a certain amount of imperfection does great for adoption |
| 13:48 | <annevk> | HTML and PHP being nice examples of that |
| 13:48 | <stvs> | It is. The users are needy: they always go out of scope in order to stretch a spec to fill new needs. |
| 13:48 | <stvs> | Users are imperfect: they make mistakes. |
| 13:50 | <stvs> | And users do not care about ideals: they have a specific line and they draw a straight line from their need to the closest approximation of a solution. |
| 13:50 | <stvs> | specific need* |
| 15:51 | <karlcow> | MikeSmith: https://github.com/chriso/cli "cli is a tool for rapidly building NodeJS command line apps" |
| 16:18 | <karlcow> | hmmm in cookies token production rules TAB is excluded two times in RFC 2616 |
| 16:18 | <karlcow> | :) not very important |
| 16:18 | <karlcow> | token = 1*<any CHAR except CTLs or separators> |
| 16:19 | <karlcow> | CTLs include (0-32) and separators include HT (9) |
| 16:19 | <karlcow> | which is in CTLs |
| 16:52 | <hsivonen> | http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/ |
| 16:52 | <hsivonen> | floats are hard |
| 16:53 | karlcow | has suddenly collapsing contexts. Japanese floating world and hard/rigor |
| 16:59 | <Philip`> | Apparently it's a bug in their strtod, but is it caused by some PHP-specific modifications or is it a common problem in other applications based on the same original strtod? |
| 17:00 | <bga_> | we need "project" nomonkeypatching.js |
| 17:00 | <paul_irish> | bga_: what'd that be? |
| 17:00 | <bga_> | which makes appendChild ... readonly fields |
| 17:01 | <bga_> | and do not let shoot you in your own leg |
| 17:01 | <Philip`> | (The code is reportedly http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_strtod.c?revision=255174&view=markup&pathrev=260750 which looks like it's been slightly modified) |
| 17:17 | <karlcow> | http://webintents.appspot.com/ (maybe already known) |
| 17:41 | <jgraham> | Hm, is the innerHTML serialization algorithm missing some magic needed for certain attributes (href, on*) containing ", or am I just missing something? |
| 17:42 | annevk | looks |
| 17:43 | <annevk> | did you read the bit about escaping? |
| 17:44 | <annevk> | it says " becomes " |
| 17:44 | <annevk> | among other things |
| 17:44 | <jgraham> | Yes |
| 17:44 | <jgraham> | Which it does |
| 17:44 | <jgraham> | Except in some cases, afaict |
| 17:44 | <annevk> | it says "the attribute's value, escaped as described below in attribute mode" |
| 17:45 | <annevk> | right, " does not become " when it is Text or some such |
| 17:45 | <annevk> | only as attribute value |
| 17:46 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/758 |
| 17:47 | <jgraham> | Oh, WebKit does what the spec says |
| 17:47 | <jgraham> | Gecko is bizzare |
| 17:47 | <jgraham> | and Opera never escapes |
| 17:48 | <annevk> | Yeah, Chrome/Safari do the sane thing |
| 17:48 | <annevk> | Opera is dangerous |
| 17:48 | <annevk> | :/ |
| 17:48 | <jgraham> | OK, I was confused by a test that checked for Opera behaviour that also passed in Gecko |
| 17:48 | <zcorpan> | opera escapes when the value contains both " and ' |
| 17:49 | <zcorpan> | annevk: what's dangerous? |
| 17:49 | <annevk> | I blame my fever |
| 17:51 | <annevk> | http://warpspire.com/posts/url-design/ -- nice that people still care (I guess karlcow might have posted this already) |
| 17:52 | <karlcow> | I seen it but I do not remember if I posted it ;) |
| 17:53 | <karlcow> | though there are part of it which makes me a bit… worried :) |
| 17:53 | <jgraham> | OK, but http://software.hixie.ch/utilities/js/live-dom-viewer/saved/760 is not escaped |
| 17:53 | <jgraham> | in WebKit |
| 17:54 | <annevk> | wait how is that different? |
| 17:55 | <annevk> | and what is 759? |
| 17:55 | <jgraham> | javascript: uris seem to be special |
| 17:56 | <annevk> | o_O |
| 17:57 | <jgraham> | I guess this is how I know it is time to go home :) |
| 17:57 | <annevk> | stvs, ^^, relevant to your interests :) |
| 17:57 | jgraham | wonders if that quirk is required for compat |
| 18:00 | <gsnedders> | jgraham: Did you se my commit to html5lib? |
| 18:11 | <annevk> | http://trac.webkit.org/browser/trunk/WebCore/editing/MarkupAccumulator.cpp#L161 it does not cite compat |
| 18:11 | <annevk> | just crazy |
| 19:00 | <jgraham> | annevk: I would be scared that someone does eval(extract_javascript_from_attribute(foo.innerHTML)) |
| 19:00 | <jgraham> | gsnedders: Well I saw you siad you made one |
| 19:00 | <annevk> | it sort of seems that is exactly what they cater for |
| 19:00 | <jgraham> | I didn't look yet |
| 19:01 | <annevk> | because they do not do it when the URL contains a ' |
| 19:01 | <annevk> | not sure what is considered a URL attribute |
| 19:01 | <annevk> | Peter` can probably figure that out :hint: |
| 19:03 | <Peter`> | Figuring out what an URL attribute is? |
| 19:03 | <annevk> | "Simply because a few thousand XML weenies think the world revolves around XML doesn't mean that the Real World contains, to a first approximation, anything but HTML." -- John Cowan |
| 19:03 | <annevk> | I think stuff just got real |
| 19:04 | <annevk> | Peter`, see the link above. It's about serialization of attributes in the context of e.g. innerHTML |
| 19:06 | <Hixie> | annevk: url? |
| 19:07 | <Peter`> | I'm totally missing the context here, I actually got home about ten minutes ago |
| 19:07 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0049.html |
| 19:09 | <hober> | So, I'm becoming part of the vast, browser-wing conspiracy: I've taken a job on the Safari / WebKit team at Apple. |
| 19:10 | <Hixie> | grats! |
| 19:10 | <Peter`> | Congratulations :) |
| 19:12 | <paul_irish> | whoa! awesome! that's huge hober. :D |
| 19:12 | <gsnedders> | hober: The browsers are taking over! Soon nothing else will be relevent! |
| 19:13 | <zcorpan> | hober: welcome to the dark side |
| 19:14 | <hober> | thanks :) |
| 19:14 | <othermaciej> | hober: now you can truly be a part of ruining the Web and hating everything good |
| 19:15 | <jgraham> | hober: You're joining both the vast-browser-wing conspiracy *and* the vast Apple conspiracy all at the same time? |
| 19:15 | <hober> | othermaciej: excellent. muhahahahaa. |
| 19:15 | <hober> | jgraham: yeah, I figured I'd kill 2 conspiratorial birds with one stone. |
| 19:15 | <Ms2ger> | othermaciej, you're off the cabal's PR subcommittee |
| 19:15 | <othermaciej> | oh yeah, since it's Apple, make sure to close everything in your house that's currently open |
| 19:17 | <Hixie> | lol |
| 19:18 | <Hixie> | Ms2ger: thanks |
| 19:18 | <gsnedders> | Ms2ger: Shh, that comittee doesn't exist! |
| 19:18 | <Hixie> | that mailing list looks like a lot of pain |
| 19:18 | <Ms2ger> | No,seriously? |
| 19:18 | <Ms2ger> | gsnedders, I guess I'm off too now |
| 19:31 | <annevk> | congrats hober |
| 19:31 | <hsivonen> | hober: congratulations |
| 19:32 | <hober> | thanks :) |
| 19:32 | <Peter`> | http://twitter.com/#!/sgalineau/status/22375757045047296 |
| 19:32 | <hober> | looking forward to it, but dreading the move |
| 20:03 | <heycam> | nice work hober! |
| 20:17 | <mpilgrim> | any opera employees around? |
| 20:18 | zcorpan | is |
| 20:18 | <mpilgrim> | i'm seeking someone to relicense this image under CC-BY-3.0-unported: http://devfiles.myopera.com/articles/4582/fig5.png |
| 20:18 | <mpilgrim> | from this article: http://dev.opera.com/articles/view/new-form-features-in-html5/#input-color |
| 20:18 | gsnedders | is |
| 20:19 | <mpilgrim> | for use in diveintohtml5.org and the next printed edition of "html5: up and running" |
| 20:20 | <zcorpan> | email patrickl@ opera.com or cmills@ opera.com |
| 20:20 | <mpilgrim> | i could make my own, but it's a nice image and i'm lazy |
| 20:20 | <mpilgrim> | in a good way (usually) |
| 20:20 | <mpilgrim> | ok |
| 20:21 | <zcorpan> | mpilgrim: btw i heard android 2.3 supports webm |
| 20:21 | <mpilgrim> | i heard that too |
| 20:22 | <mpilgrim> | can't remember where |
| 20:22 | <mpilgrim> | somewhere public |
| 20:22 | <mpilgrim> | probably here: http://developer.android.com/sdk/android-2.3-highlights.html |
| 20:22 | <mpilgrim> | "The platform now offers built-in support for the VP8 open video compression format and the WebM open container format." |
| 20:22 | <mpilgrim> | yay |
| 20:23 | <mpilgrim> | i wonder if handset manufacturers will ship hardware acceleration support |
| 20:34 | <mpilgrim> | in case people were wondering, the top search terms that brought people to http://diveintohtml5.org/ in 2010 were variations of "html5 video", "html5 forms", and "html5 canvas" |
| 20:34 | <mpilgrim> | in that order |
| 20:34 | <Workshiva> | There's a huge potential for expansion hardware in the market |
| 20:34 | <mpilgrim> | geolocation was a distant 4th |
| 20:35 | <Workshiva> | We've had graphics cards in desktop computer, surely we can fit something similar on phones :) |
| 20:35 | <paul_irish> | mpilgrim: interesting! good to know |
| 20:35 | <mpilgrim> | i may do a whole blog post on 2010 analytics for the site |
| 20:36 | zcorpan | concludes video has the best profit and goes write a book on html5 video |
| 20:37 | <Philip`> | Surely you should make a video on HTML5 video |
| 20:38 | <mpilgrim> | briefly: 4 million pageviews, 2 million visitors, 1.1 million absolute unique visitors |
| 20:38 | <Philip`> | except HTML5 video doesn't support DRM so everyone would pirate your video and you wouldn't make any money :-( |
| 20:38 | <mpilgrim> | all versions of IE combined account for less than 7% of all visitors |
| 20:38 | <mpilgrim> | my book doesn't support DRM and it's made $160,000 so far |
| 20:39 | <zcorpan> | Philip`: that's it, i should write a book about how to do DRM with html5 video |
| 20:39 | <mpilgrim> | absolutely positioned transparent gifs over the video element? |
| 20:39 | <mpilgrim> | i think that's what youtube uses |
| 20:40 | <zcorpan> | <img src="http://spacergif.mobi/">; |
| 20:40 | <mpilgrim> | obviously we need a spacer gif TLD |
| 20:41 | <Philip`> | <img src="about:spacergif"> |
| 20:41 | <Philip`> | That'd save needless network traffic |
| 20:41 | <zcorpan> | maybe we should just have <spacer> |
| 20:42 | <mpilgrim> | iOS (iPhone+iPad+iPod) accounts for 85% of all mobile devices hitting http://diveintohtml5.org/ |
| 20:42 | Philip` | is worried by how few errors people are reporting in the canvas tests |
| 20:43 | <Philip`> | False negatives will be found when people investigate test failures, but I expect false positives will survive forever |
| 20:44 | <zcorpan> | Philip`: i know i haven't investigated any of your tests that pass |
| 20:44 | mpilgrim | feels guilty for not committing his latest round of video tests |
| 20:45 | <gsnedders> | Philip`: Much the same is true of any test suite unless it really is strictly reviewed. CSS 2.1 is in much the same state. Just have to hope one impl actually follows the spec and not the test. :) |
| 20:47 | <mpilgrim> | (back to dih5 stats)...but mobile devices account for only 4% of all visits |
| 20:47 | <Philip`> | gsnedders: I'm more worried about tests that pass regardless of what the browser implements, rather than failing on correct behaviour, because then the test is useless and nobody will ever see it fail |
| 20:48 | <mpilgrim> | which makes me feel a little better about having a broken mobile stylesheet |
| 20:48 | <Ms2ger> | Philip`, and tests that don't match informative text will be found by Microsoft :) |
| 20:48 | <Workshiva> | What if there was a bounty on invalid tests? |
| 20:49 | <gsnedders> | Workshiva: It's very expensive reviewing test suites, so basically nobody does it. |
| 20:49 | <gsnedders> | The bounty would need to be raelly quite large. |
| 20:49 | <Workshiva> | Nono, crowdsourcing |
| 20:49 | <Workshiva> | Appeal to all the standards lawyers out there |
| 20:49 | <Ms2ger> | Hi :) |
| 20:50 | <zcorpan> | we shouldn't review tests, we should just write more tests |
| 20:51 | <Philip`> | Workshiva: It's hard to define "invalid" usefully, I think |
| 20:52 | <gsnedders> | A test that always passes has a low cost. A test that gives the wrong result given correct behaviour has a high cost. |
| 20:52 | <mpilgrim> | wow, search engines accounted for only 40% of my traffic |
| 20:52 | <mpilgrim> | i expected twice that much |
| 20:53 | <othermaciej> | clearly you need better SEO |
| 20:53 | <Philip`> | I think my approach is usually to try to think of errors that implementors might make, and then write a test that will fail for each error, and a test is incorrect if it won't actually fail for that error |
| 20:54 | <Philip`> | but by looking at a test case in isolation you can't always tell what error it was attempting to fail for |
| 20:54 | <Philip`> | so you can't tell whether it's incorrect |
| 20:54 | <mpilgrim> | if only there were some sort of consultant i could hire to improve my ranking in search engines |
| 20:54 | <Philip`> | and also you can't see if there's some likely error which there are no tests for |
| 20:55 | <zcorpan> | mpilgrim: you just need to stuff some keywords in your alt tags, that'll do the trick |
| 20:56 | <mpilgrim> | if only i used alt |
| 20:56 | <gsnedders> | Philip`: wrt public-html-testsuite, Opera still has plenty of issues in DOM with null characters |
| 20:56 | <mpilgrim> | wow, daringfireball.net sent me three times as much traffic as bing.com |
| 20:56 | <Philip`> | gsnedders: Does it have fewer than before? |
| 20:57 | <gsnedders> | Philip`: Yes. |
| 20:57 | <Philip`> | gsnedders: Okay, so at least it's making progress :-) |
| 20:59 | <mpilgrim> | google accounted for 98.7% of my search engine traffic |
| 20:59 | <mpilgrim> | what monoculture? |
| 21:04 | <mpilgrim> | 5:28 avg. time spent on /video.html |
| 21:04 | <mpilgrim> | 4:44 on /past.html |
| 21:04 | <mpilgrim> | people love them some html folklore |
| 21:05 | mpilgrim | makes a mental note to share that statistic with my o'reilly editor, who insisted that nobody would read a whole chapter on the history of html |
| 21:05 | <Philip`> | Maybe people open the page, read a paragraph, then doze off for a few minutes, then wake up and leave the page? |
| 21:06 | <mpilgrim> | yes, that seems more likely |
| 21:07 | <Philip`> | Analytics software ought to activate the user's webcam and take a snapshot, so it can determine how engaged they are with the content |
| 21:09 | <hober> | ganalytics + <device> :) |
| 21:09 | <mpilgrim> | that's coming in Analytics 4.0: Telescreen edition |
| 21:37 | <jgraham> | Philip`: It is occasionally pointed out to me that the number of real pages that do canvas.getContxt("2d\u0000") is 0 |
| 21:38 | <Dashiva> | jgraham: Until someone realizes there's a buffer overflow hidden in there |
| 21:39 | <jgraham> | Dashiva: Well that is quite differnt of course |
| 21:49 | <Philip`> | jgraham: Sure, the cost:benefit ratio of fixing that particular test case is infinite |
| 21:50 | <Philip`> | but that's a problem for whoever has the job of prioritising bug fixes, not for me |
| 21:51 | <Philip`> | (Also it's a problem for anyone who cares about 100% pass rates) |
| 21:51 | <Philip`> | (e.g. if W3C Rec status is dependent on that) |
| 21:51 | <Philip`> | (but that's still not my problem) |
| 21:57 | <jamesr_> | making sure implementations handle odd/mangled/etc strings correctly is normally important security wise |
| 23:31 | <benschwarz> | paul_irish: Ola! |
| 23:32 | <paul_irish> | benschwarz, welcome!!! (guy who redesigned the w3c html5 author spec to look pretty n all that ) |
| 23:33 | <Hixie> | oooh, i wanted to talk to that guy! |
| 23:33 | <benschwarz> | Thanks for the intro. Your tweet prompted me to log here |
| 23:33 | <Hixie> | benschwarz: do you mind if i reuse your style sheet (probably with modifications) on the whatwg site also? |
| 23:34 | <benschwarz> | Hixie: I'd love you to do that. I was thinking that I should "licence it" for uses by the w3c and whatwg only yesterday—Just to be clear of my intentions |
| 23:34 | <Hixie> | sweet |
| 23:34 | <Hixie> | dunno when i'll get to it but http://www.w3.org/Bugs/Public/show_bug.cgi?id=11229 is tracking this particular issue |
| 23:35 | <Hixie> | my plan is to make the "author view" version of the whatwg spec use your style sheet |
| 23:35 | <Hixie> | see that bug and the reddit comment linked to from there for more details |
| 23:35 | <Hixie> | if you would like i can set it up so that it grabs the style sheet from somewhere you control, so you can update it in realtime |
| 23:35 | <benschwarz> | I've got some additional fixes for colour and some bugs in opera that brucel raised… |
| 23:35 | <Hixie> | (either on your site, or i can give you an account on whatwg.org) |
| 23:36 | <benschwarz> | Hixie: I think that would be best, so that I can have some form of active deployment |
| 23:36 | <benschwarz> | Right now the process is that I build it here, work against it, commit it to a repo, Mike merges from git to cvs, then *magic* |
| 23:37 | <Hixie> | benschwarz: yeah |
| 23:37 | <benschwarz> | Hixie: I'm happy for an account on whatwg… |
| 23:38 | <Hixie> | benschwarz: w3c kinda frown on linking out to other sites, but there's no problem with linking out on whatwg.org so if your site can handle the (pretty small) load, that's fine by me |
| 23:39 | <Hixie> | so it's entirely up to you |
| 23:40 | <Hixie> | (if you would rather an account on whatwg.org, let me know your preferred username) |
| 23:40 | <oojacoboo> | that new "too slow" alert seems like it's made the spec more sluggish |
| 23:40 | <Hixie> | oojacoboo: i doubt it's the alert that's made it more sluggish, but it might just be bringing attention to it :-) |
| 23:41 | <oojacoboo> | seems fine now that it's gone |
| 23:41 | <oojacoboo> | it was struuuuuglng with it up |
| 23:41 | <benschwarz> | Hixie: Tell you what—Lets do whatwg.org, because of the cross domain issues that paul_irish raised with webfonts… |
| 23:41 | <Hixie> | oojacoboo: oh while the alert is up it might be slow because the alert is semi-transparent position:fixed and your browser might not be good at scrolling that |
| 23:41 | <Hixie> | benschwarz: k, sounds good |
| 23:42 | <Hixie> | benschwarz: preferred username? |
| 23:42 | <benschwarz> | and the infrastructure is already going… |
| 23:42 | <benschwarz> | Hixie: 'benschwarz' will do fine |
| 23:42 | <Hixie> | k |
| 23:42 | <Hixie> | do you prefer to work using scp, or do you prefer to edit things like on the host over ssh? |
| 23:42 | <Hixie> | edit things live, even |
| 23:43 | <benschwarz> | Hixie: If I can build the spec locally just as easily as the author-spec, then I'd scp it. |
| 23:43 | <Hixie> | build the spec locally? |
| 23:44 | <benschwarz> | Hixie: Yeah, on my machine |
| 23:44 | <benschwarz> | Just to style against the HTML |
| 23:45 | <Hixie> | what are your inputs and outputs? |
| 23:45 | <Hixie> | (just trying to work out what exactly you mean by "build") |
| 23:45 | <benschwarz> | Oh, sorry… |
| 23:45 | <Hixie> | (there's a number of steps involved from the original source file all the way to what's on the w3c site, and the whatwg site has a slightly different branch of that process) |
| 23:46 | <benschwarz> | I'd checkout the source of the entire spec, run the build command, then write my stylesheets against the HTML product. |
| 23:46 | <Hixie> | (so it's not entirely clear what you mean!) |
| 23:46 | <benschwarz> | Hixie: Ah sure—Well with the author spec… |
| 23:46 | <benschwarz> | https://github.com/benschwarz/html5forAuthors |
| 23:46 | <benschwarz> | I built it using the Makefile that sideshowbarker uses |
| 23:47 | <Hixie> | aah |
| 23:47 | <Hixie> | i think that's a part of the process that doesn't happen for the whatwg copy |
| 23:47 | <Hixie> | hmm |
| 23:47 | <Hixie> | i guess what you mean by "spec source" is actually the post-processed single-page version of the spec |
| 23:48 | <Hixie> | what i consider my primary "output" :-) |
| 23:48 | <Hixie> | aka http://www.whatwg.org/specs/web-apps/current-work/ |
| 23:49 | <benschwarz> | Hixie: Yes right :) |
| 23:49 | <benschwarz> | Hixie: How about you throw what you have at me, I'll work it out… |
| 23:49 | <benschwarz> | otherwise I'm sure that I can ask |
| 23:50 | <Hixie> | i'm just trying to work out how where to put things |
| 23:50 | <Hixie> | so your output is a bunch of HTML, CSS, and JS files, right? |
| 23:50 | <benschwarz> | Yep |
| 23:50 | <Hixie> | is your work environment unix? |
| 23:51 | <Hixie> | or rather: |
| 23:51 | <benschwarz> | Mac, but uyes |
| 23:51 | <benschwarz> | yes * |
| 23:51 | <Hixie> | hm |
| 23:51 | <Hixie> | so here's what i figure the long-term situation might be |
| 23:52 | <Hixie> | instead of the current situation where we have a multipage copy that has radio buttons to switch style sheets, we have the author version of the spec actually be on its own domain, like authors.whatwg.org/html/ or some such |
| 23:52 | <Hixie> | with you in charge of authors.whatwg.org |
| 23:52 | <Hixie> | and then each time i regen the script, i can ping a CGI script on authors.whatwg.org that regens the author version from the full version |
| 23:52 | <Hixie> | what do you think? |
| 23:53 | <benschwarz> | Hixie: sounds good to me! |
| 23:53 | <Hixie> | and we don't need the cgi scripts in the author version, so that solves that issue (the cgi scripts being the ones that show the current status of each section, and the bug filing tool) |
| 23:53 | <Hixie> | awesome |
| 23:53 | <Hixie> | let's get that set up |
| 23:53 | <benschwarz> | so when you say authors spec, you mean web developer edition |
| 23:54 | <benschwarz> | I always found that terminology "web authors" so ambiguous |
| 23:54 | <Hixie> | yeah |
| 23:54 | <Hixie> | yeah, it's a historical thing |
| 23:54 | <Hixie> | we talk in terms of authors, users, implementors, and spec editors |
| 23:55 | <Hixie> | but authors these days are really web devs |
| 23:55 | <Hixie> | what should the subdomain be rather than authors.whatwg.org? |
| 23:55 | <Hixie> | help.whatwg.org? webdevs.whatwg.org? |
| 23:55 | <Hixie> | guides.whatwg.org? |
| 23:56 | <Hixie> | note that the whatwg.org/c spec (the "complete" spec) contains more than just HTML (more than the whatwg.org/html spec) |
| 23:56 | <Hixie> | hence my suggestion that we put this guide in something.whatwg.org/html, so that later we can add guides for other things too |
| 23:56 | <Hixie> | like web workers, web storage, etc |
| 23:56 | <benschwarz> | sure… |
| 23:57 | <benschwarz> | Hixie: It sounds a bit official, but don't you think something like developers.whatwg.org would be good? |
| 23:58 | <benschwarz> | After all, web developers are the target |
