| 00:44 | <sicking> | Hixie: ping |
| 00:59 | <roc> | annevk2: <hr> and <input> has never been done through XBL |
| 00:59 | <roc> | well, <input> was as an experiment that never shipped |
| 01:33 | <othermaciej> | Lachy: are you about? |
| 03:00 | <boblet> | does anyone know what the deal is with http-equiv="X-UA-Compatible" in HTML5? not allowed b/c versioning? jury is out? other? |
| 03:24 | <mpilgrim> | if anyone had "2.5 hours" in the "how long will it take john foliot to lose his shit after we start discussing summary" pool, you're a winner! |
| 03:41 | <othermaciej> | I have reminded John that he signed off on the current draft text and encouraged him to dial down his rhetoric accordingly |
| 04:06 | <Hixie> | boblet: it's redundant, since all versions of browsers are required to act the same way. :-) |
| 04:07 | <boblet> | Hixie: heh, nice. Thanks for the answer |
| 04:14 | Hixie | blinks at jf's e-mail |
| 04:14 | <Hixie> | i thought what the spec said today was in fact jf's idea |
| 04:14 | <Hixie> | it's certainly not what i want the spec to say |
| 04:30 | <MikeSmithX> | Hixie: about r3852, if <span title=&> is now not a parse error, then title=&&> and ...title=&&&>, etc., are not either, right? |
| 04:32 | <Hixie> | title=&& never was, as far as i know, and title=&&> was only because of the >, which is now no longer an error case (never was, according to the syntax section) |
| 04:34 | <MikeSmithX> | OK |
| 06:36 | <hsivonen> | Philip`: regarding your email to rdf-in-xhtml-tf, I find it more disappointing that parties other than Google claimed that Google implements RDFa |
| 07:22 | <MikeSmithX> | hsivonen: patch - http://bugzilla.validator.nu/attachment.cgi?id=115 |
| 07:23 | <MikeSmithX> | for http://bugzilla.validator.nu/show_bug.cgi?id=653 |
| 07:24 | <MikeSmithX> | seems like a dead-simple change, but just want to make sure I didn't miss anything elsewhere |
| 07:45 | <hsivonen> | MikeSmith: looks good |
| 07:46 | <othermaciej> | hsivonen: what do you think of the PFWG idea of issuing a validator warning every time a <table> element is used (effectively)? |
| 07:48 | <hsivonen> | othermaciej: I think it doesn't make sense to issue a warning on every table especially if the PFWG position is along the lines that summary isn't always necessary but the feature must remain for use when the table is confusing enough to need it |
| 07:49 | <hsivonen> | othermaciej: as an aside, I haven't fully reviewed the proposed text yet, but I noticed that one of the sample summaries contains data that any screen reader that doesn't suck should be able to voice from the table model given headers marked up as <th> |
| 07:50 | <hsivonen> | suggesting that authors include such text because AT vendors don't get their act together seems to get Priority of Constituencies the wrong way |
| 07:50 | <othermaciej> | hsivonen: Cynthia's comments about autogenerated summary seem to be related |
| 07:51 | <Philip`> | hsivonen: Those people didn't have any way to verify Google's claims (until now), so it doesn't seem unreasonable for them to have assumed Google did something sane |
| 07:52 | <hsivonen> | Philip`: maybe my default assumption in the absence of evidence to contrary was correct but more cynical than other people's |
| 07:53 | <othermaciej> | it seems to me that if we want to consider autogenerated summary, it's much better for the UA/AT side to generate it, than the authoring tool side |
| 07:53 | <hsivonen> | othermaciej: indeed |
| 07:53 | <othermaciej> | hsivonen: anyway - would be good to have some level-headed mailing list feedback on this once you have reviewed the proposal enough |
| 07:54 | <hsivonen> | othermaciej: ok |
| 07:54 | <hsivonen> | Philip`: note that I don't mean to disparage Google in any way. That's just my default assumption about *any* even vaguely Namespace-related software--that I assume it's not correct until shown correct |
| 07:56 | <Philip`> | hsivonen: It seems reasonable to assume they'll have a few bugs, but it also seems reasonable to assume they'll have at least attempted to do something basically correct and not just totally ignored the whole specification |
| 07:56 | <hsivonen> | Philip`: fair enough |
| 07:57 | <hsivonen> | Philip`: indeed, I didn't expect the deviation from the spec to be as great as you have shown |
| 07:57 | <Philip`> | It seems kind of like whoever designed Google's RDFa support just read the RDFa Primer and didn't bother with the proper spec or with understanding RDF or namespaces at all |
| 07:57 | <othermaciej> | so they implemented RegexpDFa? |
| 07:58 | <hsivonen> | Philip`: it's also possible that whoever designed it understood it and deemed the specced approach too complex |
| 07:58 | Philip` | doesn't mean to be personally offensive to whoever designed or implemented it, but maybe he does because it seems pretty rubbish :-p |
| 08:01 | <Philip`> | hsivonen: Too complex to implement, or too complex to author? |
| 08:01 | <othermaciej> | the nested types bug is surprising |
| 08:01 | <othermaciej> | er, nested properties |
| 08:02 | <hsivonen> | Philip`: to author, because I'd assume Google can get software implemented |
| 08:03 | <Philip`> | othermaciej: Doesn't seem too surprising giving that they seemingly don't support @datatype, and in the absence of @datatype RDFa says you shouldn't recurse into property elements (they should just be treated as XMLLiterals instead) |
| 08:04 | <othermaciej> | Philip`: I see |
| 08:04 | <hsivonen> | Philip`: whoa! does RDFa default to XMLLiterals as opposed to plain strings for property values? |
| 08:04 | <Philip`> | (You have to use datatype="" to stop that XMLLiteral behaviour) |
| 08:04 | <hsivonen> | interesting! |
| 08:04 | <Philip`> | hsivonen: Yes, though I think they're thinking of changing that in RDFa 1.1 |
| 08:05 | <Philip`> | (Well, it defaults to XMLLiterals if there are any element children - if it's just text then it's an untyped string literal) |
| 08:05 | <hsivonen> | (I guess this reveals that I've never taken the time to be exhaustive in review of RDFa) |
| 08:05 | <hsivonen> | (I've stopped at earlier issues) |
| 08:06 | <hsivonen> | Philip`: ok. that's reasonable in a way |
| 08:06 | <Philip`> | hsivonen: If they wanted to make it easier to author, it seems there would be far better ways of doing that in a way that's still largely compatible with RDFa, e.g. do all the proper CURIE processing but then have a special hack for values with an undeclared prefix "v" or something |
| 08:07 | <hsivonen> | Philip`: good point |
| 08:08 | <Philip`> | What's the longest it should take for a message to reach a W3C list (if the author's never posted before and it does the slow authorisation stuff)? |
| 08:12 | <hsivonen> | why does the spec suggest a weird Mood–Grade table? |
| 08:12 | <hsivonen> | wouldn't the best way of making it accessible be making it non-weird? |
| 08:12 | hsivonen | is rather surprised to find the Mood–Grade in the main spec |
| 08:16 | <othermaciej> | what's Mood-Grade? |
| 08:16 | <hsivonen> | othermaciej: see http://www.whatwg.org/specs/web-apps/current-work/#the-table-element |
| 08:16 | <hsivonen> | othermaciej: search string "For instance, the following table:" |
| 08:17 | <jgraham_> | hsivonen: I think Hixie wanted a short but odd table |
| 08:17 | <jgraham_> | I agree it sucks though |
| 08:18 | <othermaciej> | that is a weird table |
| 08:18 | hsivonen | has trouble locating validator-sensitive text in the draft Cynthia posted |
| 08:19 | jgraham_ | is disappointed but not too surprised that PFWG have retreated away from the compromise in the spec to something rather close to their originl position |
| 08:20 | <Hixie> | hsivonen: i needed a table that had table headers in the middle or that was otherwise not something that a brief scan of the table would show to be a simple table to understand |
| 08:20 | <othermaciej> | hsivonen: http://dev.w3.org/html5/pf-summary/Overview.html#guidance-for-conformance-checkers-0 |
| 08:21 | <Hixie> | hsivonen: if you have any better suggestions for a table that really needs summary, let me know |
| 08:22 | <hsivonen> | othermaciej: ooh. Thanks. |
| 09:19 | <othermaciej> | what are the existing extensibility mechanisms in HTML5? ones I can think of: class, rel, meta, XML namespaces in XML syntax, data- attributes, "other applicable specifications" clause |
| 09:19 | <othermaciej> | did I miss any? |
| 09:19 | <jgraham_> | microdata? |
| 09:20 | <Hixie> | othermaciej: the faq has a whole bunch of them |
| 09:20 | <Hixie> | http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21 |
| 09:20 | <othermaciej> | jgraham_: duh! |
| 09:20 | <othermaciej> | Hixie: thanks |
| 09:22 | othermaciej | mulls over <script type="">, plugins, and extending APIs via JavaScript |
| 09:22 | jgraham_ | thought that script libraries altering prototypes was considered bad form |
| 09:23 | <othermaciej> | I think I will stick to markup-level extensibility in what I'm writing for the most part |
| 09:24 | <annevk2> | roc, I meant the <hr> and <input> that are displayed when you use <isindex> |
| 09:24 | <othermaciej> | wasn't there a third registry besides meta and rel extensions? |
| 09:24 | <hsivonen> | othermaciej: do you have an opinion on the idea of allowing reverse-DNS identifiers in element name as an extension mechanism? |
| 09:25 | <Hixie> | othermaciej: http-equiv |
| 09:25 | <othermaciej> | hsivonen: mixed feelings |
| 09:26 | <othermaciej> | hsivonen: on the plus side... something that's clearly a prefix-based convention is likely be better than using XML-style namespaces |
| 09:28 | <othermaciej> | hsivonen: on the minus side... (a) reverse-DNS might be needlessly verbose compared to a registry system for prefixes; and (b) any system that decorates the name would be tempting to use for proprietary UA extensions but is totally unsuitable for such |
| 09:29 | <othermaciej> | (I say (b) because if a UA extension with a prefixey name becomes popular, then the spec may have to enshrine it with the funny name, thus violating the sanctity of the namespacing mechanism) |
| 09:29 | <hsivonen> | <com.netscape.blink>, <com.microsoft.marquee> |
| 09:29 | <hsivonen> | othermaciej: true, <com.apple.canvas> would have sucked big time |
| 09:29 | <Hixie> | com.netscape.table |
| 09:29 | <Hixie> | com.netscape.img |
| 09:30 | <Hixie> | actually com.mcom.img |
| 09:30 | <othermaciej> | that's different from CSS properties or APIs with a prefix, where it's somewhat practical to consider the possibility of multiple names |
| 09:30 | <othermaciej> | that might even be true for markup attributes |
| 09:30 | <hsivonen> | Hixie: were those purely unilateral or were there drafts for those under discussion at the time? |
| 09:30 | <othermaciej> | but not really for tag names |
| 09:30 | <Hixie> | hsivonen: img was unilateral, pretty sure table was too |
| 09:31 | <hsivonen> | Hixie: I thought <table> had a I-D going for it |
| 09:31 | <Hixie> | maybe |
| 09:31 | <Hixie> | <com.netscape.embed> |
| 09:32 | <Hixie> | <com.netscape.keygen> |
| 09:32 | <hsivonen> | Hixie: microdata and Namespaces have the same problem |
| 09:32 | <hsivonen> | anything that bakes a domain name in the identifier does |
| 09:32 | <Hixie> | microdata's naming problem isn't set in stone yet and i doubt we'll use what's in the spec now |
| 09:32 | <Hixie> | not sure what we'll use |
| 09:33 | <Hixie> | btw, using reverse dns tag names for extending the vocabulary for small-scale use (the usual reason people want this) is even worse than the browser unilateral extensions |
| 09:33 | <Hixie> | because it means you have no fallback for non-supporting UAs |
| 09:33 | <Hixie> | which is why class="" and data-*="" are the right solution |
| 09:34 | <Hixie> | but i've said this lots of times already |
| 09:35 | <hsivonen> | maybe we should have an ext attribute that is like class except it's new so it's better |
| 09:35 | <Hixie> | we could call it role=""! |
| 09:35 | jgraham_ | doesn't see how fallback is related to the use of reverse dns |
| 09:36 | <Hixie> | it's not |
| 09:36 | <Hixie> | any mechanism that affects the tag name part is equally bad |
| 09:37 | <Hixie> | the point is that <cite class="book"> is better than <ext:book> or <com.example.book> (or <book> before being in a spec) |
| 09:38 | <jgraham_> | Oh, I thought you were saying it was bad in microdata for some reason |
| 09:38 | <Hixie> | oh no the fallback issue is unrelated to the microdata issue |
| 09:39 | <Hixie> | the microdata issue is that we want to have property names that are short, but want to allow vocabulary mixing |
| 09:39 | <hsivonen> | Hixie: btw, what's happing with the viewport meta state? If both iPhone and Fennec support it, it's a bit pointless to pretend it's not conforming |
| 09:39 | <Hixie> | which basically means requiring a registry for each vocabulary |
| 09:39 | <Hixie> | hsivonen: i guess someone should add it to the registry |
| 09:40 | <othermaciej> | does Fennec do the same thing with it that iPhone does? |
| 09:40 | <othermaciej> | (I'm not actually sure offhand what MobileSafari does with it) |
| 09:41 | <hsivonen> | othermaciej: I'm not sure. I just assumed the idea is to do the right thing with content that's already authored with awareness of MobileSafari |
| 09:41 | <Hixie> | i think safari uses it to define the dimensions of the ICB or something like that |
| 09:41 | <Philip`> | The fallback thing indicates a need to lets documents declare subclass relationships between elements |
| 09:41 | <Hixie> | or to define the dimensions of the viewport, and then it uses something that isn't the viewport to render the page or something like that |
| 09:41 | <hsivonen> | Philip`: we could use RDF for that |
| 09:41 | <Hixie> | Philip`: we could use an attribute called "class" to indicate that |
| 09:41 | <jgraham_> | Philip`: Using RDF boondoggles perhaps? |
| 09:41 | <Philip`> | e.g. use @profile to point to a thing that says com.example.book is a subclass of cite |
| 09:42 | <Hixie> | ok, i was being serious, i dunno about you three |
| 09:42 | <Hixie> | :-P |
| 09:42 | <Philip`> | and once that extensibility mechanism is deployed, it'll be much easier to extend the language |
| 09:42 | Philip` | is always serious |
| 09:42 | <othermaciej> | right, MobileSafari's zooming/panning is modeled as something other than scrolling, and thus it does not affect the CSS viewport |
| 09:47 | <Hixie> | huh |
| 09:48 | annevk2 | notices lots of emails with the word "summary" in his inbox |
| 09:48 | <Hixie> | Jeremy suggsts using <details> <dt> ... <dd> ... </details> instead of <details> <legend> ... </legend> ... </details> |
| 09:48 | <Hixie> | that's not a bad idea |
| 09:49 | <othermaciej> | it's an intriguing idea |
| 09:50 | <othermaciej> | big plus: avoids the <legend> parsing issue without adding elements |
| 09:50 | <Hixie> | yeah |
| 09:51 | <annevk2> | and gives you a separate container for the contents of <details> making styling easier |
| 09:52 | <othermaciej> | I was thinking the <dd> seems unnecessary, but that's a good point about styling |
| 09:52 | <hsivonen> | what about applying the pattern to <figure>, too? |
| 09:52 | <othermaciej> | then we'd have to rename <figure> to start with "d" |
| 09:52 | <othermaciej> | <diagram>? |
| 09:52 | <annevk2> | digure |
| 09:53 | <hsivonen> | <figure><dd><img ...></dd><dt>caption here</dt></figure> |
| 09:53 | <Hixie> | i really don't see why y'all are so worried about either <details> or <figure>, to be honest |
| 09:53 | <hsivonen> | othermaciej: I don't think it follows that figure needs renaming |
| 09:54 | <annevk2> | Hixie, I was somewhat convinced with the argument that if authors cannot use it for the next decade because of IE it's not really better than XHTML 2.0 |
| 09:54 | <annevk2> | though not entirely |
| 09:54 | <othermaciej> | Hixie: I don't think waiting a decade for them to be usable is a good tradeoff for avoiding creation of new elements |
| 09:54 | <hsivonen> | Hixie: I think you should take the worry as demand data just like popular class names. |
| 09:54 | <hsivonen> | Hixie: also, what annevk2 said about XHTML2 applies |
| 09:55 | <othermaciej> | Hixie: it's even more not a good tradeoff for using one existing element with a somewhat semantically appropriate name vs. another with a slightly less on-point name |
| 09:55 | <Hixie> | i guess i don't understand the demand |
| 09:55 | <Hixie> | i mean, sure, they're neat and all |
| 09:55 | <Hixie> | but they don't add much |
| 09:56 | <Philip`> | Presumably the features exist in the spec because people want to use them, and so it's not surprising that people are unhappy when they find they can't use them |
| 09:56 | <othermaciej> | especially since <caption> and <label> are arguably both more semantically appropriate than <legend> but can't be used due to technical difficulties |
| 09:56 | <hsivonen> | Hixie: everyone who has had to develop containers for a floating img+caption pair wants a <figure> they can use yesterday |
| 09:57 | <othermaciej> | the Cocoa equivalent of <details> is used all over Mac OS X UI |
| 09:57 | <othermaciej> | it's a great component for a UI toolbox |
| 09:58 | <Lachy> | I liked the idea of using <details> with <dt> and <dd>, though I'm also concerned about the compatibility issues that would be caused if authors started using it now before browser implementations are ready |
| 09:58 | <othermaciej> | it would be hard for script to make one as polished as a native implementation |
| 09:58 | <othermaciej> | if <details> didn't use <legend> it would get some native browser implementations a lot sooner |
| 09:58 | <Hixie> | othermaciej: why? |
| 09:58 | <Hixie> | Lachy: yeah, that's actually an argument for keeping <legend>, as far as i can tell |
| 09:59 | <othermaciej> | Hixie: is the "why?" regarding my last statement? |
| 09:59 | <Hixie> | yeah |
| 09:59 | <Hixie> | seems like fixing the <legend> bugs is easy |
| 09:59 | <Hixie> | at least compared to the magic involved in <details> |
| 09:59 | <Hixie> | maybe not for <figure> |
| 09:59 | <othermaciej> | for Safari/WebKit development, we prioritize implementing features that Web developers can actually use, preferably before IE6 disappears from the market |
| 09:59 | <Lachy> | the functionality provided though, such as the hiding/showing, and the rendering of +/- expander controls could interfere with sites using it before implementations ship |
| 10:00 | <Hixie> | othermaciej: they won't be able to use <details> before then anyway |
| 10:00 | <hsivonen> | maybe making V.nu whine about <details> would be better than using <legend> |
| 10:00 | <othermaciej> | so it's basically not on our roadmap right now until the <legend> landscape changes (though we do intend to do something about <legend> parsing soonish) |
| 10:01 | <othermaciej> | Hixie: unless they do some script-based fallback for non-supporting UAs |
| 10:02 | <othermaciej> | it seems easier to fake <details> with script than <canvas>, and the latter has been done to some rough degree of quality |
| 10:03 | <othermaciej> | hsivonen: the <dt>/<dd> pattern even for containers that don't start with "d" is growing on me |
| 10:03 | <othermaciej> | it kind of makes sense to generalize them as a label/item pair for different contexts |
| 10:04 | <Hixie> | i think i might add other <dx> elements to the parser even before we define such an element, btw |
| 10:04 | <Hixie> | to make future introduction of such an element easier |
| 10:04 | <Hixie> | especially if we start using <dt> everywhere |
| 10:04 | <othermaciej> | that seems wise |
| 10:05 | <jgraham_> | Faking <details> really isn't that hard, so there seems no reason not to use it now if it isn't broken at the parser level |
| 10:05 | <Lachy> | Hixie, what would <dx> mean? |
| 10:05 | Philip` | finds the problem with dt/dd is remembering which order they go in |
| 10:05 | <Hixie> | Lachy: <ds> has been suggested for stage directions in <dialog> |
| 10:05 | <Philip`> | (At least I can understand it as term/definition for <dl>, but that wouldn't help in any other contexts) |
| 10:05 | <Hixie> | Lachy: dunno what other elements we might introduce, off-hand |
| 10:05 | <hsivonen> | Hixie: Instead of adding more stuff for <dialog>, <dialog> should go the way of <bb> and <datagrid> |
| 10:06 | <jgraham_> | I am more worried about the effect othermaciej mentioned (where implementors continually consider something low priority becuase IE doesn't support it) than the "authors might accidentially poison the well" argument |
| 10:06 | <Hixie> | hsivonen: yeah that's possible too |
| 10:06 | <Hixie> | hsivonen: but might still be useful to have some elements we can introduce later that already parse well |
| 10:07 | <Lachy> | Hixie, it makes no sense to try and maintain the fiction that <dl> can't be used for dialogues |
| 10:07 | <Lachy> | and thus keeping <dialog> is pointless |
| 10:07 | <Hixie> | <dl> definitely can't be used for dialogs |
| 10:07 | <othermaciej> | jgraham_: it's not just "IE doesn't support it" but "no obvious way to patch around old (or slow-to-implement) browsers" |
| 10:07 | <Hixie> | it makes absolutely no sense to use <dl> for dialogs |
| 10:08 | <jgraham_> | othermaciej: Yes, I was imprecise |
| 10:08 | <Lachy> | Hixie, why? |
| 10:08 | <othermaciej> | IE doesn't support <video> but it's still totally valuable given the fallback capabilities |
| 10:08 | <othermaciej> | Lachy: does anyone actually use <dl> for marking up conversations? |
| 10:09 | <othermaciej> | I am not aware of examples |
| 10:09 | <Hixie> | Lachy: it'd be like using <ol> for a postal address |
| 10:09 | <Lachy> | off hand, I can only think of the example in the HTML4 spec that used it |
| 10:09 | <Hixie> | Lachy: it superficially has a similar structure, but the semantic is no match at all |
| 10:09 | <jgraham_> | (it doesn't seem such a stretch to say that a conversation is a set of name-value groups where each name is the name and each value is the spoken text) |
| 10:10 | <othermaciej> | Lachy: if the HTML4 spec example is the only use, then it sounds like it would be a fiction to say it *can* be used for dialogs |
| 10:10 | <Hixie> | "doesn't seem such a stretch" is how we know it's not the right solution |
| 10:10 | <Lachy> | Hixie, dl is nothing but a general purpose assoication list. Pretending it has more semantics than that isn't helpful |
| 10:10 | <Hixie> | you wouldn't need to say that if it wasn't a stretch |
| 10:10 | <Hixie> | Lachy: a conversation is not an association list. |
| 10:10 | hsivonen | wonders if semantics are a problem or a solution here |
| 10:10 | <Lachy> | othermaciej, in that case, I'd argue that basing the design of <dialog> on <dl> is bad design |
| 10:10 | <jgraham_> | Hixie: Not really. It is a "group of name-value data" |
| 10:11 | <Lachy> | Hixie, it associates a speaker with what they said |
| 10:11 | <Philip`> | Maybe someone should try to get actual data on how <dl> is used, rather than guessing |
| 10:11 | <Hixie> | jgraham_, Lachy: i really couldn't disagree more |
| 10:11 | <othermaciej> | I wouldn't use an association list to represent a conversation in the languages that support them |
| 10:12 | <othermaciej> | or any other form of map |
| 10:12 | <Hixie> | exactly |
| 10:12 | <Philip`> | othermaciej: In programming languages they're unordered and usually have unique keys, which is completely unlike <dl> |
| 10:12 | <jgraham_> | Hixie: I'm not arguing that I like it being used that way or anything. I'm just arguing that it is impossible to rule out from the current spec text |
| 10:12 | <othermaciej> | my understanding of <dl> is that as with <ul>, order is not important; only the name/value mapping is important |
| 10:12 | <othermaciej> | but in a conversation, the order is primary, and labels are secondary |
| 10:13 | <Hixie> | jgraham_: if you think a conversation is an "association list" or a "group of name-value data", then you need to get out more :-P |
| 10:13 | <Lachy> | Many people use cite and blockquote for conversations anyway |
| 10:13 | <othermaciej> | it would be easier to make sense of a conversation with only statements in order and no speaker labels, than to make sense of it with randomly ordered statements listed per speaker |
| 10:13 | <Lachy> | maybe we should just allow that |
| 10:14 | <jgraham_> | othermaciej: The spec says that order may be significant |
| 10:14 | <Hixie> | othermaciej: actually, <dl>'s order can be important -- e.g. some of the <dl>s in the spec are like switch statements |
| 10:14 | <Philip`> | othermaciej: That's just a matter of how you interpret the markup, which seems fundamentally different to association lists in programming languages where it's generally impossible to represent a meaningful order |
| 10:14 | <othermaciej> | but the opposite is true for an actual list of definitions |
| 10:14 | <annevk2> | othermaciej, note that Hixie often uses <dl>'s where the order is important |
| 10:14 | <othermaciej> | Philip`: Lisp has association lists which are in fact ordered (but where relying on the order is considered poor form) |
| 10:14 | <Lachy> | whether or not the order is relevant is entirely dependent on context. It can't be determined based on markup alone for a <dl> |
| 10:15 | <othermaciej> | I guess I am wrong about the philosophy of <dl> then |
| 10:15 | <Philip`> | (By "generally" what I mean is "in Perl and Python, because I don't know how they work in other languages" :-) ) |
| 10:15 | <jgraham_> | Hixie: specifically I think of the transcription of a conversation as an ordered set of key-value pairs where each key is the speaker (and possibly the timestamp) and each value is waht they said at that point |
| 10:15 | <othermaciej> | I believe the term "association list" comes from Lisp |
| 10:16 | <Philip`> | I thought everything in Computer Science came from Lisp |
| 10:16 | <othermaciej> | Java also has an ordered hashtable type |
| 10:16 | <jgraham_> | javascript has ordered Objects (although the spec doesn't quite endorse this) |
| 10:16 | <othermaciej> | but name lookup is considered primary, and indexing secondary |
| 10:16 | <Philip`> | I presume all these things still require keys to be unique |
| 10:16 | <Philip`> | unlike <dl> |
| 10:16 | <Hixie> | jgraham_: i don't think that even describes an irc log, let along any conversation |
| 10:16 | <othermaciej> | C++ has multimap with non-unique keys |
| 10:16 | <Hixie> | jgraham_: actions, joins, parts, netsplits, etc. |
| 10:17 | <othermaciej> | but it doesn't have ordering |
| 10:17 | <jgraham_> | Hixie: Those aren't strictly part of the conversation |
| 10:17 | <othermaciej> | in C++ STL data structures, you would represent a conversation as a vector<> of pair<>s of strings, not any associative type |
| 10:17 | <Hixie> | jgraham_: someone leaving the conversation is a pretty critical part of a conversation |
| 10:17 | <othermaciej> | likely also for any other programming language |
| 10:17 | Hixie | thinks that this is part of the conversation too |
| 10:18 | <jgraham_> | Hixie: Arguably it is part of the context not part of the actual conversation. |
| 10:18 | <Hixie> | it's part of whatever we're marking up |
| 10:18 | <othermaciej> | the speaker's name is not a key, it's a label |
| 10:18 | <othermaciej> | that is an important difference in data structure terms |
| 10:18 | <jgraham_> | It is possible that there is no demand for marking up context-free conversations but <dialog> doesn't work any better here than <dl> |
| 10:18 | <othermaciej> | a key is something by which you index |
| 10:18 | <othermaciej> | but you'd never index a conversation by speaker |
| 10:18 | <Philip`> | othermaciej: Seems like you'd have to use a vector<> of pair<>s of strings to represent the content of any <dl> too |
| 10:19 | <hsivonen> | http://adactio.com/journal/1607/ is disturbing |
| 10:19 | <Philip`> | so you'd be treating conversations the same as <dl>s |
| 10:19 | jgraham_ | notes that the spec uses "name" not "key" |
| 10:19 | <othermaciej> | are <dl> terms intended to be unique? |
| 10:19 | <Hixie> | jgraham_: <dialog> probably needs to go, yes |
| 10:19 | <Hixie> | othermaciej: the spec doesn't say so yet, but it probably should |
| 10:20 | <jgraham_> | Hixie: I think that is for the best |
| 10:20 | <hsivonen> | Hixie: so now empirical data shows that the definitions for section, article and details suck |
| 10:20 | <Philip`> | "I realise that it’s too small to be considered scientifically accurate" - not sure why he says that, since tens of data points are usually enough to be statistically significant |
| 10:21 | <hsivonen> | and curiously, hgroup seems to be the clearest of the lot |
| 10:21 | <othermaciej> | hsivonen: I would interpret the study as saying that the section, article and footer element names and/or definitions suck |
| 10:21 | <hsivonen> | othermaciej: fair enough |
| 10:21 | <Hixie> | i don't think the bits he quoted are necessarily the best bits to quote, but yeah, section vs article needs help, certainly |
| 10:21 | <Hixie> | someone mail me that url :-) |
| 10:22 | <Philip`> | Clearly the definitions should define themselves in terms of the name of the element, e.g. "<section> represents a section", and then people will find it harder to mix them up |
| 10:22 | <annevk2> | Hixie, at the end he says he'll post to the list |
| 10:22 | <hsivonen> | Hixie: mailed |
| 10:23 | <othermaciej> | given those quoted excerpts, I can see how people got <article> and <section> backwards |
| 10:23 | <Hixie> | thanks |
| 10:23 | <Hixie> | Philip`: yeah, that's kinda my point |
| 10:23 | <jgraham_> | The confusion between <article> and <section> seems to be the big takeaway from that |
| 10:23 | annevk2 | wouldn't be opposed against merging them |
| 10:24 | <hsivonen> | the biggest takeaway is to avoid the word "section" in the definition of <article> |
| 10:24 | <othermaciej> | good point - I wonder if the reversal would have been as common if it said "a part of a page" |
| 10:24 | <othermaciej> | instead of "a section of a page" |
| 10:24 | <jgraham_> | I think maybe it would be OK to postpone <article> to HTML6 once we have an idea of how people are using <section> |
| 10:25 | <othermaciej> | I bet it still would be though |
| 10:25 | <jgraham_> | since generally an <article> is-a <section> |
| 10:25 | <Hixie> | see, i think <article> is far more important than either <figure> or <details> :-) |
| 10:25 | <webben> | Maybe there needs to be a paragraph defining the difference between them. |
| 10:25 | <webben> | and the definition for each needs to refer back to that |
| 10:26 | <hsivonen> | Hixie: I think you have the importance of article and figure backwards |
| 10:27 | <Hixie> | i think you do :-) |
| 10:27 | <othermaciej> | I think the importance evaluation has to consider author desire to use the relevant element, and likelihood of using it correctly |
| 10:27 | jgraham_ | wonders why Hixie thinks <article> is so important |
| 10:27 | <othermaciej> | it seems like both are higher for <figure> than <article>, regardless of their importance in the world of Platonic ideals |
| 10:27 | Hixie | is changing <figure> and <details> to use <dt>/<dd>, and dropping <dialog> |
| 10:27 | <hsivonen> | woohoo! |
| 10:28 | othermaciej | wonders whether Tantek will be delighted or infuriated by that change |
| 10:28 | <Philip`> | The way I see it is that <details> does something useful, and <article> is just a semantic way of saying <div class=article>, and it's fun to be anti-semantic |
| 10:28 | <Hixie> | also, i hate you all. this is far more work than it's worth. :-P |
| 10:28 | <othermaciej> | hi Lachy! |
| 10:28 | <Lachy> | hi |
| 10:28 | <jgraham_> | :) |
| 10:29 | <othermaciej> | Lachy: may I prod you for an update on about: registration? any progress to report? should I push out the deadline? |
| 10:29 | <Hixie> | i think <article>/<section> are important because there's a key difference between a blog post and a section of a blog post, or a blog comment and a section on a web page |
| 10:29 | <jgraham_> | (as an aside the sparklines on that post work rather nicely) |
| 10:29 | <Hixie> | it's the difference between a chapter, and something that gets syndicated |
| 10:29 | <othermaciej> | jgraham_: I was also charmed by the sparklines |
| 10:29 | <Lachy> | othermaciej, the deadline was this thursday, wasn't it? |
| 10:30 | <Philip`> | jgraham_: I don't like how the sparklines ascribe significance to the arbitrary ordering of elements |
| 10:30 | <othermaciej> | Lachy: yes, it's this Thursday - just asking early |
| 10:30 | <Lachy> | I actually planned to look at that stuff today. I have a lot of feedback I need to send to Joseph about the latest draft |
| 10:31 | <Philip`> | It'd be less arbitrary if e.g. it ordered the values from highest to lowest in each sparkline |
| 10:31 | <hsivonen> | registering about: is more complex than I thought |
| 10:31 | <othermaciej> | Lachy: if you want to send an update by email, that's ok too, or I can ping you tomorrow, I was just assuming you probably wouldn't be at the telecon, so I wanted to make sure I'd have the data |
| 10:31 | <Lachy> | I'll make sure you have some info before the telcon |
| 10:31 | annevk2 | finds a page that uses about:legacy-compat: http://xopus.com/ |
| 10:32 | <othermaciej> | the potential flaw in the sparklines is that one could be really sharp and spikey while indicating 100% wrongness |
| 10:32 | <Philip`> | Hixie: That difference already seems clear enough in practice, because the something that gets syndicated is the something in the RSS feed |
| 10:33 | <othermaciej> | <article>/<section> make sense in the case of a blog but get kind of confusing (with respect to each other and possibly with respect to <div>) in other contexts |
| 10:33 | <Hixie> | othermaciej: yeah the right sparkline type for that data would be a series of red/black blocks (red for good answers, black for bad ones), or something like that |
| 10:34 | <jgraham_> | I guess dropping <article> makes the syndication-from-the-html thing harder |
| 10:34 | <Hixie> | <article>/<section> also make clear sense in a forum, on a site like iGoogle, on anything with a clear body of content like an eBay page, etc. |
| 10:35 | <jgraham_> | Hixie: I agree that there is a difference and to me it is clear. I am concerned that it is not clear enough to everyone else |
| 10:35 | <webben> | Hixie: I think recognizing messages as articles may be confusing for people actually. |
| 10:35 | <othermaciej> | I don't know how to use <article>/<section> in the context of apps, even though the spec says they can be used for that |
| 10:36 | <Lachy> | jgraham_, from the uses of <article> that I've seen, people seem to be getting it right. The only issue has been the misuse of <section> as a wrapper within articles |
| 10:36 | <othermaciej> | I admit I am a bit puzzled by the apparent confusing over <article>/<section> in the context of documents |
| 10:37 | <othermaciej> | eBay is appy enough that I wouldn't be sure how to apply article/section |
| 10:37 | <webben> | you can't use section to wrap sections inside articles? |
| 10:38 | <jgraham_> | webben: You can |
| 10:38 | <jgraham_> | If they are true subsections of the article |
| 10:38 | <webben> | Okay. (Good.) |
| 10:39 | <Lachy> | webben, yes, but people have been doing <article><header/><section/><footer/></article> where the section is nothing but a wrapper around the content |
| 10:39 | <webben> | ah I see. |
| 10:41 | <Hixie> | there are an UNGODLY number of <figure> examples in the spec |
| 10:41 | <Hixie> | not surprising everyone wants to use it |
| 10:41 | <Hixie> | i should put this many <menu> examples in |
| 10:41 | jgraham_ | wonders in which religions god has an opinion on the HTML5 spec |
| 10:44 | <Lachy> | jgraham_, that would be the god in Bible5 |
| 10:45 | <jgraham_> | I'm pretty sure Bible5 has no God on the basis of lack of scientific evidince for His existance |
| 10:46 | annevk2 | isn't really sure about <menu> 'cause of hyatt's multiple "rants" about it |
| 10:46 | <Philip`> | Shouldn't it equally have a God on the basis of lack of scientific evidence for His non-existence? |
| 10:46 | <Philip`> | Pave the cowpaths, and all that |
| 10:47 | <Hixie> | that doesn't scale |
| 10:47 | <Lachy> | Philip`, no |
| 10:47 | <Hixie> | and the cowpaths are contradictory |
| 10:47 | <Hixie> | also, specs should be written based on reality, not on previous specs (like the christian bible, in this case) |
| 10:47 | <othermaciej> | whether or not there is evidence for God, a lot of people are using him |
| 10:47 | <Philip`> | God is like xmlns |
| 10:47 | <Philip`> | Better to just accept him and carry on |
| 10:49 | <annevk2> | and make it a useless talisman in the process? |
| 10:49 | <othermaciej> | God is like violence. If he doesn't solve your problem, you're not using enough of him. |
| 10:49 | <Lachy> | haha |
| 10:49 | <Philip`> | annevk2: Sure, if it's enough to keep people happy |
| 10:51 | <Lachy> | the problems only start when people try to force their talismans upon others and attack others for rejecting it. |
| 10:55 | <othermaciej> | if only all you Tagsoupists converted to the true path of Slashianity, we wouldn't have this problem |
| 10:56 | <Philip`> | I'm sure we'd find something else to fight over instead |
| 10:56 | <Perceptes> | anyone around? |
| 10:57 | <Philip`> | Perceptes: Maybe |
| 10:57 | Perceptes | laughs. |
| 10:58 | <Philip`> | (It depends on whether you ask something that anyone feels like responding to) |
| 10:58 | <Perceptes> | I was hoping for some info on HTML 5 in IE. I ran into an issue I can't find any reference to on the web though it seems like it would be common. |
| 10:58 | <Philip`> | What issue is that? |
| 10:59 | <Perceptes> | I'm using Remy Sharp's html5shiv script, but when I insert HTML5 elements into the page later with jQuery, the elements are not styled. If I look at the newly inserted HTML in IE 8's built in developer toolbar, I can see that it's not correctly nesting the elements - it sees the opening and closing tags of each HTML5 element as two separate tags. |
| 11:00 | <Philip`> | I assume that's the http://code.google.com/p/html5shiv/source/browse/trunk/html5.js script? |
| 11:01 | <Perceptes> | that's the one. |
| 11:01 | <Philip`> | What elements are you using it with? |
| 11:01 | <Perceptes> | The ones that are being inserted and not styled are article, header, section, and time. |
| 11:01 | <Perceptes> | the latter three being children of a single article element. |
| 11:01 | <jgraham_> | Do you make sure the script runs before loading jQuery? |
| 11:02 | <Perceptes> | Yes, it's loaded before all other JS and CSS files. |
| 11:02 | <Philip`> | (That probably shouldn't matter, as long as the script runs before the parser reaches the new elements) |
| 11:03 | <Perceptes> | It only happens when injecting HTML5 elements with JS though, everything is styled correctly on initial page load, so I know the shiv script is working. |
| 11:03 | <jgraham_> | (Right but jQuery could be doing some clever caching or something so it seems worth checking) |
| 11:04 | <Philip`> | Oh, okay, I missed that you said they were inserted later |
| 11:04 | <annevk2> | might help if you show the page |
| 11:05 | <Philip`> | I expect inserting elements with createElement/appendChild should work, and inserting with innerHTML probably ought to work too (though I'm not sure), but I have no idea how jQuery tries to insert elements |
| 11:05 | <Perceptes> | it's not on a live server |
| 11:05 | <jgraham_> | Perceptes: If you take jQuery out of the loop, does it work if you do something like <script>document.body.innerHTML = "<section style='background-color:green;'>I should be a child of the section</section>"</script> |
| 11:06 | <Perceptes> | lemme try |
| 11:07 | <Perceptes> | yeah, that works |
| 11:08 | <Perceptes> | so either jQuery is the culprit or just the way I'm doing it isn't right. |
| 11:08 | <jgraham_> | Perceptes: can you make a minimal testcase that fails? |
| 11:09 | <Perceptes> | I'll see what I can come up with |
| 11:11 | Philip` | has had problems with things like jQuery selectors on new elements (<time> etc) in Opera |
| 11:12 | <jgraham_> | Philip`: Did you file a bug? |
| 11:12 | <Philip`> | Actually, maybe the problem was with doing node.is('time') |
| 11:12 | <Philip`> | so I replaced it with node[0].localName.toLowerCase() == 'time' |
| 11:13 | <Philip`> | jgraham_: No, I just hacked around the problem so I could get on with what I wanted to be working on |
| 11:13 | <jgraham_> | Philip`: Do you mind filing a bug? |
| 11:13 | <Philip`> | Oh, actually, node.is is jQuery selectors, I think |
| 11:13 | <Philip`> | jgraham_: Filing a bug on whom? |
| 11:14 | <Philip`> | Anyway, the answer is that I do mind a bit and probably wouldn't get around to doing it today |
| 11:14 | <jgraham_> | Opera I guess, if it works in other browsers. We can always file a bug on jQuery if they are doing something strage |
| 11:14 | <jgraham_> | Philip`: OK |
| 11:15 | <Philip`> | Filing bugs takes far more effort than just complaining on IRC |
| 11:15 | <annevk2> | Opera does casing different between unknown and known elements |
| 11:15 | Philip` | isn't sure if the last Opera bug he filed was even CC'd to anyone who will actually be interested in looking at it and getting it fixed |
| 11:16 | <annevk2> | what's your account? i can take a loop |
| 11:17 | <Philip`> | Hmm, I think the bug I'm thinking of was DSK-256463 |
| 11:17 | <Philip`> | but I don't know if it's still a bug in the latest version, and I can't test it since I don't have KDE3 any more |
| 11:21 | <annevk2> | oh, I cannot be of much help with that I'm afraid |
| 11:43 | <Hixie> | i now have a 3000 line diff |
| 11:43 | <Hixie> | that: |
| 11:43 | <Hixie> | drops <dialog> |
| 11:44 | <Hixie> | makes <figure> amd <details> use <dt>/<dd> instead of <legend> |
| 11:44 | <Hixie> | moves the stuff about tag clouds and footnotes into a section that also has something about conversations |
| 11:44 | <Hixie> | adds <dc> and <ds> to the parser speculatively for future expansion |
| 11:46 | <Lachy> | Hixie, what is <dc> reserved for? |
| 11:46 | <Hixie> | credits in <figure> |
| 11:47 | <Hixie> | i'll do a separate patch to move <legend> and <div> into other sections, since this is big enough alreayd |
| 11:47 | <annevk42> | sounds pretty good |
| 11:48 | <annevk42> | Hixie, you should add Jeremy Keith to the ack section too |
| 11:48 | <Hixie> | i recommend <p><b>speaker</b>: text</p> for conversations |
| 11:49 | <Hixie> | annevk42: thanks |
| 11:49 | <Hixie> | done |
| 11:50 | <Perceptes> | alright, I have a test case on the net if anyone I was talking to a few minutes ago is still on. |
| 11:52 | <Philip`> | Perceptes: It's probably best to just post the link in any case, because someone else might look at it or one of the people you were originally talking to might come back in a few hours and read the logs and see it :-) |
| 11:52 | <othermaciej> | this is interesting: http://www.techcrunch.com/2009/09/14/tc50-fluidhtml-wants-to-rewrite-the-web-with-flash-like-html/ |
| 11:52 | Philip` | is currently not here |
| 11:53 | <annevk42> | Hixie, in <details>' content model dd is not marked up with <code> |
| 11:53 | <Hixie> | fixed, thanks |
| 11:53 | <Perceptes> | well ok then! http://www.jimmycuadra.com/ie8/ is the link. I stubbed out the ajax, so just click the add comment button and it will insert a canned comment. try it in non-IE first so you see what it's supposed to do. the script it runs is at http://www.jimmycuadra.com/ie8/javascripts/comments.js and I added a comment in it that shows specifics on where it's breaking. |
| 11:57 | <Perceptes> | hmm, is time not supposed to be a block level element? |
| 11:57 | <Hixie> | nah it's phrasing-level |
| 11:57 | <Perceptes> | ok, that's something I need to fix then |
| 11:58 | <Perceptes> | not related to the issue above though |
| 11:58 | <jgraham_> | Perceptes: I don't really understand what your demo is supposed to do. I was really hoping for something like 5-10 lines long that printed "PASS" or "FAIL" as appropriate |
| 12:00 | <Perceptes> | jgraham_: it does three things: 1) adds a "1 comment" link to the bottom left corner of the blog entry 2) adds a section called "comments" above the comment form 3) adds the canned comment (in the real situation it's the comment you enter, obviously) to that new comments section |
| 12:01 | jgraham_ | will spend a few moments trying to reduce it further |
| 12:01 | <jgraham_> | (but not very many) |
| 12:01 | <Perceptes> | the part that's failing is that in step 2, it's inserting a section element which IE doesn't seem to parse correctly, so when the script tries to insert the comment into it, it throws an error |
| 12:02 | <Perceptes> | if I use a div instead of a section, then it inserts fine |
| 12:02 | <jgraham_> | Yeah, I see the failing code |
| 12:02 | <Perceptes> | but the comment itself (which uses article, header, and section) doesn't style |
| 12:02 | <Perceptes> | ok |
| 12:02 | <Perceptes> | I'll work on a version with all the stuff not specific to the failure stripped out |
| 12:04 | <Hixie> | oh i also made <dl> say that <dt> should be unique |
| 12:05 | <Hixie> | forgot to mention that in the checkin comment |
| 12:05 | <Hixie> | (it's just a "should") |
| 12:05 | <zcorpan> | Philip`: personally, i'd like related things to be on the same page in the multipage version. in particular i'd like video, audio and media elements to be in one page |
| 12:06 | <annevk42> | Hixie, for <dd> in contexts where it can be used you are specific for <dl> but not for the other two; i.e. for <figure> it can appear only once and for <details> it can appear only once, but only after a <dt> |
| 12:07 | <zcorpan> | Philip`: since e.g. things that invoke the resource selection algorithm is all over the place, it's nice to be able to search within the page |
| 12:07 | <Hixie> | annevk42: good point |
| 12:07 | <hsivonen> | Philip`: it would be great to have a static copy of the parser section stored somewhere immediately before you split the tokenization and tree building sections again |
| 12:07 | <Perceptes> | jgraham_: refresh for a super simplified HTML page |
| 12:07 | <hsivonen> | Philip`: if lynx --dump rewraps the lines, I'm in the world of hurt again |
| 12:08 | <hsivonen> | otherwise, I like having tokenization and tree building on separate pages in the multipage version |
| 12:08 | hsivonen | depends on lynx --dump for diffing those sections |
| 12:16 | <Lachy> | Hixie, in the footnotes example, why don't you use <sup> to make the footnote references superscripts, as they usually are in printed typography |
| 12:16 | <Hixie> | i was doing what wikipedia does |
| 12:16 | <Hixie> | but yeah, we could do that |
| 12:16 | <Hixie> | still with square brackets? |
| 12:16 | <Lachy> | wikipedia also uses <sup> |
| 12:16 | <jrib> | Hey, is there a reason html5lib/treebuilders/__init__.py and _base.py contain print statements? Is this just for debugging purposes during development? |
| 12:16 | <Hixie> | oh, i didn't notice |
| 12:16 | <Hixie> | ok cool, will do |
| 12:17 | <jrib> | (this is in python3) |
| 12:17 | <Hixie> | Lachy: reload in 25 seconds; is that better? |
| 12:18 | <Lachy> | the square brackets are just a wikipedia convention. i'm not sure of the reason behind it. It may be just to make the links slightly larger and easier to click. I've never seen them used in printed typography. |
| 12:19 | <Hixie> | i guess we're a new medium, we get to make our own conventions |
| 12:20 | <zcorpan> | Hixie: ugh. why change the parser before actually adding new elements? |
| 12:20 | <Hixie> | so that we can add them with significantly less pain in the future |
| 12:20 | <Hixie> | consider how easier our life would be if <legend> was parsed correctly today |
| 12:21 | <zcorpan> | if <legend> was treated as an unknown element, it would be fine |
| 12:21 | <Lachy> | Hixie, put the <a> within the <sup>, rather than the other way around |
| 12:21 | <Hixie> | Lachy: oh, yeah, underlining, oops |
| 12:21 | <Lachy> | see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/231 for why |
| 12:21 | <Lachy> | yeah |
| 12:21 | <jgraham_> | Perceptes: http://hoppipolla.co.uk/410/IE_jQuery.html |
| 12:22 | <remysharp> | On the legend note Hixie - can you clarify the "use dt/dd" comment here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7374 - is that in place of figure/details or in place of using legend? |
| 12:22 | <Creap> | http://html5.org/tools/web-apps-tracker?from=3858&to=3859 are dc/ds short for something, a typo or something I've never heard about |
| 12:22 | <Hixie> | zcorpan: ok, consider how much easier our life would be if <figure> had been a block-level element in the past |
| 12:22 | <annevk42> | Creap, they're speculative future extensions |
| 12:22 | <Hixie> | remysharp: <dt> replaces <legend> in <figure> and <details>; see the updated examples in the spec |
| 12:22 | <remysharp> | Hixie: ta. |
| 12:22 | <Creap> | ok |
| 12:23 | <Hixie> | Creap: <dc> for credits, probably, <ds> maybe for stage directions. Both are not really elements yet. |
| 12:23 | <Hixie> | Creap: (not sure how much of a good idea it is to add them before we know if we need them) |
| 12:23 | <Hixie> | Creap: (so they might not stay) |
| 12:23 | <Perceptes> | jgraham_: wow, even more stripped down then what I'm doing. D: Thank you! |
| 12:23 | hsivonen | is uneasy about <ds> and <dc> without an articulated reason |
| 12:23 | <jgraham_> | jrib: Sounds like debugging |
| 12:24 | <annevk42> | Hixie, shouldn't the <details> binding only work with <dd>? |
| 12:24 | <Hixie> | hsivonen: the articulated reason is that in the future, we will probably want <figure> <dt>legend <dc>credit <dd><img ...> </figure> |
| 12:24 | <zcorpan> | Hixie: it would make things harder if we found out that the use cases for <figure> demand it to be an inline element in the parser |
| 12:24 | <jrib> | jgraham_: yeah, I'll just comment them out I guess... |
| 12:24 | <annevk42> | Hixie, would be nice to be able to implement it as just a display switch |
| 12:25 | <jrib> | jgraham_: thanks |
| 12:25 | <annevk42> | Hixie, also a lot easier for script implementations |
| 12:25 | <Hixie> | annevk42: not sure what you mean |
| 12:25 | <annevk42> | Hixie, currently everything besides <dt> has to be hidden and displayed, rather than just the last child <dd> |
| 12:25 | <Hixie> | zcorpan: yeah, dunno |
| 12:25 | <annevk42> | (the concern is mostly about invalid docs) |
| 12:26 | <annevk42> | s/mostly// |
| 12:26 | <Hixie> | annevk42: oh, you want the rendering aspect changed more. i see. |
| 12:26 | <Hixie> | annevk42: yeah, i guess we could do that. |
| 12:26 | <jgraham_> | jrib: You are the only person known to be using the Python3 html5lib treebuilder |
| 12:26 | <jrib> | jgraham_: heh :) |
| 12:26 | annevk42 | wonders when Python3 will be more mainstream |
| 12:27 | <jrib> | I write my personal scripts in python3 |
| 12:27 | <jgraham_> | So you are basically welcome to do what you want with it. If you end up with patches you want to commit we can sort something out |
| 12:28 | <jgraham_> | (like you can have access to the Google code project or I can poull from your repo or whatever) |
| 12:29 | jgraham_ | remembers he was going to the shop some time ago |
| 12:30 | <jgraham_> | Perceptes: It looks like jQuery does something rather complex for DOM operations so it's not trivially obvious where the issue lies |
| 12:30 | <zcorpan> | hmm, writing tests for the resource selection algorithm is no fun |
| 12:30 | <zcorpan> | all my tests pass |
| 12:30 | <Perceptes> | jgraham_: I was afraid of that :| |
| 12:31 | <zcorpan> | darn philipj being so pedantic in following the spec |
| 12:31 | <hsivonen> | Perceptes: are you setting display: block; on the new structural elements? |
| 12:31 | <Perceptes> | yes, I'm using the html5 reset css from here: http://code.google.com/p/html5resetcss/downloads/list |
| 12:32 | <Perceptes> | ^ hsivonen |
| 12:33 | <hsivonen> | Perceptes: ok. that's not the problem then |
| 12:34 | <Perceptes> | I updated http://www.jimmycuadra.com/ie8/ with a full description of what's happening and a link to a copy of jgraham_'s page |
| 12:35 | <Perceptes> | anyway, it seems like this might be an issue for the jquery devs |
| 12:36 | <annevk42> | what's up with "HTMLWG WG"? |
| 12:54 | <Lachy> | annevk42, that's the working group that is working on the working group |
| 12:55 | <Lachy> | :-) |
| 12:55 | <Hixie> | is that another name for the html4all group? :-) |
| 12:55 | <Lachy> | maybe it's another name for the HTML-CG |
| 12:59 | <annevk42> | it's what everyone seems to be using when cc'ing the HTML WG list |
| 12:59 | <annevk42> | or at least a few people |
| 13:00 | <Lachy> | I haven't noticed it |
| 13:03 | <annevk42> | see e.g. http://lists.w3.org/Archives/Public/public-html/2009Sep/0567.html |
| 13:03 | <annevk42> | or http://lists.w3.org/Archives/Public/public-html/2009Sep/0550.html |
| 13:04 | <annevk42> | or http://lists.w3.org/Archives/Public/public-html/2009Sep/0537.html |
| 13:04 | <annevk42> | etc. |
| 13:06 | <Lachy> | oh, interesting. My mail client just displays "public-html" because that's what I have in my address book. |
| 13:06 | <beowulf> | it's for those working on HTML5 5 |
| 13:08 | <Philip`> | zcorpan: Hmm, the video page is pretty small so I suppose it could be merged with media-elements without causing extreme pain to people who asked for small pages |
| 13:08 | Philip` | updates his script; will upload some time later |
| 13:09 | <zcorpan> | Philip`: thanks |
| 13:10 | <Philip`> | hsivonen: I don't trivially have a copy of the parser section - I don't extract that section and then split it up further, I just split the original source document into a series of chunks |
| 13:10 | <hsivonen> | Philip`: is there a pre-splitter change and post-splitter change archive of the entire multipage spec |
| 13:10 | <hsivonen> | ? |
| 13:12 | <annevk42> | there might be one on dev.w3.org |
| 13:12 | <annevk42> | see http://dev.w3.org/cvsweb/html5/spec/ |
| 13:13 | <Philip`> | hsivonen: (so it's probably just as easy to extract that section using a simple regexp script, like perl -lne'print if /<h3 id=parsing>/../<h3 id=(?!parsing)/' index) |
| 13:13 | <hsivonen> | Philip`: oh so the splitting of the parsing section isn't changing? |
| 13:14 | <Philip`> | hsivonen: Hmm, I may be misunderstanding what you want |
| 13:15 | <hsivonen> | Philip`: if/when the lynx line wrapping of the parsing section is at risk of changing, I'd like to have reference files before and after the line wrap change |
| 13:15 | <hsivonen> | if there's no wrapping change happening this time, no problem |
| 13:16 | <Philip`> | hsivonen: The split pages that contain the parsing stuff will be different to what they were a few days ago - originally the tokeniser/tree-constructor/etc were separate pages, then <div class=impl> was added and they all became a single page, and recently the spec-splitter was updated so it will split them into separate pages again |
| 13:16 | <Philip`> | hsivonen: I don't think the splitter will change any wrapping ever - it's just copied from the source document (and parsed and serialised but not otherwise altered) |
| 13:16 | <hsivonen> | Philip`: ok. |
| 13:16 | <Philip`> | s/it's/the content of each page is/ |
| 13:17 | <hsivonen> | Philip`: at least once Hixie has done something that changed nesting depth of the paragraphs or somethnig |
| 13:17 | <Philip`> | It sounds like he must have edited the source document |
| 13:17 | <Philip`> | so I think I'm innocent of any involvement in that |
| 13:19 | <Philip`> | "why change the parser before actually adding new elements?" - it provides a way to avoid naming debates - there's no need to debate now because we're not actually adding any new elements with new names, and later we'll be forced to use the only names that are parsed correctly so there's no point debating then either |
| 13:20 | <hsivonen> | Philip`: excellent point! |
| 13:22 | <Hixie> | that's a pretty awesome reason |
| 13:22 | <Hixie> | ok, it's about 4 hours past my bed time |
| 13:22 | <Hixie> | and about 2 hours past my backup bed time |
| 13:22 | <Hixie> | so nn! |
| 13:23 | <Philip`> | hsivonen: (By the way, if you did want the old splitter output then the script is in SVN and should be relatively easily executable if you've got html5lib and lxml installed) |
| 13:23 | <hsivonen> | Philip`: ok. (I have neither) |
| 13:23 | <Philip`> | hsivonen: (but I'll assume for now that you don't need it, since hopefully nothing changed except the divisions between pages) |
| 13:23 | <hsivonen> | ok |
| 13:24 | annevk42 | sort of suspects someone to make an issue about this now |
| 13:24 | <Philip`> | Also by the way, I don't suppose anyone knows why suspend-to-RAM on my laptop only successfully resumes if I have active disk activity (e.g. md5summing a large file) before I run the suspend command? |
| 13:25 | <takkaria> | what are ds and dc meant to be for? |
| 13:25 | Philip` | wants a <psp> element |
| 13:26 | jgraham_ | wants a <wii> element |
| 13:26 | <takkaria> | <ny>? |
| 13:29 | Philip` | wants a <360> element too, but is scuppered by XML's NCName requirements |
| 13:29 | <Lachy> | Philip`, what's what with <xbox> ? |
| 13:29 | <Lachy> | <xbox type="360"> should work for you |
| 13:30 | <Lachy> | takkaria, what's <ny>? |
| 13:30 | <Lachy> | New York? |
| 13:31 | <Philip`> | Lachy: That suggests much more similarity between the types than there really is |
| 13:31 | <takkaria> | yeah, I was going off DC being Washington, District of Colombia |
| 13:31 | <Lachy> | oh |
| 13:31 | <takkaria> | screw all these, we need <gamesconsole type="xbox" model="360"> |
| 13:31 | <takkaria> | that's more extensible anyway |
| 13:32 | <annevk42> | might as well use <object> then |
| 13:32 | <takkaria> | + RDFa |
| 13:32 | <annevk42> | now you have two problems |
| 13:32 | <takkaria> | let's use Perl and regexes, then we have four |
| 13:33 | <Philip`> | takkaria: That's nowhere near enough attributes |
| 13:33 | <Lachy> | Philip`, wasn't the XBox 360 just the 2nd generation of XBox, much like the PS2 was the second generation PlayStation? |
| 13:33 | <Philip`> | Got to specify the type (Pro/Elite/etc), and disk size, and the code-name of the internal electronics |
| 13:34 | <Lachy> | oh. that's complicated. |
| 13:34 | Lachy | goes back to playing with his <gameboy> |
| 13:35 | <Philip`> | Lachy: It's totally new hardware with completely different CPU (Intel vs IBM) and completely different GPU (NVIDIA vs ATI) |
| 13:35 | <Philip`> | It's only backward-compatible through software emulation, I think |
| 13:36 | <Philip`> | I guess the OS and development tools are similar but greatly updated |
| 13:37 | <Philip`> | It's the second use of the brand name, but that's not really interesting - in most ways it's just an independent new thing |
| 13:37 | <Lachy> | right. So it's much more like the change from the Nintendo Control Deck to Super Nintendo (although they weren't compatible at all) |
| 13:38 | <Philip`> | (I expect PS->PS2 and PS2->PS3 are similar, in that they're totally new devices designed from scratch, rather than being updates of a previous version) |
| 13:39 | <Philip`> | (whereas GameCube->Wii is a much more basic hardware upgrade, just adding faster CPU and more RAM etc) |
| 13:39 | <da3d> | Philip`: We need to specify region too. A european 60GB PS3 is different from a north american 60GB PS3... |
| 13:40 | <Lachy> | Was the GameCube the one that came after the N64? |
| 13:40 | <da3d> | yes |
| 13:40 | <Lachy> | did the GameCube use CDs or cartridges for the games? |
| 13:41 | <da3d> | It used 1.5GB 8cm sorta-DVDs... |
| 13:41 | <annevk42> | small CDs |
| 13:41 | <Lachy> | oh |
| 13:43 | <Philip`> | da3d: I suppose that matters when someone queries the air-speed velocity of an unladen PS3 |
| 13:44 | Lachy | is so out of date when it comes to game consoles |
| 13:44 | <takkaria> | Philip`: it also matters for NTSC vs PAL, I imagine |
| 13:46 | <Philip`> | Wouldn't the hardware just support both? |
| 13:46 | <Philip`> | (as well as VGA and HDMI and whatever else) |
| 13:46 | Philip` | presumes it matters more for region-locking of games |
| 13:47 | jgraham_ | makles the rather obvious point that the change in input hardware from gamecube to wii is much more significant to the end user than the change in the internals |
| 13:48 | <annevk42> | the only problem with the Wii is the lack of non-casual-gamer games |
| 13:49 | <Philip`> | jgraham_: Indeed, but in terms of 'generations' it's just an incremental feature addition rather than a fundamental redesign |
| 13:49 | <annevk42> | stuff like GTA, Gears of War, etc. |
| 13:49 | <annevk42> | well, I guess there's Zelda and Mario Galaxy, but still |
| 13:49 | <da3d> | Old consoles actually had slightly different hardware in different regions, eg SNES had slightly different cpu clock rates for europe... |
| 13:50 | jgraham_ | should play more Zelda and Mario Galaxy |
| 13:50 | <Philip`> | GTA/GoW vs Zelda/Mario is quite a difference in tone |
| 13:50 | <Philip`> | da3d: Was that for NTSC vs PAL synchronisation? |
| 13:51 | <annevk42> | Philip`, they're similar in depth |
| 13:51 | <da3d> | Philip`: Not sure, probably. PAL consoles were horribly gimped back then anyway. |
| 13:51 | <Philip`> | (which seems less of an issue now there's so much variation in resolutions that you can't get precise synchronisation guarantees anyway, I guess) |
| 13:52 | <da3d> | I suppose it's mostly firmware differences these days, with a few exceptions (like certain PS3 models). |
| 13:53 | <Philip`> | annevk42: Depth similarities don't really help when you're in a mood for driving large trucks over grannies but you're not allowed to do anything but jump on mushrooms |
| 13:55 | <beowulf> | the links in Smylers lastest email don't work for me |
| 13:55 | <beowulf> | http://www.whatwg.org/html5#the-blockquote-element |
| 13:55 | <beowulf> | just goes to the multipage doc |
| 13:56 | <Philip`> | beowulf: Works for me |
| 13:56 | <Philip`> | beowulf: You don't have scripting disabled or anything? |
| 13:56 | <beowulf> | Philip`: no, JS is enabled, Smylers suggested that too |
| 13:56 | <beowulf> | I'm using Safari 4.0.3 |
| 13:57 | beowulf | investigates what else he may be doing that's stupid |
| 13:57 | Philip` | is unable to test in that |
| 13:57 | <Philip`> | (link-fixup.js ought to be redirecting you) |
| 13:58 | <beowulf> | no errors in the console... |
| 13:58 | <jgraham_> | Philip`: Are there any jumping-on-mushrooms games for the Xbox/PS3? |
| 13:58 | <jgraham_> | (that are comparable in quality to Mario) |
| 13:59 | <da3d> | The whole "Wii = casual" thing is way overblown... |
| 14:00 | <Philip`> | jgraham_: Seems unlikely |
| 14:00 | <Philip`> | At least there's Braid (on 360), which borrows some elements from Mario |
| 14:00 | <da3d> | Little Big Planet maybe? |
| 14:01 | Philip` | has never actually owned any console other than a DS, so he's not speaking from much experience here |
| 14:01 | da3d | hasn't played LBP though... |
| 14:04 | <Philip`> | ((Braid is also on PC, for ~£10, and is certainly worth it, unless you hate games)) |
| 14:07 | <beowulf> | LBp is fun |
| 14:10 | da3d | just noticed <dialog> has been dropped :( |
| 14:23 | <Lachy> | in the about: URI spec, would it be sensible for it to define how to handle the query string for about:blank? |
| 14:23 | <Lachy> | It currently says nothing about it, but browsers don't seem to be interoperable on this at all |
| 14:24 | <Lachy> | some just ignore the query string and return a blank page. IE8 complains with a Navigation cancelled message |
| 14:24 | <Lachy> | da3d, that was dropped earlier today because it was useless. |
| 14:25 | <Lachy> | and badly designed |
| 14:28 | <othermaciej> | Lachy: if other random about: URIs are undefined, and it's not needed for interop, then you can probably leave it undefined |
| 14:33 | <Lachy> | othermaciej, fair enough |
| 14:33 | <da3d> | Lachy: Yeah, I saw that while reading the irc logs. I kinda liked it, but I can't really argue against the issues it had so dropping it is probably for the best. |
| 14:34 | <othermaciej> | I'm kind of motivated to implement the new <figure> and/or <details> now |
| 14:34 | <Lachy> | cool |
| 14:34 | <Lachy> | I'm curious what UI you intend to give to details |
| 14:35 | <Lachy> | will it just be an expander triangle (or +/- icon) next to the dt? |
| 14:39 | <annevk42> | Lachy, I'd rather have it defined |
| 14:39 | <annevk42> | Lachy, probably as not having an effect |
| 14:41 | <Philip`> | The internet uses <dl> much more than I anticipated |
| 14:43 | <Philip`> | Also, computers are far too slow |
| 14:43 | <Philip`> | 1400 seconds and it's still not finished :-( |
| 14:43 | <Lachy> | annevk42, do you mean to define it such that about:blank and about:blank?foo are always effectively equivalent, as far as determining what resource to return is concenred? |
| 14:44 | <jgraham_> | Lachy: That seems sensible |
| 14:45 | <annevk42> | yeah |
| 14:46 | <Lachy> | ok |
| 14:48 | <annevk42> | as for fragids btw |
| 14:48 | <annevk42> | you can leave those out |
| 14:48 | <othermaciej> | Lachy: I would do it like Mac OS X disclosure triangles, but the tricky bit will be getting a nice animation |
| 14:48 | <Lachy> | annevk42, yeah, I know. They were already dropped from a previous draft |
| 14:48 | <Philip`> | (1600 seconds, a million lines of output, still not nearly finished...) |
| 14:49 | <Lachy> | othermaciej, do it with CSS transitions. |
| 14:49 | <erlehmann> | othermaciej, GTK has them too. so are they gonna implemented as native widgets? |
| 14:49 | <Philip`> | othermaciej, do it with <video> |
| 14:49 | <Lachy> | transition the height of the <dd> from 0 to auto over a 1s period |
| 14:49 | <othermaciej> | Lachy: that's what I was thinking - but I need to at least add pseudo-classes for the closed and open states in that case |
| 14:49 | <Lachy> | not sure how that would work with multiple <dd>s though |
| 14:50 | <othermaciej> | erlehmann: nothing in WebKit is implemented with native widgets |
| 14:50 | <Philip`> | Pre-render an MPEG of the animated triangle |
| 14:50 | <othermaciej> | erlehmann: I *could* make it themable but I am not sure it's worth it |
| 14:50 | <erlehmann> | Philip`, or, if MNG support is still in … wasn't that interactive? |
| 14:50 | <hsivonen> | WebKit has MNG support? |
| 14:50 | <erlehmann> | othermaciej, how does webkit-gtk work then? is it „fake“ widgets like with gtk-themed qt? |
| 14:52 | <othermaciej> | erlehmann: it uses the Gtk theme API to draw the native appearance |
| 14:53 | <othermaciej> | erlehmann: WebKit on Mac does it using Cocoa theme APIs |
| 14:53 | <othermaciej> | but all controls are drawn using CSS rendering |
| 14:53 | <othermaciej> | which allows you to fully style them if you choose |
| 14:54 | <erlehmann> | nice :) so the CSS transition approach is even flexible |
| 14:54 | <annevk42> | hmm yeah, we should have :open and :close or some such |
| 14:56 | jgraham_ | wonders how the need to introduce one CSS feature per HTML5 feature affects the idea that they are independant |
| 14:57 | <annevk42> | Selectors are not really independent |
| 14:57 | <annevk42> | and maybe CSS in general isn't either, dunno |
| 14:59 | <annevk42> | maybe this is something we should tackle for HTML6; how to introduce markup features that also need their visual/UI-side covered to succeed |
| 14:59 | <erlehmann> | jgraham_, i am envisioning a science-fiction short story where after a global crisis the world is ruled by the WHATWG, only by exploiting through several loopholes in existing web standards that ultimately tie into state law through use of accessability hoops. |
| 14:59 | <othermaciej> | it's hard to make pseudo-classes and psuedo-elements fully independent of the markup language |
| 14:59 | <erlehmann> | oopn, strike the "through" |
| 15:00 | <hsivonen> | It's bit sad that Google Maps views on various Web pages aren't resolution-independent |
| 15:00 | <hsivonen> | at least not in Firefox |
| 15:01 | hsivonen | wants Google Maps to use SVG |
| 15:01 | <erlehmann> | hsivonen, what other web map widgets are there? any using SVG? |
| 15:02 | <hsivonen> | I don't know |
| 15:02 | <hsivonen> | but I've browsed the Web lately with device pixel not equaling a CSS pixel |
| 15:02 | <hsivonen> | and my conclusion is that the Web needs a lot more vector graphics |
| 15:03 | <Philip`> | Could you come to a different conclusion that doesn't involve redesigning every web page in the world? |
| 15:03 | <Lachy> | othermaciej, here's a simple demo of how it could work http://software.hixie.ch/utilities/js/live-dom-viewer/saved/232 |
| 15:04 | <Lachy> | though that CSS isn't perfect |
| 15:04 | <Rik|work> | :expanded and the opposite can be useful for <details> and tree views in general |
| 15:05 | <othermaciej> | Lachy: now that's neat |
| 15:06 | <Lachy> | othermaciej, the only problem is that using height: auto; wouldn't work for the transition is going to the open state. So I had to hard code in a value for that |
| 15:06 | <annevk42> | doesn't work in Opera |
| 15:06 | <Lachy> | annevk42, that's cause I didn't use the -o- properly. |
| 15:06 | <Lachy> | *property |
| 15:07 | <othermaciej> | excepting I'd add a disclosure triangle and adjust the margins and such |
| 15:07 | <othermaciej> | also I think only the label should react to clicks |
| 15:07 | <Lachy> | and also cause we don't have transitions in 10, but it should work in core |
| 15:07 | <othermaciej> | does the spec require otherwise? if so it should be fixed IMO |
| 15:07 | <Lachy> | othermaciej, I don't think the spec requires any specific UI |
| 15:08 | <othermaciej> | basically because details needs to be able to hold interactive controls and it would be frustrating if a misclick collapsed it |
| 15:08 | <Lachy> | I just made the whole details clickable for simplicity. Making only the <dt> clickable would have reqired and extra line or two of code |
| 15:09 | <annevk42> | Lachy, it should at least hide/display without transitions, no? |
| 15:09 | <jgraham_> | Yeah only the label shopuld be clickable for sure |
| 15:09 | <Rik|work> | I want a slower transition if I hold Shift :) |
| 15:09 | <Lachy> | actually, it would just require this change: <details><dt onclick="toggle(this.parentNode);">Click This |
| 15:09 | <annevk42> | also doesn't work in Chrome |
| 15:10 | <Lachy> | does chrome support transitions? |
| 15:10 | <Philip`> | I hope it animates nicely with no jumping if you try to close it in the middle of the opening animation |
| 15:10 | <othermaciej> | would it be overly gross to reuse :checked instead of making a new pseudo? |
| 15:12 | <annevk42> | othermaciej, that sounds fine to me |
| 15:12 | <jgraham_> | that sounds somewhat dubious to me, but then I know nothing about CSS |
| 15:13 | <jgraham_> | (I would worry a bit about people finding their scripts that assumed only form controls could be :checked breaking) |
| 15:13 | <othermaciej> | if I make up a new pseudo it has to be a -webkit-prefixed one at least for now |
| 15:13 | <Lachy> | annevk42, it works in gogi if you move the onclick attribute to the <dt> like I showed above and change the -webkit- to -o- |
| 15:13 | <annevk42> | it's a boolean state and :checked matches that |
| 15:13 | <Lachy> | apparently we don't support event attributes on unknown elements, like webkit does |
| 15:13 | <annevk42> | the name might not match exactly, but still... |
| 15:14 | <annevk42> | Lachy, hmm, we should have a bug on that |
| 15:14 | <Lachy> | do you want to file ti? |
| 15:14 | <Lachy> | it? |
| 15:15 | <Lachy> | othermaciej, why do we need the new pseudo? |
| 15:16 | <Lachy> | what's wrong with just basing it on the open attribute like details[open] and details:not([open]) |
| 15:16 | <othermaciej> | Lachy: does the attribute have to reflect the current open state? |
| 15:16 | <Lachy> | yes |
| 15:17 | <othermaciej> | that would work then |
| 15:17 | <zcorpan> | <video src=data:application/octect-stream,broken onemptied=this.appendChild(document.createElement('source'))></video> |
| 15:18 | <zcorpan> | networkState is NETWORK_EMPTY, so inserting a <source> will start the resource selection algorithm |
| 15:18 | <zcorpan> | the resource selection algorithm will see that a src attribute is present |
| 15:19 | <zcorpan> | and use src |
| 15:19 | <annevk42> | ah yeah, I forgot that about <details> |
| 15:19 | <annevk42> | still not sure whether such a design makes sense, but I suppose it does not matter |
| 15:23 | <Lachy> | annevk42, what doesn't make sense about the design? |
| 15:23 | <annevk42> | it's different from all other form controls |
| 15:24 | <Lachy> | it's not a form control though |
| 15:24 | <annevk42> | form control, ui control, all the same imo |
| 15:25 | <othermaciej> | the way form control value works is terrible though |
| 15:27 | <annevk42> | yeah, that was Hixie's argument for keeping it this way |
| 15:27 | <Lachy> | ok, I guess I'm missing something. I don't see how it could possibly work any other way |
| 15:29 | <othermaciej> | it could work in a way where the markup attribute sets the default initial value but the dynamic state is decoupled from it thereafter |
| 15:30 | <jgraham_> | Of course that would be weird and confusing |
| 15:30 | <Lachy> | ah, ok. Yeah, that would be silly. |
| 15:31 | <Lachy> | it's confusing enough for <input> and <textarea> |
| 15:31 | <othermaciej> | I' |
| 15:32 | <othermaciej> | I'm not saying that it would be good to do that, just that it's possible, and probably what annevk42 had in mind |
| 15:36 | <Philip`> | http://philip.html5.org/data/dl.html |
| 15:36 | <Philip`> | Feel free to look for people using it for dialog etc |
| 15:36 | <Philip`> | if you're incredibly bored |
| 15:45 | <jgraham_> | There are a few uses for lists of comments in bug trackers and forums which are a bit like dialog |
| 15:45 | jgraham_ | has looked at the top third or so |
| 15:58 | <beowulf> | what's the point of <dl>? |
| 15:59 | <Philip`> | Backward compatibility with content that uses <dl> |
| 16:00 | <beowulf> | :) |
| 16:00 | <hsivonen> | beowulf: getting a mix of bolded text and indented text |
| 16:01 | <zcorpan> | it seems like the "If the media data is corrupted" condition is dead code if your media framework is non-draconian in its error handling |
| 16:02 | <jgraham_> | hsivonen: Having just looked through the big list from Philip` it seems like there are quite a few basically conforming uses |
| 16:02 | <jgraham_> | ANd a few basically non-conforming uses |
| 16:02 | <jgraham_> | (no conversation in English that I spotted) |
| 16:02 | <zcorpan> | i would appreciate if someone could produce a file that gstreamer can play but then aborts with a fatal error |
| 16:03 | <Philip`> | hsivonen: You don't get bold automatically, only indentation |
| 16:04 | <Philip`> | jgraham_: If you want, I can give you a list that's 50 times bigger |
| 16:10 | <jgraham_> | Philip`: No |
| 16:12 | <Philip`> | jgraham_: I can give you one that is approximately n times bigger, for 0 <= n <= 50 |
| 16:14 | <jgraham_> | Philip`: Can I have n=0 please? |
| 16:17 | <Philip`> | jgraham_: Sure |
| 16:17 | <Philip`> | jgraham_: I've uploaded it to about:blank |
| 16:18 | <Philip`> | (Sorry for using a non-standard URL) |
| 16:19 | <Dashiva> | Philip`: Wikipedia gives you bold :P |
| 16:20 | hsivonen | wonders how ActiveX integrates with the event loop considering that sync XHR started out as an ActiveX thingy |
| 16:23 | <hsivonen> | cool. it seems the W3C is doing several right things: http://omocha.w3.org/wiki/ |
| 16:23 | <hsivonen> | Reftest, Mochitest and hg |
| 16:25 | <annevk42> | I was just about to post that :) |
| 16:26 | <jgraham_> | Hmm, so I'm not sure about Mochitest |
| 16:27 | <hsivonen> | jgraham_: what's wrong with Mochitest? |
| 16:27 | <jgraham_> | Since according to the mochitest page the main advantage (for Mozilla) is that it can be run in chrome |
| 16:28 | <jgraham_> | On a technical level a) using == rather than === for assertions is wrong |
| 16:29 | jgraham_ | forgets what b) and c) were |
| 16:31 | Philip` | uses mochitests for his (mostly non-chrome) canvas tests, because it seemed the easiest way to do script-based assertions |
| 16:31 | <jgraham_> | I guess if it depends on Mochikit that is overkill for most testing needs. You don't want a bug in the test harness to cause all the tests to fail |
| 16:31 | <Philip`> | (This is for the version of the tests that's in Mozilla's test suite) |
| 16:31 | <jgraham_> | (that's why jsUnit is evil, for example) |
| 16:35 | <hsivonen> | we should collect a list of troublesome Web features so that proposed features can be compared to the list for early detection of badness |
| 16:35 | <hsivonen> | stuff like sync XHR, Namespaces, alert() and document.write() |
| 16:36 | <annevk42> | localStorage o_O |
| 16:36 | <jgraham_> | I guess another problem about MochiTest is that the number of assertions is wrong. There should either be lots (to deal with exceptions, e.g.) or just a way of recording pass/fail |
| 16:41 | <Pure> | Hey! |
| 16:42 | <jgraham_> | Hej |
| 16:42 | <Pure> | How extensive is Offline Applications? |
| 16:42 | <Pure> | In HTML5 |
| 16:42 | <annevk42> | did that guy who was going to explain us how HTML5 is silly and bloated come back with his blogpost btw? |
| 16:42 | <annevk42> | Pure, ? |
| 16:43 | <Pure> | *Looks up nme* |
| 16:43 | <Pure> | The caching of pages for offline using |
| 16:43 | <annevk42> | what do you mean with extensive? |
| 16:44 | <boblet> | Any Opera ppl here with @font-face experience? |
| 16:44 | zcorpan | has some experience |
| 16:45 | annevk42 | has some too |
| 16:45 | <boblet> | Daniel Davis’ nice Japanese example page using M+ font isn’t actually using M+ font http://devfiles.myopera.com/articles/751/japanese-newspaper.html |
| 16:46 | <Pure> | I mean, can I have an offline version of the page and an online version? |
| 16:46 | <Pure> | And can the manifest be in php? |
| 16:47 | <boblet> | The other Japanese @font-face font (in the main title) works fine, but I can’t get M+ fonts to work (M+ is used in article titles—cf Safari/FF where it’s much bolder/different glyphs) |
| 16:48 | <boblet> | brokenforeveryoneorjustme.com? |
| 16:49 | <beowulf> | Pure: I think there's a bug with a version of ff related to offline web pages |
| 16:51 | <annevk42> | Pure, not really |
| 16:51 | <annevk42> | Pure, actually, yes, you can |
| 16:51 | <Pure> | Huh? |
| 16:51 | <annevk42> | Pure, though from what I heard Firefox does not support FALLBACK or something |
| 16:51 | beowulf | is answering Pure's first q |
| 16:51 | <Pure> | And they can be in php? |
| 16:51 | <zcorpan> | beowulf: i don't see any difference between opera and firefox for the article titles |
| 16:52 | <beowulf> | zcorpan: ? |
| 16:52 | <zcorpan> | beowulf: sorry |
| 16:52 | <zcorpan> | boblet: i don't see any difference between opera and firefox for the article titles |
| 16:53 | <annevk42> | Pure, what do you mean PHP? |
| 16:53 | <annevk42> | Pure, the client never gets PHP |
| 16:53 | <boblet> | zcorpan: are you using MacOSX? |
| 16:54 | <Pure> | Does the client not request the manifest file, then the server parses it for php? |
| 16:54 | <annevk42> | Pure, sure |
| 16:55 | <annevk42> | Pure, you need to set the correct media type though |
| 16:55 | <annevk42> | Pure, maybe you're not doing that? |
| 16:55 | <zcorpan> | boblet: no, windows |
| 16:55 | <GPHemsley> | I assume there was an extensive discussion about dropping the 'cite' and 'pubdate' attributes from <article>? |
| 16:55 | <Pure> | I haven't tried yet, I'm just wondering |
| 16:55 | <GPHemsley> | (Aww, man, my logic is prohibited again? ...) |
| 16:56 | <annevk42> | Pure, in the end it's just bytes going over the wire, PHP has nothing to do with it |
| 16:56 | <annevk42> | GPHemsley, it was before too, just in Japenese |
| 16:56 | <boblet> | zcorpan: I don’t know if the version numbers are cross-platform, but what build? I’m on v6652 (newest for Mac) |
| 16:56 | <zcorpan> | Pure: php can generate any stream of bytes and set arbitrary headers |
| 16:56 | <GPHemsley> | annevk42: Oh, last I heard it had been turned into literal question marks. |
| 16:56 | <zcorpan> | Pure: so you can set the content-type header to whatever is needed for the manifest file and then generate it with php if you want |
| 16:56 | <annevk42> | GPHemsley, that was very temporary |
| 16:56 | GPHemsley | shrugs |
| 16:57 | <GPHemsley> | but anyway, back to my main question |
| 16:57 | <zcorpan> | boblet: 1733 |
| 16:57 | <annevk42> | pubdate moved to <time> |
| 16:57 | <annevk42> | cite was not found useful enough |
| 16:57 | <Pure> | What happens if the user tries to view a php page while offline? |
| 16:58 | <Lachy> | cite="" should also be dropped from blockquote |
| 16:59 | <Lachy> | since browsers don't offer a way to follow it and authors duplicate it with <a href> and <cite> anyway |
| 16:59 | <zcorpan> | Pure: there's no difference between "a php page" or "an html page" |
| 16:59 | <Pure> | Ah, the last generated page will be shown |
| 16:59 | <annevk42> | #httpistough |
| 17:00 | <Pure> | Can I detect if the user is offline with javascript |
| 17:00 | <annevk42> | yes |
| 17:00 | <annevk42> | see navigator.onLine |
| 17:00 | <zcorpan> | isn't there a tutorial for this? |
| 17:00 | <annevk42> | on devmo |
| 17:01 | <boblet> | zcorpan: ok thanks. will file a bug with a screenshot |
| 17:02 | <zcorpan> | boblet: cool thanks |
| 17:03 | <GPHemsley> | I think I agree with Erik's commentary on <cite>, FWIW. It should be able to contain one full line of a works cited page. Either allow for embedded <cite>s with different 'type' attributes (e.g. full, title, author, etc.), or just leave that job for <span> and CSS. |
| 17:03 | <GPHemsley> | (referencing the recent mailing list post) |
| 17:08 | Philip` | thinks "we will [...] deviate from the standard" is a great quote |
| 17:09 | <GPHemsley> | heh |
| 17:09 | <Philip`> | At least they're not consistently pretending to support it when they don't |
| 17:28 | <takkaria> | Shelley is so vitriolic I can feel the acid burn from thousands of miles away |
| 17:28 | <Dashiva> | Again? |
| 17:29 | <adactio> | takkaria: Yeah, this kind of made me wince a little: http://twitter.com/shelleypowers/status/4006648345 |
| 17:30 | <takkaria> | for some reason <dt> being used for stuff other than <dl> makes it "virtually useless", and now it's part of a "so-called 'details'" element |
| 17:30 | <takkaria> | apparently it means nothing anymore |
| 17:30 | <Philip`> | Her recent email doesn't appear to ask any questions or suggest any changes |
| 17:30 | <Philip`> | so it's hard to do anything productive with it |
| 17:31 | <takkaria> | I wish that her leaving the working group meant she posted to public-html less, but that doesn't seem to be happening so much |
| 17:34 | <jgraham_> | I wish her being a chronic attention seeker didn't actually result in her getting a disproportionate amount of attention |
| 17:34 | <zcorpan> | Philip`: it asks a question in the Subject: |
| 17:36 | <boblet> | zcorpan: bug DSK-265703 (I guess) |
| 17:36 | <Philip`> | zcorpan: Ah, yes |
| 17:36 | <Philip`> | zcorpan: I assumed that was a rhetorical question :-) |
| 17:36 | <zcorpan> | boblet: thanks |
| 17:37 | <boblet> | also interesting to note Daniel’s sample page is misusing <section> (another example of confusion on how to use section) |
| 17:38 | <Philip`> | Are there existing examples of elements that have very different meaning depending on the context they're used in? |
| 17:39 | <Philip`> | (assuming they're used conformingly in their context) |
| 17:39 | <annevk42> | <h1> |
| 17:39 | <hober> | adactio: thanks for the shout-out, btw |
| 17:39 | <boblet> | oh, hey adactio. nice work on dt/dd idea yo |
| 17:40 | <takkaria> | but they mean nothing now!!1! |
| 17:40 | takkaria | stops sniping |
| 17:41 | <Philip`> | annevk42: Hmm, anything with a less subtle distinction than that? |
| 17:41 | <beowulf> | Philip`: <li>? |
| 17:42 | <beowulf> | that's not a very different meaning though, sry |
| 17:42 | beowulf | tries harder |
| 17:43 | <annevk42> | Philip`, <dfn> sort of depends on the context, but not very different |
| 17:44 | <annevk42> | Philip`, the <dt>/<dd> is also not that different |
| 17:45 | <annevk42> | though a bit more |
| 17:45 | <boblet> | Hixie: I think the “a general rule…” text in the note on #the-section-element isn’t going to make sense to authors. |
| 17:46 | <boblet> | Hixie: this is too long, but might be of some use: http://html5doctor.com/the-section-element/#comment-970 |
| 17:48 | <jgraham_> | Philip`: <kbd> and <samp> |
| 17:50 | <boblet> | later all |
| 17:51 | <jgraham_> | (also, arguably <aside>) |
| 17:51 | Philip` | wonders why Opera just says "Secure site: The connection to mail.google.com is secure." with no extra information (e.g. company names) in the address bar thingy or the dialog box |
| 17:52 | <Philip`> | Does that mean it could easily be a MITM attack? (with a secure connection to an unknown server) |
| 17:52 | <AryehGregor> | Not unless they've got a CA to give them a certificate for mail.google.com. |
| 17:54 | <AryehGregor> | If it doesn't give a company name, that just means it might not be a fancy extra-expensive certificate that supposedly verifies that mail.google.com actually belongs to, you guessed it, Google, Inc. |
| 17:54 | <AryehGregor> | Which is not terribly useful anyway, AFAICT. |
| 17:56 | <Pure> | Can I have my page have a certificate on it? |
| 17:57 | <AryehGregor> | Yes, if you pay a CA for it. Or self-sign/use CACert/etc. for free, which browsers will complain about. |
| 17:59 | <AryehGregor> | "While I was at it, I also did this for <figure>, and removed <dialog> from the spec altogether." |
| 17:59 | <AryehGregor> | I like the casualness of that statement. |
| 18:00 | <AryehGregor> | (yay for the death of <dialog>) |
| 18:00 | <Pure> | Why would a browser complain about it? |
| 18:00 | <AryehGregor> | Because it doesn't actually verify who you are. |
| 18:00 | <AryehGregor> | http://en.wikipedia.org/wiki/Public_key_infrastructure |
| 18:01 | <Philip`> | AryehGregor: If I go to e.g. https://www.ietf.org/ (which I don't think is fancy extra-expensive), it still shows the certificate's domain in the address bar, and has "Certificate summary" and a Certificate tab in the dialog box |
| 18:01 | <Philip`> | whereas on Gmail I get none of that |
| 18:01 | <Philip`> | (Amusingly https://ietf.org complains of an invalid certificate, because it doesn't match *.ietf.org) |
| 18:03 | <AryehGregor> | http://www.verisign.com/ssl/ssl-information-center/extended-validation-ssl-certificates/index.html |
| 18:03 | <AryehGregor> | http://en.wikipedia.org/wiki/Extended_Validation_Certificate |
| 18:04 | <Philip`> | AryehGregor: That doesn't seem relevant when I just want Opera to show me at least a few details of the normal non-EV certificate on Gmail |
| 18:04 | <AryehGregor> | Chrome doesn't seem to show almost anything. |
| 18:04 | <AryehGregor> | I'm not sure what info you're saying Opera is missing. |
| 18:05 | <Philip`> | Imagine any kind of information whatsoever |
| 18:05 | <Philip`> | Opera is missing it |
| 18:05 | <AryehGregor> | ietf.org doesn't seem to be using an EV cert either. |
| 18:05 | <AryehGregor> | Meh, UI issue. |
| 18:06 | <Philip`> | "I apologize in advance if any of this post duplicates things that have been said before I joined these lists" - hmph, you were too lazy to catch up on the archive before joining? |
| 18:06 | <annevk42> | Philip`, for mail.google.com I see mail.google.com in the address bar with the padlock... just like for ietf.org |
| 18:06 | <Philip`> | There's only like twenty thousand messages |
| 18:06 | <AryehGregor> | Really, that few? |
| 18:09 | <Philip`> | Next you'll be saying you didn't read all the archived IRC logs |
| 18:10 | <Philip`> | http://philip.html5.org/misc/gmail-cert.png |
| 18:11 | <annevk42> | weird |
| 18:11 | <Philip`> | If I reload Gmail then it starts working fine |
| 18:12 | <Philip`> | If I view an email with external images, it changes to a question mark and the dialog says it's insecure |
| 18:13 | <Philip`> | I haven't seen it change back to the empty yellow box yet |
| 18:14 | <Philip`> | AryehGregor: If you're looking for examples of summary usage, http://philip.html5.org/data/table-summary-values-dotbot.html has some |
| 18:14 | <AryehGregor> | Does that say if they actually meet the use cases adequately? |
| 18:15 | <AryehGregor> | I can't figure out whether the examples given in the spec change proposal meets the proposed use case, let alone stuff on random websites. |
| 18:15 | <Philip`> | It doesn't say anything, it's just mostly-raw data |
| 18:16 | <Philip`> | I think people who've looked at the data say most of it is either useless or garbage |
| 18:16 | <Philip`> | (That is, the summary values are useless or garbage, not the data about summary values) |
| 18:16 | <Philip`> | (though the data might be too) |
| 18:17 | <Philip`> | so there's no desire to make the spec accept what random websites do |
| 18:20 | <Philip`> | "standards authors can't give authors much incentive to cater to blind people if blind people are 0.1% or less of their audience" - that's what government legislation is for, so people are forced to make things accessible even if it's not in their business interests |
| 18:21 | <Philip`> | and so standards need to provide features that can be used by people who are forced to make things accessible, and that clearly demonstrate they've done some work to demonstrate they've made things accessible |
| 18:22 | <Philip`> | (so explicit attributes are good, because you can easily check if they exist or not, and if they exist then someone's clearly been successfully forced to do some work) |
| 18:22 | <Philip`> | Maybe that's how it works, anyway, or maybe that's totally wrong |
| 18:28 | jgraham_ | feels compelled to make the obvious point that the existance of some accessibility attribute and the content actually being more accessible are not strongly correlated |
| 18:28 | <webben> | Philip`: I think you'll find many people who think HTML is better off with features like "summary" don't have that much faith in automated testing for accessibility. |
| 18:30 | <annevk42> | webben, I hope they don't think that the people who think HTML is worse off with such features do have much faith in that... |
| 18:33 | <AryehGregor> | webben, I hope nobody has much faith in automated testing for accessibility. |
| 18:33 | <AryehGregor> | Philip`, you can't realistically require that every website be accessible, or even most. |
| 18:33 | <hsivonen> | hmm. non-DOM processors out of scope? http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0093.html |
| 18:34 | <AryehGregor> | A small minority, sure, maybe. |
| 18:34 | <AryehGregor> | But even then it's somewhat hard. |
| 18:34 | hsivonen | wonders how that's going to go with those who object to DOM-centricity |
| 18:34 | <AryehGregor> | It's not like RL accessibility, where you can say "everywhere has to be wheelchair-accessible by following these detailed rules about the exact width and slope of ramps needed". |
| 18:36 | Philip` | wonders what kind of testing is used for accessibility legislation |
| 18:37 | <AryehGregor> | Web accessibility legislation, you mean? |
| 18:37 | hsivonen | thought governments pretty much look at whatever WCAG says for Web accessibility |
| 18:37 | jgraham_ | wonders if he should have sent the email explaining why a lxml-based RDFa processor would need to know about the htmlness of documents (or assume anything taht looked like xmlns: under the infoset coercion algorithm was actually html) |
| 18:37 | <Philip`> | AryehGregor: Yes |
| 18:37 | <AryehGregor> | Probably lengthy checklists of manually-checked regulations. Maybe just copied from WCAG. |
| 18:37 | <jgraham_> | s/anything/any attribute with a name starting with something/ |
| 18:38 | <hsivonen> | jgraham_: seems like something to point out |
| 18:40 | <jgraham_> | hsivonen: I am reluctant to engage in too much discussion about a technology I am as uninterested in as RDFa |
| 18:40 | <Philip`> | jgraham_: It seems potentially productive to give concrete examples of why some implementers will have to care about these things, even if all the current implementations are coping alright with namespace-unaware APIs |
| 18:41 | <AryehGregor> | Ugh, I shouldn't be posting these long things that will actually attract replies. I don't have time for it. |
| 18:42 | <webben> | annevk42: That wasn't what I meant; I see no reason to think they do. AryehGregor: That hope is likely to be disappointed. |
| 18:42 | <AryehGregor> | What hope? |
| 18:42 | <AryehGregor> | Oh. |
| 18:42 | <AryehGregor> | Automated testing. |
| 18:42 | <AryehGregor> | Oh well. |
| 18:42 | <webben> | hsivonen: Pretty much, from what I've seen (looking at WCAG). |
| 18:48 | <othermaciej> | AryehGregor: I think your post was interesting and I don't think it just duplicated previous posts |
| 19:00 | <cgriego> | As I read it, the details element content model forbids dd+dt? If I am reading that correctly, then I think that should instead be explicitly allowed. |
| 19:02 | <Dashiva> | cgriego: Hixie is more likely to listen if you give reasoning |
| 19:03 | <cgriego> | The most common use case would be a more/less use case. Where some teaser content is always visible and you want the control anchored to the bottom. |
| 19:07 | <Dashiva> | But the teaser content would be the <dt> would it not? |
| 19:07 | <Dashiva> | So it seems what you really want is control of the UI placement |
| 19:12 | <webben> | cgriego: Sounds like something to be controlled with CSS. |
| 19:13 | <cgriego> | No, teaser content would not appear in the dt because the teaser content should not control the show state. |
| 19:13 | <cgriego> | Example (Show All Amenities): http://travel.ian.com/hotel/propertydetails/134540/SUMMARY?cid=40 |
| 19:14 | <cgriego> | Example (more under city list): http://www.getaroom.com/ |
| 19:14 | <webben> | cgriego: No teaser content should be extracted from the "hidden" part of details. |
| 19:16 | <webben> | hmm. |
| 19:18 | <webben> | cgriego: In the case of getaroom, I don't think the first cities you see should be part of details. |
| 19:18 | <cgriego> | Agreed, it would appear before the details element. |
| 19:19 | <webben> | cgriego: so <details><dt>More cities</dt><dd>... additional cities ... </dd></details> |
| 19:21 | <webben> | cgriego: Though I suspect the widget as a whole is "semantically" http://dev.w3.org/html5/spec/forms.html#attr-input-list |
| 19:21 | <cgriego> | That's the rub, in the case of adding expanded information, it's common for the control to be below the content. |
| 19:21 | <cgriego> | As an author, I want to be able to put the dd first. |
| 19:21 | <webben> | cgriego: Before/after is CSS. |
| 19:22 | <webben> | though /either/ will gel with native <details> controls I dunno |
| 19:23 | <webben> | cgriego: In CSS 2.1, position the dt relative to details; in CSS3, http://www.w3.org/TR/css3-content/#moving |
| 19:23 | <webben> | *how /either/ |
| 19:25 | <annevk42> | cgriego, maybe you should suggest on the list that both orders should be allowed and give the examples |
| 19:25 | <annevk42> | cgriego, though I'm not sure the second example applies |
| 19:30 | <cgriego> | Additional examples: iTunes artwork panel, iCal calendars/notifications panel, firebug, IE developer tools. |
| 19:37 | <annevk42> | ifette, congrats, though where's Mac/Ubuntu-stable? :) |
| 19:41 | <hsivonen> | annevk42: did the Chome team ship to stable channel? |
| 19:41 | <hsivonen> | *Chrome |
| 19:43 | <hsivonen> | it seems so |
| 19:44 | <hsivonen> | did both Theora and H.264 make it to the stable release? |
| 19:55 | <hsivonen> | hmm. CSSquirrel now has a URL in aria-describedby... |
| 20:01 | <Lachy> | that's not surprising. I expected that to become a common authoring mistake, as people think aria-describedby is a direct replacement for longdesc |
| 20:02 | <takkaria> | relatively easy cowpath to pave, though |
| 20:09 | <hsivonen> | Lachy: the interesting part is that CSSquirrel was nonetheless put forward as a positive example by an accessibility expert despite it using the attribute wrong |
| 20:10 | hsivonen | assumes that Kyle Weems reads this anyway, so the IRC log counts as a bug report |
| 20:11 | <annevk42> | it's funny how we always point out the mistakes... |
| 20:14 | <Dashiva> | Maybe doing something is more important than doing it right |
| 20:15 | jgraham_ | is discovering why OpenOffice is not more popular |
| 20:17 | <Philip`> | Because it's too free? |
| 20:17 | <jgraham_> | Because the UI is too shit |
| 20:17 | <Philip`> | Hmm, that too |
| 20:18 | Philip` | only really has Microsoft Office 97 as a point of comparison |
| 20:19 | <jgraham_> | It seems exactly like what you would get if you made a really half assed clone of the Office-97 UI so that seems like a reasonable point of comparison |
| 20:20 | <hsivonen> | OO.o is like SeaMonkey in need of its Firefox |
| 20:21 | <Philip`> | I guess part of the problem is that Microsoft Office works pretty well, so few people have a personal desire to work on a replacement |
| 20:23 | <Philip`> | (whereas IE6 was old and unmaintained and lacked lots of necessary features, so there was strong incentive for a replacement) |
| 20:24 | <othermaciej> | OO.o has crufty code and unpleasant UI |
| 20:24 | <hsivonen> | I mean the OOo engine needs a better UI design |
| 20:24 | <jgraham_> | But the replacemnets have generally done better by improving the UI not slavishly copying the UI |
| 20:24 | <jgraham_> | from IE |
| 20:24 | <hsivonen> | OOo's COM clone is rather horrible. |
| 20:24 | hsivonen | has programmed with the UNO Java bridge |
| 20:25 | <othermaciej> | perhaps the same could be said for old school SeaMonkey, but OO.o's code is a lot bigger, and there's no motivated group of insiders looking to make a radical improvement |
| 20:25 | <hsivonen> | where you need to do both QueryInterface *and* Java-level casting |
| 20:26 | <hsivonen> | with the UNO-Java bridge, more than 50% of the lines of code are just dealing with the system and not doing anything productive |
| 20:26 | <Philip`> | hsivonen: Indeed, and I mean there's probably few people interested in working on a better UI design for it, because those people (and most of the potential audience) can just use MS Office |
| 20:27 | <Philip`> | (unless they're solely on Linux, in which they can't, but there aren't many people like that and they're not going to care a lot about UI design) |
| 20:27 | <Philip`> | s/which/which case/ |
| 20:27 | <roc> | Google Docs etc will disrupt all this |
| 20:28 | jgraham_ | wonders why Philip` thinks that Linux users don't cre about UI design |
| 20:28 | <jgraham_> | *care |
| 20:28 | <jgraham_> | Hmm Google docs. There's an idea |
| 20:28 | taf2 | likes nice looking apps on linux.. |
| 20:28 | <jgraham_> | IS it actually any good yet? |
| 20:28 | <Philip`> | jgraham_: I guess some of them do, but not enough to make Linux a shining example of good UI design |
| 20:29 | <roc> | jgraham_: no, but it's convenient |
| 20:29 | <jgraham_> | Philip`: Generally a lot of Gnome stuff has pretty reasonable UI design. KDE is generally pretty awful I grant you |
| 20:29 | <takkaria> | jgraham_: no, it's not |
| 20:29 | <roc> | and for collaboration it can't really be beat |
| 20:29 | <hsivonen> | mpt has lots of stuff to fix still |
| 20:30 | <takkaria> | the spreadsheet stuff is good, mind |
| 20:30 | <mpt> | Clearly I should sleep less |
| 20:30 | <roc> | unless you have sharepoint |
| 20:30 | <roc> | but most people don't have sharepoint |
| 20:30 | <takkaria> | but the word processor feels much like sitting a bit contentEditable |
| 20:30 | <takkaria> | *big contentEditable field |
| 20:31 | <jgraham_> | mpt: Would it help if you stopped sleeping altogether? |
| 20:31 | <annevk42> | roc, as uber-late reply, I mean <isindex> being implemented with XBL, not <hr> or <input> (they appear on screen if you use <isindex>) |
| 20:31 | <mpt> | Sun apparently has a bench of UX designers working on OpenOffice.org |
| 20:31 | <jgraham_> | takkaria: That's basically what I remember too |
| 20:32 | <roc> | annevk42: oh. The implementation of <isindex> predates XBL |
| 20:32 | <annevk42> | is it done directly in the style tree then or something? |
| 20:33 | <annevk42> | oh well, doesn't really matter I guess |
| 20:33 | <roc> | it uses a different anonymous content system |
| 20:33 | <roc> | more like what Webkit does if I understand correctly |
| 20:36 | <hsivonen> | roc: WebKit seems to have a parser macro for isindex |
| 20:36 | <roc> | sorry, I mean the way Webkit does anonymous content in general, not for isindex |
| 20:37 | <hsivonen> | I see |
| 20:48 | <Lachy> | now what on earth would be the point of allowing aria-describedby accept URLs instead of IDREFs, and let it be used just like longdesc? That would just repeat exactly the same mistake as longdesc! http://lists.w3.org/Archives/Public/public-html/2009Sep/0591.html |
| 20:49 | <Dashiva> | But this time it'll be different! |
| 21:11 | <zcorpan> | why can't i edit bugs in w3c bugzilla? |
| 21:11 | <annevk42> | did mike(tm) gave you editbugs? |
| 21:11 | <zcorpan> | no? |
| 21:12 | <annevk42> | that's your answer |
| 21:12 | <zcorpan> | ok |
| 21:12 | <annevk42> | you can ask him, if it's something trivial i can make the change for you now |
| 21:13 | <annevk42> | s/,/ for editbugs,/ |
| 21:13 | <zcorpan> | i wanted to make the summary shorter for http://www.w3.org/Bugs/Public/show_bug.cgi?id=7639 |
| 21:16 | <annevk42> | done |
| 21:17 | <zcorpan> | thanks |
| 21:27 | <Philip`> | Is anyone going to point out the squirrely aria-describedby error on the list? |
| 21:30 | <Dashiva> | Doesn't look like it |
| 21:30 | <Dashiva> | Go ahead if you want to |
| 21:31 | <annevk42> | maybe we should put some money on the number of hours until when it comes out and John realizes he's wrong |
| 21:32 | <othermaciej> | why did Opera add longdesc support anyway? |
| 21:33 | <othermaciej> | do you guys have data on it being useful, or customer requests, or the like? |
| 21:33 | <annevk42> | I'd ask chaals |
| 21:33 | annevk42 | doesn't really know |
| 21:34 | <othermaciej> | was chaals involved in the decision, or are you just saying he's likely to know stuff like that in general? |
| 21:35 | <annevk42> | both, I think |
| 21:35 | <annevk42> | (at least as far a11y goes) |
| 21:37 | <zcorpan> | the impl doesn't work so well for longdesc="#description", however that doesn't work so well in jaws either so maybe it's good to discourage authors from doing that |
| 21:37 | <Philip`> | Dashiva: I'm happy to leave it for someone else, rather than getting involved |
| 21:38 | <Philip`> | I presume if the page was unfixed, and then Opera implemented aria-describedby taking precedence over longdesc, the page's description would become inaccessible |
| 21:38 | <Philip`> | So: Don't implement ARIA, it will demonstrably hurt accessibility |
| 21:53 | <zcorpan> | maybe he'd find the mistake if he validated against html5 "Error: The aria-describedby attribute must point to an element in the same document." |
| 21:56 | <zcorpan> | hmm. does the spec make document.createElement('isindex') an HTMLElement rather than HTMLUnknownElement by listing it in the obsolete section? |
| 22:05 | <gsnedders> | zcorpan: I'd say yes, but that does seem horrifically underdefined |
| 22:14 | zcorpan | considers switching to dt/dd for figure on one of his sites, but concludes that he's too lazy to rewrite the relevant parts of the script and style sheet and retest |
| 22:17 | <zcorpan> | what's a browser supposed to do with <details><dt>x<dd>y<dd>z</details>? |
| 22:17 | <zcorpan> | always show z? |
| 22:19 | <annevk42> | zcorpan, either always show z or always show y |
| 22:19 | <zcorpan> | "The first dd element child of the element, if any, represents the details." |
| 22:22 | <zcorpan> | the rendering section will make everything but the first dt element hidden |
| 22:23 | <beowulf> | is jeremy keith not a SuperFriend? |
| 22:23 | <annevk42> | zcorpan, I filed a bug on that |
| 22:23 | <beowulf> | ach, nm |
| 22:26 | <zcorpan> | annevk2: ah. me too :) |
| 22:27 | zcorpan | notes that the rendering section relies on case-insensitivity for attribute value selectors |
| 22:28 | <annevk42> | sigh |
| 22:28 | <annevk42> | maybe we cannot remove that then |
| 22:36 | <zcorpan> | css specs should reference mimesniff |
| 22:39 | <zcorpan> | btw, philipj discovered that code reuse in browsers has caused 'load' and 'error' events to be fired on elements when using e.g. css border-image or video poster |
| 22:48 | Philip` | tries to work out how you're meant to take Opera out of F11-style fullscreen view, when viewing a fullscreen Flash plugin |
| 22:48 | <Philip`> | because the plugin has focus and intercepts the F11 key |
| 22:48 | <Philip`> | and it's fullscreen so there's no browser chrome left to click on and focus :-/ |
| 22:49 | <Philip`> | s/fullscreen Flash plugin/normal embedded Flash plugin which fills 100% of the screen/ |
| 22:51 | <roc> | zcorpan: did anyone file a Mozilla bug on that? |
| 22:53 | <zcorpan> | roc: don't think so |
| 22:54 | <roc> | I actually don't believe we'd fire load on border-image loads |
| 22:54 | <roc> | I believe that we might for poster |
| 22:54 | <zcorpan> | i didn't test border-image in firefox |
| 22:55 | <zcorpan> | but i tested poster and they fired in my build |
| 22:56 | <roc> | I'll file a bug |
| 22:56 | <roc> | thanks |
| 22:56 | <zcorpan> | cool |
| 22:56 | <zcorpan> | i'm going to test all things that load stuff sometime and see if they fire events |
| 22:59 | <zcorpan> | btw, poster also happily shows images with 404 status or text/html mime type |
| 22:59 | <zcorpan> | iirc |
