| 00:43 | othermaciej | would appreciate input on his recent bugs from people who know more about document conformance |
| 00:51 | <AryehGregor> | othermaciej, they all look good to me. |
| 01:52 | <othermaciej> | like I don't know the deep reason <nobr> and <wbr> are nonconforming |
| 01:52 | <othermaciej> | maybe just because they never were conforming before? |
| 01:52 | <AryehGregor> | I would guess it's because, unlike <pre> and <br>, they were not in any previous spec. |
| 01:52 | <AryehGregor> | Yeah. |
| 01:53 | <Dashiva> | They don't feel entirely semantic to me. Line breaking (or not) is fairly deep into CSS territory. |
| 01:53 | <AryehGregor> | Then why doesn't that apply to <pre>? |
| 01:53 | <AryehGregor> | Or <br>? |
| 01:53 | <Dashiva> | Of course, <wbr> can't really be emulated |
| 01:53 | <AryehGregor> | Also, as Maciej points out, <wbr> can't be emulated -- yeah. |
| 01:54 | <AryehGregor> | I'm also planning to file a bug requesting that most or all presentational attributes/elements be made conforming (possibly obsolete but conforming so they throw an error). Something like <table cellpadding=5> is difficult to reproduce exactly in inline CSS, and even more difficult to convert automatically. And some, like cellspacing, have no direct CSS equivalent that works in (for example) IE6. |
| 01:54 | <Dashiva> | <pre> is different, because it says the whitespace is significant |
| 01:54 | <AryehGregor> | s/so they throw an error/so they raise a warning/ |
| 01:54 | <AryehGregor> | Dashiva, <nobr> says line breaks are significant. |
| 01:55 | <AryehGregor> | Er. |
| 01:55 | <AryehGregor> | Or, no. |
| 01:55 | <AryehGregor> | What does it do? |
| 01:55 | AryehGregor | has never used it |
| 01:55 | <Dashiva> | It prevents line breaking |
| 01:55 | <Dashiva> | <pre> gives meaning to the whitespace within it. <nobr> is just a formatting guideline. |
| 01:55 | <AryehGregor> | Then what does Maciej mean by "<nobr> should be considered just as semantic as <pre> or <br>, with a semantic of 'a block of text with preformatted line breaks.'"? |
| 01:55 | <AryehGregor> | It's not preformatted line breaks, it just doesn't have any line breaks. |
| 01:56 | <AryehGregor> | That does seem like CSS territory to me. |
| 01:56 | <AryehGregor> | <wbr> less so, because it's hard to see how you'd even implement such a feature in CSS -- it inherently requires a particular point to be flagged in the markup itself. |
| 01:57 | <Dashiva> | It's surely angels and pins territory, but to me <pre> is a clear step away from <br>, <wbr>, <nobr> |
| 01:58 | <AryehGregor> | Really? <br> and <wbr> seem like they have to be in HTML to me. <nobr> I agree with you on, more or less. |
| 01:58 | <Dashiva> | They have to be, but only because we can't express it any other way |
| 01:58 | <AryehGregor> | Well, eh. |
| 01:58 | <othermaciej> | AryehGregor: Sam Ruby has a bug open specifically about some particular examples of presentational table markup |
| 01:59 | <AryehGregor> | <nobr> really means "there are no line breaks here". |
| 01:59 | <AryehGregor> | othermaciej, oh, really? |
| 01:59 | <Dashiva> | <wbr> is sort of like ­ |
| 01:59 | <othermaciej> | let me see if I can find it |
| 01:59 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7468 |
| 01:59 | <Dashiva> | (only there's no hyphen involved, obviously) |
| 02:00 | <othermaciej> | I guess I described <nobr> incorrectly in my bug |
| 02:00 | <AryehGregor> | "This use case is handled by <style scoped> in HTML5." |
| 02:00 | <AryehGregor> | That's actually a good point. |
| 02:00 | <othermaciej> | AryehGregor: that's the one |
| 02:00 | <AryehGregor> | Once that's supported, the table markup could be easily replaced. |
| 02:00 | <Dashiva> | Well, zzz time, *poof* |
| 02:01 | <othermaciej> | I'm not sure I buy that argument |
| 02:01 | <othermaciej> | about <style scoped> |
| 02:01 | <othermaciej> | I guess it is more compact than putting a style= attribute on every cell, but it's probably still less compact than the presentational attributes |
| 02:01 | <othermaciej> | and it's not clear to me that the accessibility / media independence argument applies in this particular case |
| 02:03 | <mpilgrim> | ooh, if we added <nobr> and <wbr> to html5, ppk's compatibility tables could finally validate |
| 02:03 | <AryehGregor> | I think the real argument in favor of pushing for the use of CSS is consistency. There's never any actual difference between using presentational markup and equivalent inline CSS, but CSS is a much more powerful and general mechanism, and is the only styling mechanism to be supported going forward. A language that didn't include presentational markup beyond inline style would be much simpler. |
| 02:03 | <othermaciej> | mpilgrim: he uses those? |
| 02:03 | <AryehGregor> | I don't know whether that's a good enough reason to make them invalid, though, rather than obsolete but conforming. |
| 02:04 | <daedb> | http://www.quirksmode.org/oddsandends/wbr.html |
| 02:04 | <othermaciej> | I think whitespace treatment is something that is on the fine edge between semantics and presentation |
| 02:05 | <othermaciej> | sometimes, a particular whitespace treatment is really part of the information in the document, not just a matter of how you present it |
| 02:11 | <AryehGregor> | Poetry and computer code are standard examples of that. |
| 02:11 | <AryehGregor> | Although <pre> usually suffices for both, if you suppress the monotype font for poetry. |
| 02:32 | <Traveler7> | hi |
| 02:33 | <Traveler7> | What's correct <article><section><h1>Title</h1><p>Some content here</p></section> | <section><h1>Another title</h1></section></article> or <section><article><h1>Title</h1><p>Content</p></article></section> and so on. |
| 02:38 | <JonathanNeal> | hola |
| 02:40 | AryehGregor | commented on bug 7468 |
| 02:43 | <othermaciej> | why does the validator dislike this docype: |
| 02:43 | <othermaciej> | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd"; |
| 02:43 | <othermaciej> | > |
| 02:43 | <othermaciej> | is that the wrong URL for the DTD? |
| 02:51 | <AryehGregor> | Are you using html5.validator.nu or just validator.nu? |
| 02:51 | <AryehGregor> | I think only the former accepts obsolete-but-conforming doctypes, for some reason. |
| 03:02 | <Traveler1> | hi |
| 03:08 | <AryehGregor> | othermaciej et al.: I just filed a bug "Many, most, or all obsolete features should be conforming". http://www.w3.org/Bugs/Public/show_bug.cgi?id=9355 |
| 03:10 | <othermaciej> | AryehGregor: I would recommend filing bugs that are narrower in scope than that |
| 03:10 | <AryehGregor> | Really? Why? |
| 03:10 | <AryehGregor> | I give clear reasoning that applies to *all* obsolete features. |
| 03:10 | <AryehGregor> | I.e., I argue that features should not be non-conforming merely because they're obsolete. The same logic applies to nearly all features that are non-conforming because they're obsolete. |
| 03:10 | <AryehGregor> | I don't see how I would be able to narrow the bug. |
| 03:11 | <othermaciej> | None of the features that are non-conforming "merely because they're obsolete" |
| 03:11 | <AryehGregor> | Really? |
| 03:11 | <AryehGregor> | It looks like they are to me. |
| 03:11 | <othermaciej> | obsolete is a specific subcategory of "non-conforming" |
| 03:11 | <othermaciej> | it is not a justification, it is a label |
| 03:11 | <othermaciej> | the rationale for things being noncomforming is in the new section Hixie just added |
| 03:12 | <AryehGregor> | Where? |
| 03:12 | <AryehGregor> | Maybe I missed it. |
| 03:12 | <AryehGregor> | The various features are listed as being obsolete, and the only hint as to why is that alternative markup is suggested. |
| 03:12 | <AryehGregor> | I mean, as non-conforming. |
| 03:12 | <othermaciej> | hang on, waiting for spec to load |
| 03:13 | <othermaciej> | it used to be there was no in-sepc rationale that said why those things are nonconforming |
| 03:13 | <othermaciej> | *in-spec |
| 03:13 | <AryehGregor> | The implication (to me) is that the only reason they're non-conforming is because these other features exist, which are in most cases exactly equivalent but are considered better for various reasons. |
| 03:13 | <AryehGregor> | They can't actually be very much better if they're functionally identical, of course. |
| 03:30 | <AryehGregor> | Okay, well, I'm going to bed. If you have specific suggestions for how I should split up the bug or any further points that I should address, othermaciej, feel free to ping me to tell me of them. |
| 03:30 | <othermaciej> | hang on |
| 03:30 | <othermaciej> | my computer was hosed |
| 03:30 | <othermaciej> | read this: http://dev.w3.org/html5/spec/Overview.html#conformance-requirements-for-authors |
| 03:30 | <othermaciej> | AryehGregor: ^ |
| 03:31 | <AryehGregor> | Aha. |
| 03:31 | <othermaciej> | that states many individual reasons for particular author conformance requirements |
| 03:31 | <othermaciej> | none of the justifications amounts to "is obsolete" |
| 03:31 | <othermaciej> | you may disagree with some of them, or you may feel some things marked obsolete and nonconforming when none of those criteria apply |
| 03:32 | <AryehGregor> | I didn't know about that. |
| 03:32 | <othermaciej> | yeah, it's new |
| 03:32 | <AryehGregor> | I'll look it over and amend the bug report accordingly, when I have time. |
| 03:32 | <othermaciej> | Hixie added that in response to bug 7034 |
| 03:32 | <othermaciej> | I think your bug is arguably just a duplicate of bug 7034 |
| 03:32 | <othermaciej> | (which is titled "remove or replace author conformance requirements") |
| 03:33 | <othermaciej> | I guess it is slightly less narrow in that it's limited to the obsolete section |
| 03:33 | <AryehGregor> | No, I only argue for removing a subset of them. |
| 03:33 | <othermaciej> | but that's kind of arbitrary |
| 03:33 | <AryehGregor> | There are lots of author conformance requirements that I think are a good idea. |
| 03:33 | <AryehGregor> | For instance, they can help to catch authoring mistakes. |
| 03:33 | <othermaciej> | note that not everything in the obsolete section is even presentational, though much of your argument is about presentational markups pecifically |
| 03:33 | <AryehGregor> | Or inform authors of areas where they might be running into interoperability problems, or pressure authors to do something that we have good reason to want them to do (e.g., alt=""). |
| 03:34 | <AryehGregor> | Thus the many/most/all in the bug summary. |
| 03:34 | <AryehGregor> | Much of it applies to all of them, I think. |
| 03:35 | <AryehGregor> | It looks like the justification for presentational markup offers no arguments that couldn't equally apply to style="". |
| 03:35 | <othermaciej> | that's why it gives a specific reason for exempting style="" |
| 03:35 | <othermaciej> | which you may or may not agree with |
| 03:35 | <othermaciej> | anyway |
| 03:35 | <othermaciej> | I think a bug about just presentational markup might make sense |
| 03:35 | <AryehGregor> | Maybe I'll repurpose it. |
| 03:35 | <othermaciej> | I don't see how your argument applies to, say, <bgsound> |
| 03:35 | <othermaciej> | or <applet> |
| 03:36 | <othermaciej> | or <frameset> |
| 03:36 | <AryehGregor> | I don't know what the first two do, really. |
| 03:36 | <othermaciej> | but if you make the bug be about that, then I suggest you should address Ian's argument in the rationale |
| 03:36 | <othermaciej> | well if you don't know what they do, you probably don't have enough info to suggest they should be conforming :-) |
| 03:36 | <AryehGregor> | <frameset> is something that's banned because it's considered to be something authors should almost never do, because it has serious problems, although they might be tempted to do it. |
| 03:36 | <AryehGregor> | Which is why I didn't say all obsolete features should be conforming. |
| 03:37 | <othermaciej> | if you say many/most/all, then you are asking someone else to guess what you mean |
| 03:38 | <othermaciej> | all I'm saying is, make it clear enough that no one has to guess which ones you have in mind |
| 03:38 | <AryehGregor> | I guess I can present a narrow argument, and he can extend it to everything else it applies to if he likes. |
| 03:39 | <othermaciej> | well, even "presentational" is a fairly clear category, though there may be edge cases that are hard to judge |
| 03:40 | <othermaciej> | most obsolete nonconforming features are that way for reason of being presentational it seems, but there are quite a few exceptions which generally have an independent and plausible reason to be banned |
| 03:41 | <othermaciej> | anyway, this is mainly my advice on how to make a good bug report - if you choose to do nothing, then the project won't blow up or anything, but |
| 03:41 | <othermaciej> | I think some revision would be wise |
| 03:41 | <othermaciej> | anyway, I won't keep you up any longer |
| 03:51 | <AryehGregor> | othermaciej, okay, how's this? <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9355>; |
| 03:51 | <AryehGregor> | (now I'm really going to bed, won't see your response till tomorrow) |
| 04:35 | <JonathanNeal> | Hello |
| 05:24 | <lazni> | has anyone diffed DOMs using html5lib? |
| 05:31 | <lazni> | there's a firefox extension, which would use html5.enabled |
| 05:45 | <lazni> | ah, SAX output, that would reduce the load of comparing |
| 07:07 | <othermaciej> | AryehGregor: looks more focused to me |
| 08:36 | <JonathanNeal> | TabAtkins, if you read this message when you come back, I have new IE json stylesheets for you. |
| 10:55 | <jgraham> | AFAICT there is no difference between "obsolete but conforming" and "transitional" |
| 10:59 | <othermaciej> | jgraham: in plain english meaning - perhaps not |
| 10:59 | <othermaciej> | jgraham: operationally - seems like a fair bit of difference between "mandatory non-error warning" and "you can choose to make all of them errors or all of them silent with a flag inside the document" |
| 11:00 | <othermaciej> | from the developer perspective, I like the warning better, if validators have the UI in non-default mode to selectively silence them or force them into errors based on category |
| 11:03 | <jgraham> | The difference between "Your document is valid but uses some obsolete features" and "Tour document is validates as HTML transitional" seems rather subtle to me. Presumably the majority of authors using transitional doctypes know that they are using obsolete features |
| 11:03 | <jgraham> | *Your |
| 11:08 | <othermaciej> | jgraham: the difference in overall wording is subtle, but getting the specific list of uses of obsolete features is a big practical difference |
| 11:09 | <othermaciej> | (whether for good or ill, I don't know, though I tend to think for good) |
| 11:11 | <jgraham> | Yes, having the list presented is, I guess better |
| 11:13 | <othermaciej> | but hey, maybe calling them "transitional features" instead of "obsolete but conforming features" might be better branding |
| 11:14 | <jgraham> | If we really must have a list of "features you are allowed to use but validators must warn about", could be get rid of the oxymornic-sounding name, present them with a special obsolete marking, and just say "authors should not use obsolete features. Validators must warn when obsolete features are used" |
| 11:15 | <jgraham> | Although I think my preferred solution is still not to have that list |
| 11:15 | <othermaciej> | well, there's also obsolete features that are nonconforming and must result in an error |
| 11:15 | <othermaciej> | so you can't just use the unqualified term "obsolete" |
| 11:16 | <jgraham> | Yeah true |
| 11:16 | <jgraham> | They should be called this-is-a-bad-idea-and-you-don't-want-to-do-this-but-hey-experience-suggests-that-you-will-do-anyway features |
| 11:16 | <othermaciej> | I think that list and its status is on some level a compromise between Henri, who did not want to spam people with useless errors for markup that is in fact harmless, and Ian, who wanted to alert authors of new documents that there are certain effectively useless constructs which they should not bother with |
| 11:17 | <jgraham> | I thought it was mainly a result of the great accessibility wars |
| 11:17 | <jgraham> | But I could be misremembering |
| 11:17 | <othermaciej> | there is only one item in there on the basis of accessibility |
| 11:18 | <othermaciej> | I guess before that it was a list of "downplayed errors" |
| 11:18 | <jgraham> | Yes, that's what I recall |
| 11:18 | <othermaciej> | but the concept of "downplayed error" is silly |
| 11:18 | <jgraham> | Well so is "obsolete but conforming" |
| 11:18 | <othermaciej> | that too |
| 11:19 | <othermaciej> | my own suggestion was to just describe them in terms of the effect ('"validators must issue a warning when X") instead of as a conceptual category |
| 11:21 | <othermaciej> | yeah, other than summary, all the others seem to be more in the "waste of electrons" category |
| 11:22 | <othermaciej> | but there's only 6 things total in the "obsolete but conforming" category |
| 11:23 | <othermaciej> | which makes it seem like a waste to name it, especially when the name is confusing to so many peple |
| 11:23 | <othermaciej> | *people |
| 11:23 | <jgraham> | It seems like one possible future is that a lot more things end up as obsolete but conforming |
| 11:24 | <othermaciej> | could be |
| 11:24 | <othermaciej> | I think so far only Aryeh has outright advocated that path, but his particular proposal would indeed turn the category into "transitional" |
| 11:25 | <othermaciej> | it's kind of a lie to call it "transitional" if it's been over 10 years and the transition still hasn't happened... |
| 11:25 | <jgraham> | Indeed |
| 11:25 | <othermaciej> | anyway I am almost finished breaking down all the errors in the conformance error study |
| 11:26 | <othermaciej> | http://www.w3.org/html/wg/wiki/index.php?title=HTML5_Authoring_Conformance_Study |
| 11:26 | <othermaciej> | only ebay and nytimes remain to be typed in |
| 11:27 | <othermaciej> | it seems like unescaped & is the most common single error, by far |
| 11:28 | <othermaciej> | and after that I guess presentational markup |
| 11:28 | <othermaciej> | X-UA-Compatible is surprisingly common, but since it is anti-interoperability by design, it seems silly to make it conforming |
| 11:29 | <othermaciej> | there are surprisingly many sites with a stray close tag, also |
| 11:36 | <jgraham> | Not that surprising; it's almost always totally harmless, an easy error to make, and hard to spot |
| 11:39 | <othermaciej> | I think the main reason for stray close tag to be an error is that there are a lot of authoring mistakes that would show up that way (forgetting to close a tag at all near some that may implicitly close, wrong close tag, misnested tags, etc) |
| 12:16 | <Philip`> | Why is x-ua-compatible anti-interoperability, when including it makes pages work in *more* browsers than if it was not included? |
| 12:22 | <Philip`> | (It would be a problem if people used x-ua-compatible as a way to avoid having to write code that works in browsers that follow standards better, but in practice it seems more commonly used on sites that already have a standards-browser codepath plus an IE7 codepath and don't want to add an extra codepath for IE8 since it's too different from the existing ones) |
| 12:23 | <Philip`> | (so it's not causing any disadvantage to browsers that implement standards better than IE does) |
| 15:23 | <Dashiva> | "The absence of Theora (or Dirac) as baseline codec means that a good portion of user agents will likely omit Theora support" |
| 15:23 | <Dashiva> | If you accept that people will be wrong on the internet, is it preferale that they be wrong the same way even after being corrected, or that they come up with new ways to be wrong every time? |
| 16:17 | <JonathanNeal> | Goodmorning |
| 17:09 | <divya> | I have a question regarding the flow content as defined in HTML5 spec: http://www.w3.org/TR/html5/dom.html#flow-content |
| 17:11 | <divya> | the spec says "Most elements that are used in the body of documents and applications are categorized as flow content." but the pictorial representation seems to indicate the only way an element wont be a flow content is if it is meta data content (and somehow not be flow content). http://www.w3.org/TR/html5/images/content-venn.svg Is this right? |
| 17:12 | <divya> | or are there hard rules that can be used to define if an element is flow content or not (spec does not define one)? |
| 17:14 | <Dashiva> | Each element specifies which categories it is in |
| 17:16 | <divya> | Dashiva: can you elaborate? How does it specify? Is it because it belongs to the list of elements specified in the doc? |
| 17:16 | <Dashiva> | http://www.w3.org/TR/html5/semantics.html#the-hgroup-element |
| 17:16 | <Dashiva> | Categories: Flow content. Heading content. formatBlock candidate. |
| 17:17 | <divya> | Dashiva: got it. so there is no rule, except to refer to the doc to find out if an element is a flow element or not. |
| 17:18 | <paul_irish> | <source> probably isnt flow content |
| 17:19 | <divya> | neither is <legend> |
| 19:41 | <AryehGregor> | The irony of a page entitled "HTML5: Cross-Browser Best practices" being written in Silverlight is . . . a lot. http://live.visitmix.com/MIX10/Sessions/CL27 |
| 19:59 | <gsnedders> | jgraham: FYI, I was in Sweden yesterday and am today (just now, actually) back in St Andrews |
| 20:02 | <othermaciej> | AryehGregor: lol |
| 20:03 | <AryehGregor> | They do offer the same content on the right-hand side in three other proprietary formats, though! |
| 20:03 | <AryehGregor> | And one open patent-encumbered format. |
| 20:27 | <othermaciej> | the width and height attributes on span don't do anything, right? |
| 20:27 | <workmad3> | othermaciej: not unless you change it's display to block |
| 20:28 | <othermaciej> | workmad3: I'm asking about attributes, not CSS properties - I am thinking the attributes don't ever do anything (unlike <div>, where they map to css propertieS) |
| 20:28 | <workmad3> | ah right |
| 20:28 | <workmad3> | wasn't even aware that width and height were valid attributes on a <span> :) |
| 20:29 | <othermaciej> | they are not |
| 20:44 | AryehGregor | is mildly fascinated by which of the language links on the left side of http://en.wikipedia.org/wiki/HTML5 have a space in the article name and which don't |
| 20:44 | AryehGregor | wonders if there are any patterns |
| 20:50 | <Dashiva> | I doubt it |
| 22:11 | <zcorpan> | http://urbanlistening.wordpress.com/2010/03/28/projekktor-zwei-html5-video-player/ |
| 22:23 | <Dashiva> | The meta @keywords bug is quite verbose... |
| 22:24 | <Dashiva> | I don't really agree with the argument "content-producing parts of google use @keywords, this is proof google search uses @keywords" |
| 22:26 | <webben> | Yeah, that's bogus. |
| 22:27 | <webben> | "content-producing parts of google use @keywords, this suggests some Googlers think some search engine might use keywords" would work |
| 22:27 | <webben> | (where "might" can include future engines, of course) |
| 22:27 | <Dashiva> | Or just "content-producing parts of google use tools that think @keywords is useful" |
| 22:28 | <webben> | Mmm maybe. |
| 22:28 | <webben> | At Yahoo! we add keywords and that's definitely deliberate not an artefact of tools. |
| 22:31 | <Dashiva> | Besides, Google would have no trouble using @keywords for its own sites, since they would be known to be reliable |
| 22:33 | <AryehGregor> | Dashiva, I sure hope Google Search doesn't treat Google-hosted sites differently from any othrs. |
| 22:35 | <Dashiva> | AryehGregor: Not necessarily used for Google search |
| 22:37 | <TabAtkins> | Google has said explicitly that it does not pay attention to keywords. |
| 22:38 | <Philip`> | It could be mistaken, or lying |
| 22:40 | <deltab> | Google Web Search is not the only crawling Google does |
| 22:40 | <Hixie> | i'm not aware of anything we do that uses keywords |
| 22:41 | <AryehGregor> | Saying that doesn't violate your NDA or anything? |
| 22:43 | <Dashiva> | Everyone in #whatwg works for Google anyhow |
| 22:45 | <Hixie> | AryehGregor: it's part of my job to represent google on committees; part of that is determining what information i can say. |
| 22:45 | <AryehGregor> | Reasonable. |
| 22:46 | <AryehGregor> | Dashiva, no, they mostly seem to work for Opera as far as I can tell. |
| 22:46 | <AryehGregor> | Do we have chat statistics hanging around, of biggest talkers and such? It would be fun to do breakdown by employer. |
| 22:46 | <Philip`> | Opera is just a front for Google |
| 22:47 | <gsnedders> | AryehGregor: Heh. To such an extreme that in 2008 MikeSmith predicted that within five years I would be working for Opera :) |
| 22:47 | <Dashiva> | Mozilla too, obviously |
| 22:47 | <Philip`> | It helps them monopolise the web without everybody noticing |
| 22:47 | <Philip`> | AryehGregor: See /topic |
| 22:47 | <jgraham> | Actually Google is just a front for Opera |
| 22:48 | <gsnedders> | jgraham: Go to bed. |
| 22:48 | <gsnedders> | Oh, wait, you're not an hour ahead of the time here. |
| 22:48 | <gsnedders> | It's just the time is still Europe/Stockholm on my laptop :P |
| 22:48 | <jgraham> | gsnedders: I thought I was? Did the clocks not change there? |
| 22:48 | <Dashiva> | The clocks changed last night |
| 22:48 | <gsnedders> | jgraham: They did |
| 22:48 | <gsnedders> | jgraham: Just not an hour ahead of the time here on my laptop |
| 22:48 | <Dashiva> | Philip`: Apparently you're unpopular |
| 22:49 | <gsnedders> | Shit, Lachy's almost caught up with me in number of lines |
| 22:49 | <jgraham> | Anyway, like I was saying it's always the little harmless looking one that turns out to weild ultimate power |
| 22:49 | <Dashiva> | "Hixie's faithful follower, Philip`, didn't speak so much: 534519 words." |
| 22:49 | <Dashiva> | Clearly Philip` is also a Google shill |
| 22:49 | AryehGregor | realizes he has no idea who a bunch of the people here work for, but is pretty sure at least four of the top ten there are Opera |
| 22:50 | <gsnedders> | AryehGregor: Of the top ten, five work for Opera |
| 22:50 | <AryehGregor> | And does anyone else employ more than one? |
| 22:50 | <gsnedders> | No |
| 22:51 | <zcorpan> | opera hires all #whatwg regulars |
| 22:51 | <jgraham> | Google, Opera, PhD, Mozilla (contractor), Apple, Opera, Opera, Opera, Opera, W3C |
| 22:51 | <othermaciej> | Dashiva: we already added back meta keywords, not sure why we had a second bug about it |
| 22:51 | <Dashiva> | The mozillas appear further down |
| 22:51 | <gsnedders> | zcorpan: Were you here before or after you joined Opera? |
| 22:52 | <zcorpan> | gsnedders: before |
| 22:52 | <jgraham> | Dashiva: What do you do these days? |
| 22:52 | <gsnedders> | zcorpan: When did you join here? |
| 22:52 | <othermaciej> | btw http://www.w3.org/html/wg/wiki/index.php?title=HTML5_Authoring_Conformance_Study is pretty much finished |
| 22:52 | <zcorpan> | gsnedders: 2005 iirc |
| 22:52 | <gsnedders> | zcorpan: Oh, my memory is really diabolical. |
| 22:52 | <othermaciej> | there are lots of interesting patterns in the data left to be teased out though |
| 22:52 | <othermaciej> | I may try to do a count of which errors are the most common across sites |
| 22:53 | <Dashiva> | jgraham: I'm finishing my master's degree (for real this time). I start at Google this summer. |
| 22:53 | <othermaciej> | or more specifically which presentational markup gets used the most |
| 22:53 | <othermaciej> | bus I filed so far are here: http://www.w3.org/html/wg/wiki/index.php?title=HTML5_Authoring_Conformance_Study#Bugs_Filed_Against_Spec |
| 22:53 | <jgraham> | Dashiva: Oh, cool. Know what you're doing at Google? |
| 22:53 | <othermaciej> | (well, and bugs other people filed) |
| 22:53 | <Dashiva> | Front end stuff |
| 22:54 | <Philip`> | Dashiva: Only 534519? That's not even as many as War and Peace :-( |
| 22:55 | <Dashiva> | Don't worry, it's only been a few years. You still have time. |
| 22:55 | <Dashiva> | 2022, remember |
| 22:56 | jgraham | is worried that zcorpan has said almost as many more lines than him as the total number of lines from roc |
| 22:56 | <Dashiva> | Be worried about your own word count before worrying about others :P |
| 22:57 | <jgraham> | You misunderstand. I'm not worried for zcorpan's benefit |
| 22:57 | <roc> | I don't know what jgraham is worried about exactly, but there's nothing wrong with being terse |
| 22:58 | <gsnedders> | Ah, new snapshot with 2.5.24 |
| 22:59 | <jgraham> | "Worried" is maybe the wrong word. It just seems like an incomprehensibly large gap |
| 23:00 | <Dashiva> | Tell his manager, grab his spot on the rankings :P |
| 23:00 | <gsnedders> | Hmm, http://developers.slashdot.org/story/10/03/28/208210/Best-Way-To-Land-Entry-Level-Job |
| 23:00 | <gsnedders> | I guess I circumvented this whole get-a-job-after-graduating problem by not going to uni |
| 23:02 | <Dashiva> | I've been lucky enough to never need to |
| 23:02 | <gsnedders> | Never need to what? |
| 23:02 | <Dashiva> | Apply for a job from the outside |
| 23:03 | <gsnedders> | Ah. I technically did for Opera, with an application thrown together very quickly on the final day |
| 23:03 | <gsnedders> | (including whole CV and everything) |
| 23:04 | <gsnedders> | My interview, however, was more just like a random conversation. :D |
| 23:04 | <Hixie> | it is incredibly hard to get the a11y people to actually suggest alt text |
| 23:04 | <Dashiva> | I got my interview with Opera from hanging out and giving help on #javascript :) |
| 23:05 | <Hixie> | they're eager to tell you what advice is _wrong_, but try to get them to give you positive advice, and sheesh |
| 23:05 | <gsnedders> | Dashiva: I got mine from hanging out here :) |
| 23:06 | <AryehGregor> | I can probably get a job at Wikimedia because I was a volunteer developer for them for the last 3.5 years, so I also hopefully won't have to apply for a job anytime soon. |
| 23:06 | <AryehGregor> | (currently working on a Ph.D., though) |
| 23:06 | <Dashiva> | Hixie: If there's no perfect solution, any near-optimal solution will still have flaws, and nobody wants to suggest flawed advice. |
| 23:06 | <AryehGregor> | Not having to actually be part of the job market is great. \o/ |
| 23:07 | <Hixie> | Dashiva: well then why complain about the advice in the spec that admits that any solution will be flawed? |
| 23:07 | <Dashiva> | Because it isn't perfect |
| 23:09 | <Hixie> | so it's better to advise people to do something impossible, and thus guarantee that everyone will do it wrong, than advise people to do the best that is possible, thus at least making it possible for some people to get it as right as possible? |
| 23:10 | <Dashiva> | Protecting the image of perfection can be important to some people |
| 23:10 | <Dashiva> | Or less pointedly, the moment you admit perfection is impossible, it can seem like you're accepting mediocrity |
| 23:11 | <AryehGregor> | Hixie, surely most feed readers strip <style>? |
| 23:11 | AryehGregor | supposes he can test |
| 23:12 | <Dashiva> | Wasn't syndication one of the main use cases for <style scoped? |
| 23:12 | <AryehGregor> | I have no idea. |
| 23:13 | <jgraham> | My conclusion about feed readers is that I almost always want them to remove document styles and I don't trust authors to use the right markup in cases where the style is essential compared to cases where the style is ephemeral |
| 23:13 | <AryehGregor> | jgraham, so if the author includes a table with borders, should it remove the borders? |
| 23:14 | <zcorpan> | i'd like the same table style on all tables in feeds |
| 23:14 | <zcorpan> | but i almost never see any tables in feeds anyway |
| 23:14 | <jgraham> | I think typically it would be fine to display in the standard style for the feedreader |
| 23:14 | <zcorpan> | so can't be bothered to write a user style sheet |
| 23:14 | <AryehGregor> | Even when one table is used presentationally (borders wreck the layout) and one is used semantically (borders necessary to look good)? |
| 23:15 | <jgraham> | Do items in feeds typically have tables for layout? I don't recall ever seeing that |
| 23:15 | <AryehGregor> | I have to admit, I agree that it's nice they all look consistent. |
| 23:15 | <AryehGregor> | No, I can't think of any time I've seen that. |
| 23:15 | <AryehGregor> | Hmm. |
| 23:15 | <AryehGregor> | In practice, do feed readers usually strip styles . . . ? |
| 23:15 | <jgraham> | I guess |
| 23:16 | <AryehGregor> | Inline styles, I mean, obviously. |
| 23:16 | AryehGregor | tries to find a likely example |
| 23:17 | <AryehGregor> | Google Reader doesn't strip inline style. |
| 23:17 | <daedb_> | cia.vc has styles in their feeds |
| 23:17 | <AryehGregor> | It's so obviously necessaryt \ |
| 23:18 | <AryehGregor> | It's so obviously necessary for it to strip <style> that I'm not even going to test that, though. (Don't have a feed handy that I really control . . .) |
| 23:18 | <AryehGregor> | Yeah, the styles on cia.vc feeds are really noticeable. Quite annoying, honestly. |
| 23:19 | <webben> | Hixie: Seems to me that bug resolves around the question of text /equivalence/ versus identification and that Laura is asking for caption ("descriptive identification") in alt. |
| 23:22 | <webben> | Hixie: In particular, the bit quoted from the spec treats "alternative text" as equivalent, whereas the bit quoted from WCAG2 distinguishes "text alternative[s] that serve.. the equivalent purpose" from some superset of text alternatives. |
| 23:23 | <webben> | In WCAG2 "text alternative" pretty much just means "programmatically associated text": http://www.w3.org/TR/WCAG/#text-altdef |
| 23:24 | <webben> | I think the question needs to be whether inserting "descriptive identification" in @alt versus the other methods the spec mentions is useful or not. |
| 23:27 | <webben> | the bug's confused by the fact the webcam image actually contains textual information. |
| 23:31 | <Hixie> | webben: yeah i certainly agree that we should provide captions for these images, and that's what the spec suggests -- but it seems obvious that mixing captions and replacements is suboptimal |
| 23:32 | <Hixie> | webben: currently i'm just trying to get an accessibility expert to tell me what the alt="" text should be so that i can determine if it is a caption or not |
| 23:33 | <Dashiva> | othermaciej: The bugs you changed with "moved back to verified" comment seem to be only at resolved. |
| 23:33 | <webben> | Yep I get that. I think there's agreement in that ticket that providing programmatically associated captions is good, and the disagreement is about how to do so. |
| 23:35 | <webben> | From a WCAG1/2 Techniques perspective (and common practice I guess), @alt is already overloaded to mix caption and replacement. |
| 23:37 | <Hixie> | well wcag1/2 were written in a world where alt="" was required, so it makes sense they'd use that hammer for all their problems |
| 23:37 | <Hixie> | but we have the opportunity to think this out better now |
| 23:46 | <zcorpan> | wait why doesn't embed fire 'load'? |
