| 00:00 | <Lachy> | with the current spec, only the last simple selector in the sequence needs to match an element within context, whereas all others can match any ancestors or previous siblings (depending on the combinators) |
| 00:00 | <Philip`> | JohnResig: Just in case it's of any interest: Of those 130K pages, http://philip.html5.org/misc/jquery-pages.txt lists the ones matching /<script[^>]*jquery/ |
| 00:00 | <JohnResig> | Philip`: neat - thanks! |
| 00:00 | <Hixie> | ":scope>*" isn't a valid use case for this, that's what the element traversal stuff is for |
| 00:01 | <JohnResig> | Hixie: but :scope > div.foo.bar[baz] is totally valid here |
| 00:01 | <Hixie> | yeah, what's the page that does that? |
| 00:02 | <Hixie> | most seem to just do a single simple selector chain |
| 00:02 | <Hixie> | or whatever the term is these days |
| 00:02 | <Lachy> | Philip`, I only used * in :scope>* because I was referring to the general case |
| 00:02 | <Hixie> | no combinators, i mean |
| 00:02 | <Philip`> | Lachy: s/Philip`/Hixie/ ? |
| 00:02 | <Hixie> | oh |
| 00:02 | <JohnResig> | here's one with at least two: jQuery(element.form || document).find('[@name=' + element.name + ']:checked') |
| 00:03 | <Hixie> | that would work fine |
| 00:03 | <Hixie> | there's no combinator there |
| 00:03 | <Lachy> | Hixie, there are a couple that I have seen using .find(">x") |
| 00:03 | <Hixie> | Lachy: interesting syntax |
| 00:03 | <Lachy> | yeah, it's the equivalent to ":scope>x" |
| 00:04 | <Hixie> | right |
| 00:04 | <Lachy> | and it's the one I'm not sure how to solve without :scope |
| 00:04 | <Hixie> | seems like most of them don't do this |
| 00:04 | <Hixie> | which would suggest it's not a high prioprity |
| 00:04 | <JohnResig> | jQuery("> tbody:first/tr",o).find("> td:eq(" + COLUMN_LAST_INDEX + ")") |
| 00:04 | <Hixie> | priority |
| 00:04 | <JohnResig> | Hixie: they don't do it because it's slow - the point of this whole new API is to make it fast |
| 00:05 | <JohnResig> | if we're not striving to make things faster - that pure JS can't make faster - then there's really no point |
| 00:05 | <Hixie> | this data suggests many people use the api, just not with combinators |
| 00:05 | <Hixie> | i've no idea what "tbody:first/tr" is supposed to match |
| 00:05 | <Lachy> | nor do I. |
| 00:05 | <Hixie> | but it certainly won't work with the api anyway, so that again isn't an argument in favour of this |
| 00:05 | <Hixie> | i have to go to another building, but i'll be on irc again briefly |
| 00:06 | <Hixie> | s/briefly/momentarily/ |
| 00:06 | <JohnResig> | sure it is - we support some simple XPath expressions - we map them to CSS before parsing |
| 00:06 | <Lachy> | ok, so it tbody/tr the same as "tbody tr" or "tbody>tr"? |
| 00:06 | <JohnResig> | "tbody>tr" |
| 00:07 | <Philip`> | How would you do :eq with the Selectors API? |
| 00:08 | <JohnResig> | Philip`: we wouldn't - we'd have to fall back - which is why I've been arguing for good error reporting so that we can actually fallback gracefully |
| 00:11 | <Philip`> | Is this almost like Array.forEach(o.querySelector('tbody').querySelectorAll('tr'), function (tr) { var td = tr.querySelectorAll('td')[COLUMN_LAST_INDEX]; foo(td) }) ? |
| 00:11 | <Lachy> | JohnResig, without :scope, how would you propose the API work to find child nodes of the context node in the following scenario? |
| 00:11 | <Philip`> | (Oh, except that won't work with nested tables) |
| 00:12 | <JohnResig> | Philip`: roughly, yeah - it would seem! |
| 00:12 | <Lachy> | <div id=foo>A <div>B <div>C</div> B</div> A</div> |
| 00:13 | <JohnResig> | Lachy: without scope, just look for the front-leading >. I'm not really sure what the purpose of introducing :scope is if there's only one combinator that it'll work on |
| 00:13 | <Lachy> | with foo.querySelectorAll("..."); how would you find all child divs (the ones labelled B) |
| 00:13 | <Philip`> | After the querySelector('tbody'), it wants some way to find all the <tr>s that are direct children of that particular <tbody> (and not e.g. children of a tbody which is a descendant of that first tbody) |
| 00:13 | <Lachy> | because ">div" is an invalid selector |
| 00:13 | <JohnResig> | Lachy: unless it's defined to be valid |
| 00:13 | <Lachy> | and allowing that would require redefining the selector syntax |
| 00:14 | <JohnResig> | Lachy: new syntax is already being defined with :scope - it's not a leap of imagination |
| 00:14 | <Lachy> | the difference is :scope doesn't require chaning the grammar |
| 00:14 | <Lachy> | it's just another pseudo class |
| 00:15 | <jgraham_> | FWIW selectors like ">div" strike me as a bad idea |
| 00:15 | <othermaciej> | Lachy, JohnResig: since you're both here... |
| 00:15 | <othermaciej> | I was going to suggest on the list that there could be queryScopedSelector() |
| 00:15 | <JohnResig> | Lachy: but yeah, with the current spec, it's impossible to reliably find the <div>B one |
| 00:15 | <othermaciej> | which implicitly prepends ":scope " |
| 00:16 | <othermaciej> | and that might be what JS libraries want to use |
| 00:16 | <JohnResig> | othermaciej: I'd contend that it's what users want to use |
| 00:16 | <othermaciej> | at least that would clarify that it is using a different notion of a "scoped selector" instead of standard slector grammar and semantics |
| 00:16 | <othermaciej> | JohnResig: is that feedback in favor of or against my suggestion? |
| 00:17 | <JohnResig> | othermaciej: I think it's fine if it's implied - I just think that querySelectorAll should do that to begin with. |
| 00:17 | <Lachy> | othermaciej, are you suggesting that .queryScopedSelector(">div") implicitly becomes ":scope >div"? |
| 00:18 | <Philip`> | Does HTML5's <style scoped> have exactly the same issues? |
| 00:18 | <othermaciej> | Lachy: yes |
| 00:18 | <Lachy> | Philip`, yeah, introducing :scope addresses use cases for that too |
| 00:18 | <JohnResig> | othermaciej: I'm also assuming that there'd be .queryScopedSelectorAll and .queryScopedSelector? |
| 00:18 | <othermaciej> | Lachy: similarly, queryScopedSelector("div") becomes queryScopedSelector(":scope div") |
| 00:19 | <othermaciej> | Lachy: sorry, just querySelector the second time |
| 00:19 | <othermaciej> | JohnResig: presumably, yes |
| 00:20 | <othermaciej> | JohnResig: the de facto syntax for selectors supported by JS library query APIs does not match standard selectors, and I am not sure changing the core selector syntax is the way to go, but I think this could be a plausible workaround that gives a simple well-defined notion of a "scoped selector" |
| 00:20 | <othermaciej> | with grammar and semantics that better match JS libraries |
| 00:21 | <othermaciej> | of course there is still the fact that JS libraries support some extensions that CSS3 Selectors expressly forbids, which maybe should be handled by extending Selectors (things like ":not(a > b)") |
| 00:21 | <othermaciej> | I'm not sure what all the differences are |
| 00:23 | <Lachy> | I guess there's one advantage to introducing a separate method is that is allows libraries to test for it like: if (element.queryScopedSelector) {... } |
| 00:23 | <JohnResig> | I'm just completely confused as to why this wasn't done in the first place - and why it's not the default. Alternatively, I'd like to propose that querySelectorAll("selector") be equivalent to .queryGlobalSelector(":scope selector") (changing the primary querySelectorAll method to actually match precedence) |
| 00:24 | <othermaciej> | JohnResig: we had lots of input from UA implementors and CSS experts, but not so much from JS library authors or AJAX developers, when drafting the spec |
| 00:25 | <JohnResig> | :-| |
| 00:25 | <othermaciej> | so I think everyone assumed that normal selector syntax and semantics were what is desired |
| 00:25 | <Lachy> | I certainly assumed that |
| 00:25 | <Lachy> | while I was aware of the problem, I wasn't aware it was such a priority |
| 00:25 | <Lachy> | and assumed that it could be safely left to v2 and solved with :scope |
| 00:27 | <othermaciej> | in fact queryScopedSelector could even be defined without Selectors defining ":scope" first, because it could say it acts as if an unspecified simple selector uniquely matching the scope element is prepended |
| 00:28 | <othermaciej> | (I guess to each selector in a group of selectors, not just stringwise) |
| 00:28 | <othermaciej> | (since you want comma to work as expected) |
| 00:28 | <othermaciej> | so UAs could use an arbitrary mechanism to achieve that, and ":scope" can be added to the CSS Selectors spec later |
| 00:30 | <Lachy> | ok, I'll think about it. |
| 00:30 | <JohnResig> | othermaciej: it seems like it would be better to not overload that method and, instead, provide a primary filtering method .filterSelector("div.class") |
| 00:30 | <JohnResig> | othermaciej: of course, that's more useful if the method also exists on DOMNodeLists |
| 00:31 | <Lachy> | I'm not sure how .filterSelector would work on anything but NodeLists |
| 00:31 | <othermaciej> | for NodeLists you obviously can't support scoped selectors |
| 00:31 | <Lachy> | but then, as I wrote in the email, I really need to see the use cases for it |
| 00:32 | <othermaciej> | I'm not sure what filterSelector does |
| 00:32 | <Lachy> | indeed. .filterSelector() would have to use the global context |
| 00:32 | <Lachy> | othermaciej, it takes a NodeList and evaluates the selector against the element in the context of the document |
| 00:33 | <Lachy> | and returns all matching elements |
| 00:33 | <othermaciej> | that's sorta the same thing as querySelectorAll, as currently defined |
| 00:33 | <othermaciej> | isn't it? |
| 00:34 | <Lachy> | it's not quite, but the reason I need use cases for it is because I can't see what it can solve that querySelectorAll can't |
| 00:35 | <othermaciej> | is it that it can only match immediate children? |
| 00:36 | <othermaciej> | I guess thinking about it, querySelectorAll on a NodeList seems kind of weird |
| 00:36 | <othermaciej> | when would you want to do selector matching on a list of DOM subtrees? |
| 00:36 | <Lachy> | ok, so the advantages for queryScopedSelector/queryScopedSelectorAll() are: 1. Doesn't break the existing API, 2. Can be tested for by scripts, 3. Doesn't depend upon :scope being defined immediately |
| 00:36 | <othermaciej> | seems more likely you'd want to do it on a list of actual nodes |
| 00:37 | <Lachy> | othermaciej, I think your interpretation of how it would work is different from mine |
| 00:38 | <Lachy> | or I'm not sure what you meant by "selector matching on a list of DOM subtrees?" |
| 00:38 | <othermaciej> | Lachy: I am not sure how you see it working either |
| 00:38 | <Lachy> | ok, consider this: |
| 00:38 | <othermaciej> | I am drawing conclusions based on you saying filterSelector and querySelector all would be different |
| 00:38 | <othermaciej> | here is what I assumed the difference is: |
| 00:38 | <Lachy> | var list = document.getElementsByTagName("div"); |
| 00:38 | <othermaciej> | filterSelector - can only match items actually in the node list, not their descendants |
| 00:39 | <Lachy> | var list2 = list.filterSelector(".foo"); |
| 00:39 | <othermaciej> | querySelectorAll - can match items in the node list, or any of their descendants |
| 00:39 | <Lachy> | list 2 contains all the divs from the first list that had a class of foo |
| 00:39 | <Lachy> | basically, the result is the same as querySelectorAll("div.foo") |
| 00:39 | <othermaciej> | that seems to match my interpretation of filterSelector |
| 00:39 | <Lachy> | which is useless |
| 00:40 | <Lachy> | ok, good |
| 00:40 | <othermaciej> | Is my understanding of how NodeList.querySelectorAll would differ correct? |
| 00:41 | <othermaciej> | I can see how you could do things with filterSelector + querySelectorAll that can't be done with just QSA |
| 00:41 | <Lachy> | I assumed they would were just different possible names for the same thing. |
| 00:41 | <othermaciej> | for instance: |
| 00:41 | <Lachy> | I didn't think there were 2 separate suggestions |
| 00:42 | <othermaciej> | var list = document.querySelectorAll("div *") |
| 00:42 | <othermaciej> | var list2 = list.filterSelector("section *") |
| 00:42 | <othermaciej> | list 2 is all elements contained in both a div and a section, in either order |
| 00:42 | <othermaciej> | no, I guess I am wrong |
| 00:43 | <othermaciej> | you could instead query for "div section *, section div *" |
| 00:43 | <Lachy> | oh yeah, that's right. It's sort of like the :matches() proposal in Selectors |
| 00:43 | <othermaciej> | but with many independent conditions you could get a huge explosion of selector length |
| 00:43 | <othermaciej> | and maybe some trickier case is not trivially convertible to a group of two selectors |
| 00:44 | <Lachy> | yeah, I'm sure there are some rather complicated cases that it could simplify. But are there any such use cases that people are actually attempting? |
| 00:44 | <othermaciej> | you might also want to do foo.childNodes.filterSelector(), but queryScopedSelectorAll could do that |
| 00:44 | <othermaciej> | I dunno |
| 00:44 | <othermaciej> | I am just trying to understand it |
| 00:54 | <Lachy> | I think that would mean foo.queryScopedSelectorAll("div").filterSelector("section *"); would be equivalent to foo.querySelector("section div"); |
| 00:55 | <othermaciej> | Lachy: I think that's right |
| 00:58 | <Lachy> | queryScopedSelector() would need to prepend ":scope " (or equivalent magical selector) to evey sequence of simple selectors, so "strong, em" became ":scope strong, :scope em" |
| 00:59 | <othermaciej> | right |
| 01:02 | <Lachy> | ok, I've got a lot too think about and a lot more to do. I have to find out if IE, Mozilla and Opera would be willing and able to implement queryScopedSelector, then define it, and still evaluate whether or not it really is the best solution to go for |
| 01:15 | <hasather> | Hixie: seen this: http://xiphmont.livejournal.com/31209.html |
| 01:36 | <Lachy> | queryScopedSelector() won't work as easily as I initially thought. :-( |
| 01:36 | <Lachy> | Consider this: |
| 01:37 | <Lachy> | foo.queryScopedSelector(">strong, >em"); |
| 01:38 | <Lachy> | I would basically need to define a special grammar for selectors used in this method in a way that is compatible with normal selectors, and doesn't break forwards compatibility |
| 01:38 | <Lachy> | it's basically a complete nightmare |
| 01:41 | <Hixie> | hsivonen: that doesn't look like the kind of stuff i'd write |
| 01:41 | <Hixie> | i don't even known how to spell antithesis |
| 01:43 | <kevogod> | I remember reading something about that months ago. |
| 01:44 | <kevogod> | http://64.233.167.104/search?q=cache:VvbdPyHxdxAJ:ventnorsblog.blogspot.com/2008/04/rated-p-for-proprietary.html%3FshowComment%3D1209354480000+The+distinction+between+the+video+format+war+and+the+browser+war&hl=en&ct=clnk&cd=2&gl=us&client=firefox-a |
| 01:44 | <Hixie> | yeah i just posted a link to that |
| 01:44 | <kevogod> | Oh, sorry. |
| 01:45 | <kevogod> | I am curious how "Michael" became Hixie. |
| 01:46 | <Lachy> | Hixie, I was wondering why the article implied you no longer had a blog. |
| 01:58 | <Philip`> | kevogod: The keys are like right next to each other |
| 01:58 | <kevogod> | Philip`, True, I can see how the mistake was made. |
| 05:28 | <Facedown> | positioned elements (other than static) have a higher stacking order than floated non-positioned elements (z-index not explicitly set) , dont they? |
| 06:07 | <roc> | yes |
| 06:13 | <Facedown> | have you run into any IE specific issues where IE does not honor the rightful stacking order, roc? |
| 06:13 | <roc> | IE treats z-index:auto as z-index:0 IIRC |
| 06:13 | <roc> | not sure about any other stacking order bugs |
| 06:14 | <roc> | I hardly ever use IE :-) |
| 06:14 | <Facedown> | no self proclaimed web dev would ever personally use it.. but clients.. |
| 06:14 | <roc> | I work on Firefox. I don't have clients :-) |
| 06:15 | <Facedown> | heh |
| 09:14 | <hsivonen> | I wish we could magically make CRLF disappear |
| 09:22 | <Facedown> | what's CRLF? |
| 09:22 | <Facedown> | \r\n ? |
| 09:23 | <Facedown> | carriage return line feed? |
| 09:30 | <hsivonen> | Facedown: yes. It's evil. |
| 10:12 | <jgraham_> | Sigh. Nice of Daniel to post such a well argued, non-inflammatory addition to the alt thread |
| 10:32 | <Lachy> | oh, yeah, cause arguments like "making alt optional in HTML 5 is ridiculous" is exactly the kind of short and to the point arguments we need. |
| 10:47 | jgraham_ | ponders the recursive nature of making non-conformance conforming |
| 11:15 | <hsivonen> | hmm. perhaps I should just do a preflight on each buffer to get rid of CRLF instead of making the rest of the tokenizer really complex in order to avoid the preflight |
| 11:16 | <hsivonen> | I don't usually admit to hating things, so I seriously dislike CRLF |
| 11:30 | <jgraham_> | hsivonen: IIRC we strip out CRLF when we buffer the data |
| 11:31 | <jgraham_> | (and have a flag to indicate trailing CR in case CRLF is split over two buffers) |
| 18:40 | <jgraham_> | So Nvu/KomoZer adds alt="" even when you specify "Don't add alternate text" |
| 18:42 | <jgraham_> | And adds alt="image filename" if you drag and drop an image file in |
| 18:42 | <jgraham_> | s/KomoZer/KompoZer/ |
| 18:42 | <jgraham_> | Which clearly sucks |
| 18:58 | <Philip`> | Maybe it'd be vaguely informative to correlate alt usage with <meta name=generator> values |
| 19:27 | <Facedown> | what's the best ftp client anyone here has ever used? (on windows preferably)? filezilla 3 is a memory hog like firefox.. slow as shit |
| 19:32 | <Philip`> | I use Krusader (on Linux) |
| 20:51 | <Hixie> | i wonder why the alt="" people aren't screaming about <object></object> |
| 20:52 | <Hixie> | which is even worse since it doesn't distinguish between unknown important image and decorative image |
| 20:52 | <Philip`> | Probably because nobody uses <object> decoratively |
| 20:53 | <jgraham_> | Probably because nobody uses <object> for images |
| 20:53 | <Philip`> | and theoretical problems aren't worth worrying about |
| 20:53 | <Hixie> | well then shouldn't they be arguing that <object> must never be empty? |
| 20:53 | <Hixie> | what i find interesting is that the longer this argument goes on, the more people are coming out and defending what the spec says |
| 20:53 | <Philip`> | jgraham_: I use <object> for images, at least twice in my life :-) |
| 20:53 | <Philip`> | although actually one of those was purely decorative |
| 20:54 | <jgraham_> | OK "nobody" for large values of "nobody" |
| 20:55 | <Philip`> | Hixie: That's because people flock to authority, which the spec provides, rather than considering the technical arguments ;-) |
| 20:56 | <Lachy> | I used <object> for an image once, and I put an <img> inside it as fallback :-) |
| 20:56 | <Philip`> | Lachy: And an alt on the image as fallback? |
| 20:56 | <Lachy> | yes |
| 20:56 | <Hixie> | Philip`: if anyone is being an authority here it's the self-proclaimed accessibility experts who announce their opinions as unquestionable |
| 20:56 | <jgraham_> | I am quite tempted to say why I think that the Nvu UI encourages bad alt text and required alt encourages Nvu-like UI. But if I do that it will be taken badly... |
| 20:57 | <Philip`> | The logo on http://canvex.lazyilluminati.com/ does <h1><object><img alt></...> |
| 20:57 | <Philip`> | which is hopefully sane |
| 20:57 | <Lachy> | IMHO, Nvu is a really bad editor |
| 20:57 | <Hixie> | jgraham_: just ask Philip` for a list of pages that have nvu's signature, and do a study |
| 20:58 | <jgraham_> | Hixie: AFAICT Nvu doesn't have a signature |
| 20:58 | <jgraham_> | (at least the version that comes with Ubuntu) |
| 20:58 | <Hixie> | jgraham_: and compare it to a list of pages that have the signature of tools that make it optional and don't complain and see what they're like |
| 20:58 | <Hixie> | actually this would be an interesting study |
| 20:58 | <jgraham_> | Hixie: I agree this would be an interesting study |
| 20:58 | <Hixie> | i should get us a list of pages with various detailed generator strings |
| 20:59 | <Hixie> | someone remind me later today and i'll see about setting that up |
| 20:59 | <Hixie> | gotta go now though |
| 20:59 | <Philip`> | http://philip.html5.org/data/underline-generators.txt was my last attempt at looking at generators |
| 20:59 | <Lachy> | Hixie, at what time do you want to be reminded? |
| 21:00 | <Hixie> | Lachy: now + 8 hours |
| 21:00 | <Lachy> | OK, I'll be asleep by then. Someone else will have to do it |
| 21:01 | <Philip`> | Google Web History says 5am is not my time of greatest awakeness |
| 21:01 | <Hixie> | well remind me in 2 hours, i'll be gone then and will see the reminder when i get back :-D |
| 21:02 | <Hixie> | bbl :-) |
| 21:02 | <Philip`> | Looking for (?i)generator.*nvu I see one <meta name="GENERATOR" content="NVu"> and one <meta name="generator" content="nvu"> and one <meta name="generator" content="Nvu v1.0"> |
| 21:04 | <Philip`> | I see more pages with <comment title=" ... " xmlns="http://disruptive-innovations.com/zoo/nvu">;, which presumably come from some form of interaction with Nvu |
| 21:05 | <Philip`> | ...where "more" means 8 |
| 21:08 | <Philip`> | Hixie: The problem with that kind of study is you have no way of knowing whether use of a particular authoring tool causes bad alt text, rather than some other external influence causing both, so you can't conclude anything |
| 21:09 | <Philip`> | e.g. maybe people who choose Nvu are more technically competent than those who choose FrontPage, and they'll do better alt text regardless of the editor's UI |
| 21:10 | <jgraham_> | Philip`: Yeah there are systematic biases in all surveys like this |
| 21:10 | <jgraham_> | You just have to try and understand them |
| 21:10 | <jgraham_> | rather than conclude that everything is pointless |
| 21:10 | <Philip`> | You should try to eliminate them |
| 21:10 | <Philip`> | and it's only pointless if you find you can't do that :-) |
| 21:11 | <jgraham_> | Also pasting <comment title=" ... " xmlns="http://disruptive-innovations.com/zoo/nvu">foo</comment>; into the source view of KompoZer and then switching back to normal view seems to lock the application up with 100% CPU |
| 21:11 | <Philip`> | Just because it's not possible to do a good large-scale study, that doesn't mean you should do a bad one and think its conclusions have any relevance to reality |
| 21:12 | <jgraham_> | Philip`: If you have an idea of what the biases are then you can determine whether they are likely to affect the outcome in the way that you observe |
| 21:13 | <jgraham_> | e.g. if you think that all Nvu users are more competent than Frontpage users but find that Nvu pages have worse alt text, the effect is most likely real |
| 21:14 | <jgraham_> | rather than an artifact of the people using the software |
| 21:14 | <Philip`> | If that happened, it probably just means I didn't have a good idea of the biases |
| 21:14 | <Philip`> | (If it didn't happen, I still wouldn't think I had a good idea of the biases) |
| 21:15 | <Philip`> | Maybe Nvu users are less competent than FrontPage users, or maybe there's one extremely prolific Nvu-using author who writes really bad alt text |
| 21:15 | <jgraham_> | Philip`: You don't make any progress by not doing things because you can't do them perfectly. Of course you should report any problems your study might have |
| 21:17 | <Philip`> | jgraham_: Indeed, but 'not quite perfect' and 'so far from perfect that the results are meaningless' are not the same |
| 21:18 | <jgraham_> | Philip`: Of course :) I don't think this study would necessarily produce meaningless results though |
| 21:18 | <Philip`> | So how could we be sure it was not going to produce meaningless results? :-) |
| 21:19 | <jgraham_> | We couldn't — at least for a strict definition of "sure" |
| 21:19 | <Philip`> | (preferably without first collecting a load of data and then checking whether it corresponds to our preconceived ideas of what the correct results should be :-) ) |
| 21:19 | <Philip`> | s/sure/reasonably confident/ |
| 21:19 | <Philip`> | s/reasonably confident/sufficiently confident that we could make language design decisions based on it/ |
| 21:19 | <Facedown> | Philip` - <h1><object><img> ? hrm |
| 21:20 | <jgraham_> | But we could consider all the thinks that might be wrong with it and work out whether any effects should average out over the sample or have a systematic effect |
| 21:20 | <Facedown> | I usually dont put my logos in h1 since i don't think they're real headings |
| 21:20 | <Facedown> | <div id="logo"><img></div> or just <img id="logo"> usually does it.. |
| 21:20 | <jgraham_> | We then decide if the systematic effect will be big enough to worry about |
| 21:20 | <Philip`> | Facedown: A non-visual UA that replaces the image with its alt text ought to use heading formatting for the alt text |
| 21:21 | <jgraham_> | If we're not sure, we do the study, collect the results and see if the significant of the result is greater than our estimate of the systematic effects |
| 21:21 | <Facedown> | ? to say the logo out louder? |
| 21:21 | <Facedown> | isnt that what aural styles are for? |
| 21:21 | <Facedown> | hehe |
| 21:22 | <Philip`> | Facedown: It could be a non-graphical text browser, rather than an aural one |
| 21:22 | <Philip`> | Facedown: and I'd rather aural browsers used the default <h1> aural styles, rather than some which I've made up myself and haven't been able to test |
| 21:22 | <jgraham_> | (also if we were doing the analysis in a proper Bayesian sense, our preconceived idea of what the result should be is important) |
| 21:22 | <Facedown> | My eyes usually go on the main heading in a newspaper rather than look at the logo |
| 21:23 | <Philip`> | Facedown: In my case, the logo is the main heading (since it's just fancy text) |
| 21:25 | <Philip`> | jgraham: So, how do we quantify the systematic biases in this case? |
| 21:26 | <Philip`> | (Oops, I've got to go out and find food) |
| 21:26 | jgraham | suggests eating the pigeons |
| 21:27 | <jgraham> | (since you sound o hunter-gather about it ;) |
| 21:27 | <jgraham> | s/o/so/ |
| 21:28 | <Philip`> | jgraham: I've not seen any pigeons around where I live :-( |
| 21:28 | <Philip`> | Quite a few cats wander around our garden, though |
| 21:30 | <jgraham> | Apparently carnivores taste quite bad |
| 21:51 | <Philip`> | Hmm, I did manage to sneak up on a cat, but I didn't manage to actually see it before it had already decided to run away |
| 21:51 | <Philip`> | and my spear arm wasn't quick enough |
| 23:00 | Philip` | thinks "market-leading HTML5 validator" is an odd phrase to use when the entire market consists of about ten people and one validator |
| 23:08 | <hsivonen> | Philip`: if there's only one, it's necessarily the top product in its category, isn't it? :-) |
| 23:12 | <Philip`> | hsivonen: It's technically a true statement, but the phrase has connotations that are not applicable in this case :-) |
| 23:21 | <zokka> | hello |
| 23:23 | <zokka> | i think they should change the code tag |
| 23:24 | <zokka> | so it displays special characters |
| 23:26 | <hsivonen> | zokka: who's "they" and what special characters are you referring to? |
| 23:26 | <zokka> | <> |
| 23:26 | <hsivonen> | zokka: there's already <xmp> for that |
| 23:27 | <hsivonen> | zokka: it doesn't add to the expressiveness of the language and has the problem of not being able to represent an example of itself |
| 23:27 | <zokka> | that went over my head |
| 23:27 | <zokka> | :D |
| 23:28 | <zokka> | xmp is deprecreated though |
| 23:28 | <hsivonen> | zokka: you can use <code> and <pre> to show an example of <code> or <pre> |
| 23:28 | <hsivonen> | zokka: you can't use <xmp> to show an example of <xmp> |
| 23:29 | <hsivonen> | zokka: and for the "expressiveness" part, <xmp> doesn't really help you say anything you couldn't say with <pre> |
| 23:29 | <zokka> | i like the auto escaping of special characterst though on it |
| 23:29 | <zokka> | it doesnt seem natural to use escape codes |
| 23:30 | <zokka> | i see your meaning though markup might look bad when using html |
| 23:34 | <jwalden> | *cough* cdata *cough* |
| 23:35 | <zokka> | gotta go |