| 00:01 | <Hixie> | Lachy: a few seconds above 38 is a few seconds under 39 :-P |
| 00:01 | <Hixie> | and i think the conditions include A and B is correct |
| 00:02 | <jgraham> | To clarify, by "marking titles" above, I meant marking them up using <cite> rather than anything to do with <mark> |
| 00:03 | <Hixie> | jgraham: "my favourite book series is <cite>The Night Dawn's Trilogy</cite>." |
| 00:04 | <webben> | the HTML specs have been consistent in making cite mean citation not just title e.g. "The CITE element is used to indicate the title of a book or other citation" (HTML 2.0). "CITE used for citations or references to other sources" (HTML 3.2). |
| 00:04 | <jgraham> | Hixie: So, apart from the italics for visual presentation, why should I care that it's a book title rather than something else? |
| 00:04 | <webben> | it's also worth noting that not all titles are italicized |
| 00:05 | <Hixie> | jgraham: "So, apart from the italics for visual presentation, why should I care that it's emphasis rather than importance?" |
| 00:05 | <webben> | and if one were to restrict cite to titles that happen to be italicized in a particular citation style, it's hard to see any advantage of cite over i |
| 00:05 | <jgraham> | (Do non-visual UAs do something different for <cite> compared to e.g. <i>)? |
| 00:05 | <webben> | I'm not sure what they do. |
| 00:06 | <tantek> | csarven, agreed, the semantic of <mark> is better suited to HTML than a microformat. it sounds like a special purpose <em> element IMHO. |
| 00:07 | <webben> | Probably the most interesting consuming agent to look at would be Zotero, see if they do anything with it. |
| 00:07 | <webben> | (or would like to do anything with it) |
| 00:07 | <jgraham> | Hixie: in the case of something generic like emphasis v importance, I can imagine that there will be a presentational distinction in all media |
| 00:07 | <jgraham> | and many uses |
| 00:08 | <tantek> | jgraham, if a UA knows semantically that something is the name of a book or other such reference, it may be possible for it to look it up in various citation references, or points of viewing/previewing/purchase. |
| 00:08 | <Hixie> | jgraham: i guess the real question is whether we should define "citation" as only something to which more than a passing reference is made, or whether any reference to another work is enough to be considered a citation |
| 00:08 | <jgraham> | tantek: Is that realistic, given how non-unique titles of works are? |
| 00:08 | <webben> | Hixie: Agreed that a big problem with CITE is clarifying what citation is. e.g. not quotation |
| 00:09 | <csarven> | tantek I agree. It appears to me more of an element that is used for visual or interaction then a semantic representation of some content. I can understand the real-world use cases but that tends to get into a gray area IMO |
| 00:09 | <Lachy> | Hixie, the series always said 38 minutes, and most close closer to 38 minutes than to 39 minutes. (There was only one that lasted 38:34 in Chain Reaction, but that extra time was because the planet became a ball of plasma) |
| 00:09 | <tantek> | jgraham, seems to work well enough in practice, humans communicate names of movies, songs, books all the time and are able to get value out of such communication. |
| 00:09 | <Hixie> | jgraham: i would imagine it is realistic in the context of a specific site with some specific JS to do e.g. referrals to amazon |
| 00:09 | <webben> | Note that in academic circles, you cite people as sources not just works. |
| 00:10 | <Hixie> | Lachy: agreed |
| 00:10 | <Lachy> | Hixie, it needs to say "or" instead of "and" because the it only requires one or the other, not both |
| 00:10 | <jgraham> | tantek: It's not clear to me that all things that work well in two-way human-human conversation translate to good UI for browsers |
| 00:10 | <Hixie> | Lachy: (38 is a number in stargate used in much the same way as 47 in startrek) |
| 00:11 | <Hixie> | Lachy: the list includes A and B, i don't say "it can happen if A and B" |
| 00:11 | <tantek> | jgraham, we don't need "all things", just 80/20. no need to boil the ocean. |
| 00:11 | Lachy | covers his ears and starts yelling "NOT LISTENING!" :-) |
| 00:11 | <jgraham> | To me a citation is specifically a work that is drawn on by the current work and should be referenced for background |
| 00:12 | <tantek> | Hixie, is that also true for wormholes between supergates? |
| 00:12 | Lachy | chooses to believe the 38 minute limit can be explained by quantum mechanics |
| 00:12 | <Lachy> | :-) |
| 00:12 | <jgraham> | tantek: Still, I don't recally any of the systems for "helpfully" adding referral links to webpages based on keywords ever hitting anything like an 80/20 point for me |
| 00:12 | <Hixie> | bbl |
| 00:14 | <tantek> | jgraham, true, invisible meta keywords FAIL. visible tags FTW. also human-based folksonomy currently wins over "helpful" AI autotagging. |
| 00:15 | jgraham | -> sleep |
| 00:15 | <csarven> | NLP is trying to solve a much greater problem which probably won't really be solved anytime 'soon' |
| 00:17 | <csarven> | (At least in digital computing) |
| 00:17 | <tantek> | csarven, true. just let the singularity solve the NLP problem. |
| 00:18 | <Hixie> | (sorry, had a shift) |
| 00:19 | <Hixie> | tantek: no iea |
| 00:19 | <Hixie> | Lachy: long story short, it's just an example. :-P |
| 00:20 | <Hixie> | anyway. we clearly must keep <cite>, and since we're keeping it, how to define it is key |
| 00:20 | <webben> | systems referring users to for-pay systems are probably a bit less useful (and of course, a bit more profitable) than something referring users to e.g. a university library resource resolver |
| 00:20 | <Hixie> | i'm not going off for a few hours. got another shfit and then i'm off to the other side of the stage and then to dinner. |
| 00:20 | <Hixie> | bbl. |
| 00:20 | <Hixie> | i'll read any insights you have upon my return :-) |
| 00:21 | <Philip`> | "I also have some <mark>kitten</mark>s" - that makes me wonder whether "<mark>kittens</mark>" would be acceptable (from a cleverer search engine that detects words with the same basic meaning, rather than doing substring matches, and it might get <mark>young cat</mark> too) |
| 00:23 | <Philip`> | (I believe it is perfectly acceptable, but the example makes me wonder anyway, so maybe the example could say <mark>kittens</mark> to be clear that it's not meant to be strict about anything) |
| 00:23 | <webben> | it's intriguing folks aren't sure CITE is 100% semantically appropriate for citations in zotero's output: http://forums.zotero.org/discussion/2169/ |
| 00:24 | <webben> | http://en.wikipedia.org/wiki/Template_talk:Citation also interesting |
| 00:25 | <Philip`> | "<pre><code>int x = 1<mark></mark></code></pre> Error: expected semicolon; got EOF" - I guess that wouldn't work, which seems a problem if you want to use this for highlighting sections of code |
| 00:28 | <Philip`> | Is it safe to copy xkcd text without being affected by Creative Commons? |
| 09:59 | <annevk> | jwalden, the security section already deals with cross-origin stuff |
| 09:59 | <annevk> | jwalden, also for setting fillStyle and strokeStyle |
| 10:01 | <jwalden> | sure; it doesn't, however, say that drawImage with a different-origin image should not throw |
| 10:02 | <Philip`> | Is it not possible to access the .complete of a different-origin image? |
| 10:03 | <annevk> | jwalden, it does |
| 10:04 | <jwalden> | where? |
| 10:04 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#security1 |
| 10:05 | <jwalden> | that just says origin-clean is set to false, not that it doesn't throw |
| 10:05 | <annevk> | oh right, sorry |
| 10:05 | <annevk> | why should drawing fail? |
| 10:05 | <annevk> | there's no risk there |
| 10:07 | <jwalden> | it can draw or not draw depending on whether the resource is a valid image, it just seems reasonable to say you shouldn't be able to differentiate the two for a different-origin image |
| 10:07 | <jwalden> | .complete doesn't say anything about origins |
| 10:07 | <jwalden> | which might make the concern moot, now that you mention it |
| 10:07 | <annevk> | onerror fails for non same-origin images too |
| 10:07 | <annevk> | euh, fires |
| 10:07 | <annevk> | s/fails/fires/ |
| 10:09 | <jwalden> | hrm |
| 10:09 | <jwalden> | so basically, worrying about this is probably not worthwhile, I guess |
| 10:10 | <annevk> | yeah |
| 10:11 | <annevk> | certainly <canvas> wouldn't be the place to fix the issue |
| 14:25 | <annevk> | for 'setAttribute(a, v1); v2 = getAttribute(a)' v1 != v2 when a is style in Gecko (for some values of v1) |
| 14:26 | <annevk> | oops |
| 14:36 | <hendry> | anyone going to www2008.org in Beijing? i need some motivation |
| 14:37 | <annevk> | my manager prolly |
| 14:38 | <annevk> | aka chaals |
| 14:38 | <Lachy> | annevk, do you know if comments like this one, which don't require any action, need to be recorded in the disposition of comments? http://lists.w3.org/Archives/Public/public-webapi/2008Jan/0021.html |
| 14:39 | <annevk> | explicit endorsement is never bad, i'd add it |
| 14:41 | <Lachy> | done |
| 14:48 | <Lachy> | I wonder how I can deal with this comment http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0104.html |
| 14:49 | <Lachy> | I don't know what the spec should say about the issue |
| 14:49 | <Lachy> | of NSResolver mutating the DOM |
| 14:51 | <Lachy> | I wonder if I could say that, due to the possibility of the NSResolver mutating the DOM, that all prefixes must be resolved before looking for matching elements |
| 14:52 | <Lachy> | that way, if NSResolver did modify the dom, then all modifications would have occurred before the UA began looking |
| 14:55 | <annevk> | " |
| 14:55 | <annevk> | Now maybe you're actually requiring that the number of calls to the NSResolver |
| 14:55 | <annevk> | for any given selector and initial DOM tree is bounded in the face of all |
| 14:55 | <annevk> | possible mutations by the NSResolver and that hence the DOM will at some point |
| 14:55 | <annevk> | stabilize and it will be possible to return the things the spec requires be |
| 14:55 | <annevk> | returned. But if that's a constraint you want to place on implementations, you |
| 14:55 | <annevk> | should probably spell it out clearly." |
| 14:55 | <annevk> | is what I think the spec already says |
| 14:55 | <annevk> | but we could add a paragraph that spells it out clearly |
| 14:55 | <hendry> | annevk: met charges at MWC2008 in Barcelona, aka HELL |
| 14:55 | <annevk> | Lachy, indeed |
| 15:03 | <Philip`> | Lachy: s/exersise/exercise/ in the note about case-mapping |
| 15:04 | <Lachy> | fixed |
| 15:21 | <Lachy> | annevk, how does this sound: |
| 15:21 | <Lachy> | Elements returned by these methods must include only matching Element nodes, which were present in the document after all namespaces that the implemented needed to resolve, have been resolved. |
| 15:21 | <Lachy> | Note: This is to ensure that any DOM modifications performed by a misbehaving namespace resolver have occurred prior to matching any elements. |
| 15:21 | <Lachy> | s/implemented/implementation/ |
| 15:23 | <Philip`> | The first sentence doesn't sound right - if someone queried for "a b" then the resolver moved the 'b' outside the 'a' (but kept it present in the document elsewhere), it's not clear that it shouldn't be matched |
| 15:24 | <hendry> | s/charges/chaals/ woops |
| 15:26 | <Lachy> | Philip`, then it would no longer be a matching element node |
| 15:28 | <Lachy> | I'm not sure how I can make it any clearer. Elements are only determined to match at the they are evaluated with the selector |
| 15:28 | <Philip`> | It was a matching element node (before the resolving), so it is one of the matching nodes which is still present in the document |
| 15:28 | <Lachy> | but the implementation wouldn't know that it was matching until it started looking for it |
| 15:28 | <Philip`> | *still present in the document after the resolving |
| 15:32 | <Lachy> | hmm. I just realised my current defintions of element.querySelector require the matching elements to be within the document, but that wouldn't be the case if the element itself wasn't in the document |
| 15:33 | <Lachy> | oh, no they don't |
| 15:33 | <Lachy> | I misread it |
| 15:34 | <Philip`> | "'Matching Element nodes' are the Element nodes that match after all NSResolver calls have been made" or something like that? |
| 15:35 | <Philip`> | Incidentally, "The implementation must process the selectors according to the grammar of Selectors ([Selectors], section 10)." should have small-caps "must" |
| 15:35 | <Philip`> | (as should "the implementation must act as if the nsresolver argument was set to null") |
| 15:46 | <Lachy> | fixed |
| 15:47 | <annevk> | Lachy, I'm away for a while, just check in what you think is appropriate, i'll try to scream whenever it's not :p |
| 15:50 | <Lachy> | Elements returned by these methods must include only Element nodes that are present within the document or the element’s subtree that match the group of selectors after all namespaces that need to be resolved by the implementation, have been resolved. |
| 15:51 | <Lachy> | Philip`, how's that now? |
| 15:51 | <Lachy> | s/subtree that/subtree and/ |
| 15:52 | <Lachy> | this is the corrected version: |
| 15:52 | <Lachy> | Elements returned by these methods must only include Element nodes that are present within the document or the element’s subtree, and match the group of selectors after all namespaces that need to be resolved by the implementation, have been resolved. |
| 15:55 | <jgraham_mibbit> | Lachy: I think your commas are in the wrong places |
| 15:56 | <jgraham_mibbit> | Actually I just think that the last comma is wrong |
| 15:56 | <jgraham_mibbit> | (i.e. you should delete it) |
| 15:57 | <Lachy> | ok |
| 16:04 | <Lachy> | hmm. I need to think about this some more. I'm not sure if it completely addresses Boris' comment |
| 16:07 | <Philip`> | Lachy: Sounds reasonable to me now |
| 16:19 | <zcorpan> | should the presence of a ::selection rule set supress the default styles for selections? |
| 16:20 | <zcorpan> | s/rule/ruleset/ |
| 16:21 | <othermaciej> | zcorpan: I think it's browser-specific how they combine |
| 16:25 | zcorpan | thinks it should be defined |
| 16:34 | <othermaciej> | zcorpan: the expected model would be different if the default selection style is something that can be itself achieved through style rule vs. if it is a totally custom rendering of some kind |
| 16:35 | <Philip`> | ::selected { display: none } /* Anti-Copy-And-Paste Script, copyright 2008 www.coolscripts.com */ |
| 16:36 | <zcorpan> | currently both opera and firefox supress default styles in the presence of ::selection (or ::-moz-selection) |
| 16:36 | <zcorpan> | Philip`: display doesn't apply |
| 16:36 | <Philip`> | Oh |
| 16:36 | <zcorpan> | Philip`: or it's not required to apply |
| 16:36 | <othermaciej> | the selection pseudo-element allows a limited set of style properties |
| 16:37 | <othermaciej> | in Safari, I think the background drawing still happens unless you explicitly suppress it |
| 16:37 | <Philip`> | ::selected { color: expression(alert("Anti-Copy-And-Paste!")) } |
| 16:38 | <zcorpan> | supressing the default styles is different from how css usually works, so not what i had expected |
| 16:40 | <zcorpan> | oh wait, opera doesn't supress unless there's a color or background property, it seems |
| 16:43 | <othermaciej> | Safari models it as a magical background-color property basically, although there isn't an explicit rule for it in html4.css |
| 16:44 | <hsivonen> | othermaciej: does Apple disclose the mechanism of Safari content blocking when parental controls are enabled? |
| 16:45 | <othermaciej> | hsivonen: I'm not sure |
| 16:45 | <hsivonen> | othermaciej: ok |
| 16:45 | <othermaciej> | hsivonen: I believe the parent can set up a whitelist via bookmarks, but I don't know if there is more to it |
| 16:47 | <hsivonen> | othermaciej: there seems to be a middle setting where magic is supposed to happen in addition to parent-controlled white and blacklists |
| 16:47 | <hsivonen> | othermaciej: unlike IE, Safari doesn't say what the magic is |
| 18:47 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=151 |
| 19:06 | <Lachy> | I don't think introducing even more entities is a good idea |
| 19:17 | <h3h> | so I'm trying to come up with the most reasonable/portable way to represent this data as HTML: http://h3h.net/images/data-representation-01.png |
| 19:18 | <h3h> | I think a DL matches somewhat, so this would be good: http://pastie.caboo.se/153841 |
| 19:18 | <h3h> | but I can't think of a way to style that reliably |
| 19:19 | <jwalden> | if you care about portability, I think you lose; I'm not sure how you'd work with that other than with ~ or + selectors |
| 19:19 | <h3h> | right. even then, separating the dt/dd+ blocks from one another is near impossible |
| 19:19 | <h3h> | so I guess each data block has to be its own table or dl |
| 19:20 | <h3h> | supremely disappointing |
| 19:21 | <jwalden> | <div><h3>Members</h3><div>stuff [<br /> more stuff]</div></div> or something |
| 19:21 | <h3h> | yeah, but then I have the same sibling grouping problem |
| 19:22 | <Lachy> | h3h, looks like a job for nested tables :-) |
| 19:22 | <h3h> | tables really don't work because they assume a specific row/column layout |
| 19:22 | <jwalden> | .outer > .inner { } .outer > .header { } ? |
| 19:22 | <h3h> | in this case I just have header:data groupings |
| 19:22 | <h3h> | which could be displayed vertically, horizontally, or otherwise |
| 19:23 | <Lachy> | then dl/dt/dd might be appropriate, though may be difficult to achieve the intended style |
| 19:23 | <h3h> | so it would have to be more like <div class="stats"><div class="stat"><h3>Header</h3><p>data</p></div> <div class="stat"><h3>Header 2</h3><p>data 2</p></div> ...</div> |
| 19:23 | <h3h> | which is disgusting, frankly |
| 19:24 | <h3h> | yeah, I think I'm going to have to go with a new DL for each one |
| 19:24 | <jwalden> | it's web development :-) |
| 19:24 | <h3h> | less terrible than the alternatives |
| 19:25 | <h3h> | it's like I want the semantics of a "table row" (which can contain a header and one or more data elements) without the notion of an actual row |
| 19:26 | <h3h> | the simplest table markup would be perfect if I could style it vertically |
| 19:27 | <h3h> | table-layout: transposed; or something :) |
| 19:30 | <h3h> | actually, I might be able to pull that off... |
| 19:40 | <h3h> | hah: http://paste.css-standards.org/32610/view |
| 19:40 | <h3h> | though it displays upside down in Safari |
| 19:42 | <h3h> | and sideways in IE |
| 19:42 | <h3h> | Firefox and Opera get the prize for simplest reverse engineering of default styles |
| 19:56 | <SadEagle> | h3h: try making it strict |
| 19:56 | <h3h> | hm good point |
| 19:57 | <h3h> | ah nice shooting. works fine with strict |
| 19:58 | <h3h> | in Safari |
| 19:58 | <h3h> | IE still sucks of course |
| 19:58 | <Dashiva> | Would you have it any other way? |
| 19:58 | <h3h> | :( |
| 20:23 | <Hixie> | othermaciej lives! |
| 20:23 | <othermaciej> | hello Hixie |
| 20:23 | <othermaciej> | I've been on vacation the past week |
| 20:23 | <othermaciej> | back now |
| 20:23 | <Hixie> | so i heard |
| 20:24 | <Hixie> | you might be interested in http://hixie.ch/specs/dom/messages/0.9 and http://hixie.ch/specs/dom/workers/0.9 |
| 20:24 | <Hixie> | once you've dealt with your e-mail |
| 20:24 | <jruderman> | Hixie: are you serious about "The eyes go orange if you view the test zoomed in or zoomed out: This is a bug."? |
| 20:24 | <jruderman> | see https://bugzilla.mozilla.org/show_bug.cgi?id=418235#c6 |
| 20:25 | <jruderman> | expecting that transparency offset thing to work when zoomed seems a bit much |
| 20:29 | <roc> | so Hixie's saying that image scaling algorithms that use any kind of interpolation are not allowed? |
| 20:31 | <Hixie> | it's certainly suboptimal |
| 20:32 | <Hixie> | one could imagine a perfect UA that rendered all the graphics at 1:1, then scaled the composited graphic down |
| 20:32 | <Hixie> | and then overlapped the text on top of that |
| 20:32 | <Hixie> | i'm not saying that's necessarily even remotely easy or likely to ever be implemented |
| 20:33 | <roc> | actually that is feasible, it's full-screen antialiasing |
| 20:33 | <roc> | but it |
| 20:33 | <roc> | 's expensive |
| 20:33 | <Hixie> | i'm sure |
| 20:34 | <Hixie> | but it's hard to argue that it's not what is intended by the author :-) |
| 20:34 | <jruderman> | hopefully this issue doesn't come up much in real-world web pages :) |
| 20:34 | <Hixie> | probably comes up more than you'd like, and less than makes it worth it :-) |
| 20:35 | <roc> | well, in this case we might wilfully ignore the author's intent since interpolation produces good results for real Web pages |
| 20:35 | <roc> | as in, I haven't seen a real bug filed related to this |
| 20:36 | <Hixie> | well we haven't shipped zoom yet :-) |
| 20:37 | <roc> | true, and IIRC only Mac builds use interpolation |
| 20:37 | <roc> | but still, there are something like 300K active beta3 users |
| 20:39 | <Hixie> | rue |
| 20:39 | <Hixie> | true |
| 20:41 | <Hixie> | like i said, i doubt that it's worth fixing |
| 20:41 | <Hixie> | bbl |
| 21:54 | <hsivonen> | hmm. now internationalization and accessibility & ethics are at odds: http://lists.w3.org/Archives/Public/www-archive/2008Feb/0030.html |
| 21:56 | <annevk> | i've given up reading through his replies |
| 21:58 | annevk | wonders how fast his note about <object> will cause a stirr |
| 21:59 | Dashiva | wonders if annevk did it on purpose |
| 21:59 | <annevk> | well, I did want to point out that his point of view has caused issues in the past, but I didn't want to say too much |
| 22:00 | <annevk> | I think it's rather well put, but probably only if you agree with my line of thought |
| 22:03 | <hsivonen> | annevk: well, gotta love a situation where one way leads to getting accused of breaking accessibility and the other would lead to accusations of breaking internationalization |
| 22:05 | <annevk> | It's hard for me to see what his real issue is. That some browsers are still broken? |
| 22:06 | <hsivonen> | annevk: so I gather from his feedback |
| 22:06 | <annevk> | ok, so I did read the important parts |
| 22:06 | <hsivonen> | of course, it is well-known that there are older versions of IE still out there that don't support IDN |
| 22:06 | <hsivonen> | but IE7 supports IDN, right? |
| 22:06 | <annevk> | guess first sentence/last sentence, first paragraph/last paragraph, might be applicable to e-mail too |
| 22:06 | <annevk> | hsivonen, yeah |
| 22:07 | <annevk> | they also experimented with IDN for e-mail I believe |
| 22:07 | <jgraham> | annevk: I think you're probably right about aria-* and <object>, at least from the pov of author confusion. I can't imagine any spec that forces us to deal with <label for="a">foo</label> <span id="b">bar</span> <input id="a" aria-labelledby="b"> is going to be easy for authors to understand |
| 22:08 | <annevk> | "well, if the OBJECT model failed, it was due to lousy implementation decisions" |
| 22:08 | <Dashiva> | Ouch: "Some weeks ago you quoted an ISO standard I haven't heard of before for your definition of "valid". If that ISO standard has "congruent de facto guidance" in its definition trash it or maybe put it where you have DIS 29500." |
| 22:08 | <hsivonen> | jgraham: I happen to have a use case for having an input labeled by a <select> :-) |
| 22:08 | <annevk> | score |
| 22:09 | <hsivonen> | jgraham: and <label> doesn't work due to the association by containment legacy misfeature |
| 22:09 | <annevk> | it's questionable whether you should use <select> there though or three separate forms |
| 22:10 | <annevk> | i guess both approaches are ok somehow |
| 22:11 | <jgraham> | hsivonen: I don't think all the features are bad, just that making it all easy to understand will be tough |
| 22:12 | <annevk> | pretty clear that HD DVD is dead now |
| 22:12 | <annevk> | glad I didn't buy this Xbox add-on |
| 22:42 | <aroben> | hsivonen: do I remember hearing that you have some doctype parsing tests? |
