| 00:17 | <Philip`> | Ooh, WebKit's globalCompositeOperation = 'highlight' is much easier than I thought it might be |
| 00:18 | <Philip`> | (since it's a deprecated part of Cocoa (or whatever it is), and acts as a synonym for 'source-over') |
| 00:35 | <zcorpan> | hmm, wonder what conformance requirements there should be for placeholder="" (for UAs) |
| 00:36 | <Hixie> | wish i knew wtf the guy in the entity thread actually wanted |
| 00:36 | <zcorpan> | e.g. should UAs be allowed to present the placeholder text to the user in some way even when the value is not empty? |
| 00:36 | <zcorpan> | wonder if that could make sense in some media |
| 00:37 | <Hixie> | maybe |
| 00:37 | <Hixie> | i don't think we should disallow it |
| 00:37 | <zcorpan> | indeed |
| 00:39 | <zcorpan> | http://simon.html5.org/temp/search-control.htm |
| 00:39 | <zcorpan> | that was originally a much bigger spec |
| 00:39 | <zcorpan> | heh |
| 00:40 | <Hixie> | i don't think we should have type=search, personally |
| 00:40 | <Hixie> | it's a text field |
| 00:40 | <Hixie> | its searchingness is orthogonal |
| 00:40 | <Hixie> | e.g. you could have a numeric search field |
| 00:41 | <Hixie> | agreed on the placeholder thing though |
| 00:42 | <zcorpan> | hmm... i think search fields are almost always free-text |
| 00:42 | <Hixie> | sure |
| 00:43 | <Hixie> | but it's not a type |
| 00:44 | <zcorpan> | if you want to skip to a search field, you'd want to skip directly to that control so you can start typing. an attribute on <input>? <input search>? |
| 00:44 | <Hixie> | or class=search |
| 00:44 | <Hixie> | which is widely used |
| 00:45 | <webben_> | zcorpan: isn't that reinventing WebKit's type="search"? |
| 00:45 | <webben_> | possibly <search> various stuff goes here </search> would be better |
| 00:45 | <webben_> | including other options for filtering searches perhaps |
| 00:47 | <zcorpan> | given that there already is an implementation, and that search fields are almost always text anyway, i think it's better to use type=search |
| 00:48 | <Hixie> | what would it do? |
| 00:48 | <zcorpan> | be easy to find as a search field |
| 00:48 | <Hixie> | why doesn't class=search do that? |
| 00:49 | <Hixie> | given that class=search automatically makes this work with existing content |
| 00:49 | <Hixie> | i don't understand why you would want to overload type="" for this |
| 00:49 | <Hixie> | note that webkit's type=search does other things than just make it seekable |
| 00:50 | <zcorpan> | yeah, but that isn't incompatible with not doing those things, right? |
| 00:50 | <Hixie> | it's still dangerous to walk all over the extensions |
| 00:50 | <zcorpan> | perhaps |
| 00:50 | <Hixie> | i don't understand what's wrong with seeking to class=search |
| 00:51 | <Hixie> | given that it's more widely used |
| 00:51 | <zcorpan> | nothing wrong with it |
| 00:51 | <Hixie> | so why is type=search better? |
| 00:51 | <zcorpan> | it has an implementation :) |
| 00:51 | <Hixie> | where? |
| 00:51 | <zcorpan> | safari |
| 00:51 | <Hixie> | no, that's an implementation of other behavour, not of the seeking you're trying to solve. |
| 00:51 | <tantek> | FWIW, at technorati.com we use <input id="search" ... |
| 00:51 | <webben_> | Hixie: Also, for the same reasons class-based approaches will always receive opposition. |
| 00:52 | <Hixie> | webben_: class-based approaches don't receive opposition when you do them using the microformats process |
| 00:52 | <othermaciej> | what do you mean by seekable? |
| 00:52 | <Hixie> | (unless they're a bad idea) |
| 00:52 | <zcorpan> | Hixie: it renders them distinctly, so for visual users they are easier to find than normal text fields |
| 00:52 | <bewest> | (in which case they shouldn't make it through the mf process) |
| 00:53 | <othermaciej> | I think our <input type="search"> is useful |
| 00:53 | <webben_> | Hixie: Microformats are very different in that most of the successful formats either misuse elements in unusual ways (abbr/title) or "namespace" the classes using an unnatural class name (e.g. hCard, hAtom) |
| 00:53 | <othermaciej> | it changes the control appearance and behavior |
| 00:53 | <othermaciej> | having class do that would be weird |
| 00:53 | <Hixie> | othermaciej: i agree that if the idea is to change the behaviour, then a new type is worthy |
| 00:53 | <othermaciej> | and I'm not sure how you could overlay arbitrary input types with also having all the search properties |
| 00:54 | <othermaciej> | (it draws in a distinctive style, saves recent searches, etc) |
| 00:54 | <Hixie> | othermaciej: zcorpan said the problem he was trying to solve was simply that of making the search field targettable by shortcut |
| 00:54 | <webben_> | Hixie: I think heuristics for finding search need to be distinguished from explicitly marking search. |
| 00:54 | <Hixie> | zcorpan: for which the type doesn't make sense imho |
| 00:54 | <tantek> | and auto-targeting/focusing an input field is orthogonal from search |
| 00:55 | <webben_> | falling back on class="search" or id="search" is more appropriate for an AT trying to guess where the search is |
| 00:55 | <Hixie> | auto-targeting/focusing an input field is already handled by autofocus="" |
| 00:55 | <othermaciej> | zcorpan, annevk: you can probably get help on this from Adele from the WebKit team if you want to write up how our search field works |
| 00:55 | <Hixie> | webben_: i'm just saying that we should make sure that we correctly determine what problem we're trying to solve and then consider the various options in that light |
| 00:55 | <webben_> | Hixie: No disagreement there. :) |
| 00:55 | <othermaciej> | well, if the idea is to have a keyboard shortcut to pick the search field, then you probably need a number of potential candidates: |
| 00:56 | <othermaciej> | 1) <input type="search"> fields, since intent there is clear without a class |
| 00:56 | <zcorpan> | Hixie: i didn't mean only accessible with keyboard shortcut, but more identifiable as a search field |
| 00:56 | <othermaciej> | 2) input fields that have class="search" (maybe - is this actually common on an input, not a form?) |
| 00:56 | <othermaciej> | 3) some heuristically determined text input in a form with class="search" |
| 00:56 | <webben_> | I think the focus on inputs here is wrong, because many search queries involve more than one input. |
| 00:57 | <webben_> | the focus should be on <form type/class="search"> |
| 00:57 | <othermaciej> | there are a lot of search forms that are based on a single search field |
| 00:57 | <othermaciej> | and distinguishing the field in such cases visually and adding special behavior is useful |
| 00:57 | <zcorpan> | yeah. this isn't for complex searches |
| 00:57 | <webben_> | othermaciej: Of course. But those are also handled by distinguishing <form>. |
| 00:57 | <Hixie> | personally i'm not really convinced there's a problem to solve here, but i haven't looked at it closely |
| 00:57 | <webben_> | zcorpan: but for AT navigation, you want to handle complex search areas on a page too |
| 00:57 | <othermaciej> | webben_: have you seen how <input type="search"> works in Safari? |
| 00:58 | <webben_> | othermaciej: what's an example page that uses it? |
| 00:58 | <webben_> | (i've got safari here) |
| 00:58 | <zcorpan> | webben_: for complex searches, you generally have a page dedicated for that specifically |
| 00:58 | <othermaciej> | webben_: http://www.apple.com/ |
| 00:58 | <webben_> | zcorpan: I've seen plenty of pages with more than one input in the search area on a page not dedicated to search |
| 00:58 | <othermaciej> | webben_: it looks distinctive and remembers past searches |
| 00:59 | <zcorpan> | webben_: pointer? |
| 00:59 | <webben_> | zcorpan: I can try and find you some examples if that would help. |
| 01:00 | <othermaciej> | anyway, you wouldn't want to do the extra appearance and behavior on any input field that's inside a <form class="search"> |
| 01:00 | <webben_> | zcorpan: http://ubuntuforums.org/ springs to mind |
| 01:00 | <webben_> | othermaciej: That's the difference between search and keywords. |
| 01:00 | <othermaciej> | and if you had a feature to "find the search field", it would be perverse for it to ignore an <input type="search"> that doesn't happen to be in a form with the right class |
| 01:00 | <webben_> | safari's search is /really/ a keywords field |
| 01:01 | <webben_> | othermaciej: Sure. But that's a matter of heuristics. |
| 01:01 | <webben_> | (and with type, there's no huge harm in making special treatment a requirement, even if search isn't made a conforming value) |
| 01:02 | <othermaciej> | well, I think it's clear that if it is worth identifying something on the page as "the search field" and to have a spec for it, <input type="search"> should be included |
| 01:02 | <othermaciej> | the question is then what other things, if any, would need to be identified |
| 01:02 | webben_ | agrees it's worth including. But then he also thinks it's worth including <acronym>. |
| 01:03 | <zcorpan> | webben_: that page has two separate simple search fields? |
| 01:03 | <webben_> | zcorpan: click search to see the search form |
| 01:04 | <webben_> | (it's a dropdown) |
| 01:04 | <webben_> | you control what form you want results returned in |
| 01:04 | <zcorpan> | show in threads / show in posts ? |
| 01:05 | <othermaciej> | I don't think the auxiliary radio buttons here would conflict with <input type="search"> as a way to find the search field |
| 01:05 | <webben_> | zcorpan: yeah |
| 01:05 | <zcorpan> | othermaciej: agreed |
| 01:05 | <othermaciej> | the case where it breaks down is if you have multiple text inputs |
| 01:05 | <othermaciej> | or something like a date range picker |
| 01:06 | <webben_> | othermaciej: does Safari or VO offer any navigation shortcut to type=search |
| 01:06 | <webben_> | can either cycle between multiple instances of that type? |
| 01:07 | <othermaciej> | Safari doesn't, no |
| 01:07 | <othermaciej> | I think VO does distinguish search fields from garden-variety text fields though |
| 01:08 | <webben_> | othermaciej: it would probably be worth getting a clear description of how it's currently used |
| 01:09 | <othermaciej> | webben_: it's not primarily an accessibility feature |
| 01:10 | <webben_> | othermaciej: That doesn't matter. If current AT makes use of it in any way, that needs to be documented for considering how to treat it in the spec. |
| 01:10 | <Hixie> | othermaciej doesn't care about accessibility!!!11 |
| 01:10 | <webben_> | e.g. it would be interesting to know if there is a Search input in Apple's Accessibility API |
| 01:11 | <webben_> | (it's important to have some sync between desktop accessibility APIs and HTML applications) |
| 01:11 | <othermaciej> | webben_: HTML5 in general doesn't spec how AT treats various form controls |
| 01:11 | <othermaciej> | sounds like it would be worthy research, but I don't volunteer to do it |
| 01:12 | <webben_> | othermaciej: But how UAs treat form controls is what we're discussing here, isn't it? |
| 01:12 | <webben_> | which obviously includes AT? |
| 01:12 | <webben_> | we don't seem to be having an abstract discussion of semantics |
| 01:12 | <othermaciej> | I'm actually not sure what the point of contention is - I just wanted to explain why I think <input type="search"> is a generally useful feature |
| 01:13 | <othermaciej> | I don't know any more about the details of how VoiceOver treats it than I do about how VoiceOver treats <input type="text"> |
| 01:13 | <webben_> | othermaciej: it would be useful because UAs can make use of it ... hence my question of what use UAs do make of it. |
| 01:14 | <othermaciej> | Safari makes use of it by giving it a distinctive appearance (rounded ends, search icon on one side) and behavior (menu of previous searches) and probably some other stuff I am forgetting |
| 01:14 | <webben_> | (of course UAs could presumably make /more/ use of it too) |
| 01:14 | <othermaciej> | how VO makes use of it, I don't know offhand |
| 01:15 | <othermaciej> | we don't have a "find the search field" feature, I imagine it could be cool, but the distinctive look makes it easy for a sighted user at least to spot while scanning the page |
| 01:15 | <webben_> | othermaciej: is the menu URL specific or general to all search boxes? |
| 01:15 | <othermaciej> | I'm not sure what you mean by 'menu URL' |
| 01:16 | <webben_> | sorry, I mean the menu of previous searches, does Safari lump all search boxes together when presenting a menu |
| 01:16 | <webben_> | or remember searches for each instance or each URL or what? |
| 01:19 | zcorpan | updated the document |
| 01:19 | <othermaciej> | I think it's distinct per search field |
| 01:19 | <othermaciej> | http://www.searchmash.com/ is another field that uses it |
| 01:20 | <othermaciej> | (another site that uses it) |
| 01:20 | <Hixie> | mmmm |
| 01:20 | <Hixie> | searchmash.com |
| 01:20 | <Hixie> | wonder what that could be! |
| 01:20 | <othermaciej> | it's not-so-secretly a "web 2.0" version of google search |
| 01:21 | <Hixie> | indeed |
| 01:21 | <othermaciej> | I know I've seen it on other sites but I can't think of examples offhand |
| 01:22 | <Hixie> | basically it looks different and has a button to clear the field, as far as i can tell |
| 01:22 | <othermaciej> | the searchmash one isn't using the menu of saved searches feature |
| 01:22 | <aroben> | Hixie: othermaciej: facebook.com uses it |
| 01:22 | <othermaciej> | oh that's right |
| 01:22 | <othermaciej> | and facebook uses the Recent Searches feature |
| 01:23 | <aroben> | othermaciej: webben_: the recent searches are made unique by the autosave attribute |
| 01:24 | <Hixie> | how do i see these recent searches? |
| 01:24 | <aroben> | othermaciej: webben_: <input type="search" autosave="unique_identifier"> |
| 01:24 | <aroben> | Hixie: do some searches using the field |
| 01:24 | <aroben> | Hixie: then click on the magnifying glass |
| 01:24 | <webben_> | othermaciej: so couldn't one decouple autosave and type="search"? |
| 01:24 | <aroben> | Hixie: a menu should pop up |
| 01:24 | <Hixie> | aroben: tried that |
| 01:24 | <zcorpan> | why isn't name="unique_identifier" good enough for that feature? |
| 01:24 | <Hixie> | aroben: on apple.com didn't work |
| 01:25 | <aroben> | Hixie: apple.com isn't saving any search results |
| 01:25 | <Hixie> | ah |
| 01:25 | <Hixie> | i don't have a facebook account |
| 01:25 | <aroben> | Hixie: the magnifying glass has a little down arrow next to it if will save results |
| 01:25 | <webben_> | autosave sounds weirdly similar to IE's autocomplete |
| 01:25 | <Hixie> | so what makes the magnifying glass appear? |
| 01:26 | <aroben> | Hixie: http://www.37signals.com/svn/archives2/searchin_safari.php |
| 01:26 | <Hixie> | doesn't answer the question :-) |
| 01:26 | <aroben> | Hixie: just showing you the picture |
| 01:26 | <Hixie> | searchmash doesn't have a magnifying glass |
| 01:26 | <Hixie> | apple does |
| 01:26 | <aroben> | Hixie: the magnifying glass is controlled by the results attribute |
| 01:26 | <webben_> | I quite like the idea of a default presentation for search fields. It's worth noting that attaching a default presentation might well drive some publishers to avoid using it though. |
| 01:27 | <webben_> | (in favour of their own search icons or whatever) |
| 01:27 | <Hixie> | aroben: which does what? |
| 01:27 | <tantek> | indeed, publishers make <div> javascript buttons for that reason |
| 01:27 | <webben_> | it may be that providing CSS for adding an icon for fields, and distributing copyleft images for a search magnifying glass would wok better |
| 01:27 | <aroben> | Hixie: you can have results="10" to specify that 10 results should be saved |
| 01:27 | <webben_> | (a bit like the Feed icons) |
| 01:27 | <Hixie> | aroben: seems silly to show the magnifying glass if nothing's gonna be saved :-) |
| 01:27 | <tantek> | but if Safari supported more of CSS3UI, then publishers could customize the look & feel of controls better |
| 01:28 | <aroben> | Hixie: yes, but that's the OS X convention |
| 01:29 | <Hixie> | aroben: so why not show it always? |
| 01:29 | karlUshi | wonders if the list is YOUR own previous search requets on the site. So it means the browser has an individual list for each site having this markup. And is it by site (domain name) or by individual web page? |
| 01:29 | <aroben> | Hixie: not sure, honestly |
| 01:29 | <karlUshi> | A lot of issues |
| 01:30 | <aroben> | Hixie: the rule is: if there's no results attribute, you get no magnifying glass |
| 01:30 | <webben_> | so we're talking two extra attributes as well as a new type |
| 01:30 | <aroben> | Hixie: if there's an empty results attribute or it has the value 0, there's a magnifying glass with no arrow and no menu |
| 01:30 | <aroben> | Hixie: if there's a results attribute with value > 0, there's a magnifying glass, arrow, and menu |
| 01:30 | <Hixie> | aroben: seems weird :-) |
| 01:31 | <zcorpan> | why aren't searches always saved? with some appropriate number of shown results? with the identifier being the name=""? |
| 01:31 | <webben_> | a unique autosave id makes sense to me |
| 01:31 | <webben_> | agree with zcorpan about results |
| 01:31 | <webben_> | don't understand what either has to do (intrinsically) with search |
| 01:32 | <aroben> | zcorpan: I don't know all the reasons behind the current design |
| 01:32 | <webben_> | e.g. autosave functionality would also be useful for data entry |
| 01:32 | <zcorpan> | normal text fields remember what was typed in based on name=""... i don't see why search fields should be different |
| 01:32 | <aroben> | webben_: you mean similar to most browser's autocomplete feature? |
| 01:32 | <aroben> | *browsers' |
| 01:33 | <webben_> | aroben: I don't really know how those features work, so I'm not sure. |
| 01:33 | <webben_> | in particular, how granular their memory is |
| 01:33 | <aroben> | webben_: I believe it's what zcorpan is referring to |
| 01:33 | <zcorpan> | yeah |
| 01:33 | <zcorpan> | how is autosave different? |
| 01:33 | <zcorpan> | and why |
| 01:34 | <aroben> | zcorpan: I'm not sure there's any deep reason behind the separation |
| 01:34 | <aroben> | zcorpan: clearly autocomplete can work nicely for search fields, as with the search field in the Firefox chrome |
| 01:34 | <zcorpan> | indeed |
| 01:34 | <webben_> | . |
| 01:35 | <webben_> | i thought that was Google Suggest powering that |
| 01:35 | <webben_> | maybe it's a combination of the two |
| 01:35 | <aroben> | webben_: Google Suggest is there, yes, but it will also just remember things you've typed in before |
| 01:35 | <aroben> | webben_: right |
| 01:36 | <webben_> | it sounds like autocomplete, autosave, and our autocompletion-WF2 stuff all needs to be considered together |
| 01:37 | <webben_> | as it's all trying to manipulate the same functionality from the server |
| 01:38 | <zcorpan> | i understand the autosave feature, but i don't understand why it needs any attributes for it to work |
| 01:38 | <webben_> | it doesn't sound as though type=search shares searches between multiple sites, which in theory could be useful (as in, "i didn't find anything about X on this site, but now I'll go search for X on this other site") |
| 01:39 | <Lachy> | good morning |
| 01:39 | <webben_> | morning Lachy |
| 01:39 | <zcorpan> | good night |
| 01:39 | <zcorpan> | :) |
| 01:39 | <Lachy> | Hixie: what did you mean by "lordy, poor lachy"? |
| 01:40 | <Hixie> | webapi |
| 01:40 | <aroben> | webben_: it does share between sites |
| 01:41 | <aroben> | webben_: all that matters is the autosave attribute |
| 01:41 | <aroben> | webben_: which is probably why we didn't go with name="" |
| 01:41 | <webben_> | aroben: sorry, i meant between sites where the authors didn't intended to share searches like that |
| 01:41 | <Lachy> | oh, the objections to the names? Just reading those now |
| 01:42 | <webben_> | (e.g. I search for something on Google, then give up and search for it on Microsoft Live.com) |
| 01:42 | <Hixie> | Lachy: yeah. luckily nobody is trying to change the decision, but sheesh. talk about illustrating the difference between the w3c and the whatwg. |
| 01:42 | <aroben> | webben_: yes, that's what I'm talking about |
| 01:42 | <aroben> | webben_: if google.com and live.com use the same autosave attribute, you'll get shared recent searches |
| 01:42 | <Hixie> | isn't that a privacy risk? |
| 01:42 | <webben_> | aroben: are so the intention is that competitors will use the same autosave id? |
| 01:43 | <aroben> | Hixie: through user error, I suppose |
| 01:43 | <aroben> | Hixie: there's no access to the recent searches through the DOM |
| 01:43 | <Hixie> | aroben: you can easily trick users to click in different places |
| 01:43 | <aroben> | Hixie: right |
| 01:43 | <aroben> | webben_: I suppose so |
| 01:43 | <zcorpan> | aroben: and that is just as likely as that they use the same name="", no? |
| 01:43 | <aroben> | zcorpan: right |
| 01:43 | <zcorpan> | ok. anyway, i was going to bed |
| 01:43 | <zcorpan> | nn |
| 01:44 | <aroben> | zcorpan: I think the nice thing about having a separate attribute is that autosave isn't tied up in POST/GET requests |
| 01:44 | <webben_> | me too |
| 01:44 | <webben_> | good night folks |
| 01:44 | <aroben> | night zcorpan, webben_ |
| 01:46 | <aroben> | Hixie: overall I think the desire was to mimic the functionality of NSSearchField |
| 01:47 | <Lachy> | yeah, it's quite annoying. I clearly addressed all the arguments (though I didn't specifically reference the F2F minutes), yet I get accused of ignoring and treating people unfairly :-( |
| 01:48 | <Hixie> | Lachy: welcome to the world of spec editor |
| 01:48 | <Hixie> | Lachy: the only way around it is to make crappy compromises which make for a crappy spec |
| 01:49 | <Lachy> | I really don't want to compromise on gEBS, it'll just make another group of people unhappy |
| 03:05 | <Hixie> | does everyone agree that the tokeniser has 32 states now? |
| 03:05 | <Hixie> | or did i miscount |
| 03:06 | <Hixie> | like a dozen of them are just for the doctype |
| 03:06 | <Hixie> | sheesh |
| 03:56 | <aroben> | Hixie: one potential situation I thought of where you'd want an autosave attribute instead of a name attribute |
| 03:57 | <aroben> | Hixie: would be if you had two search fields on a page that you wanted to have share recent searches |
| 03:59 | <Hixie> | makes sense |
| 04:01 | <aroben> | Hixie: did input type=search show up in a spec recently? |
| 04:01 | <Hixie> | not one of mine |
| 04:01 | <aroben> | Hixie: just wondering what sparked the discussion |
| 04:01 | <Hixie> | http://simon.html5.org/temp/search-control.htm |
| 04:01 | <Hixie> | i don't know what the background was though |
| 04:02 | <aroben> | Hixie: do you know what "The autosave and results attributes have been identified as misnormers." means? |
| 04:06 | <Hixie> | no |
| 04:50 | <Hixie> | oops |
| 04:50 | <Hixie> | 225 compiler errors |
| 07:23 | <webben> | Lachy: If you care to reread http://joeclark.org/book/sashay/serialization/Chapter13.html , you'll find Clark would certainly not favour removing the ability to provide transcription as an alternative to video. |
| 07:24 | <webben> | Full-fledged captioning, subtitles, audio description, and signing being preferable is not the same as transcription being useless. |
| 07:25 | <webben> | Indeed, Clark says that including a transcription is helpful even with those things (and easy to produce as part of the process.) |
| 07:29 | <webben> | What Clark does discourage in that chapter is not transcription per se but text (rather than audio) description for the blind. |
| 07:37 | <Hixie> | ok, i give up |
| 07:37 | <Hixie> | i've been trying to ignore it for all this time, but i finally broke down |
| 07:37 | <Hixie> | what the hell is the subject line "the market hasn't spoken - it hasn't bothered to listened" supposed to mean? |
| 07:37 | <Hixie> | is it supposed to be "to listen" or is it supposed to be "to be listened to"? |
| 07:38 | <hsivonen> | Hixie: "to listen" |
| 07:38 | <gavins> | hmm, I'd always read it as "the market has spoken, no one's bothered to listen" |
| 07:38 | <Hixie> | gavins: yeah, hence my confusion |
| 07:38 | <Hixie> | who hasn't listened? |
| 07:38 | <hsivonen> | Hixie: the market |
| 07:38 | <Hixie> | what haven't they listened to? |
| 07:38 | <hsivonen> | Hixie: the accessibility folk |
| 07:39 | <Hixie> | i see |
| 07:39 | <Hixie> | isn't it the accessibility folk (and in fact all of us spec people) who are the ones who are supposed to listen? |
| 07:39 | <hsivonen> | no comment |
| 07:41 | <gavins> | oh, I get it now |
| 07:41 | <gavins> | (reading his actual message helped) |
| 09:52 | <hsivonen> | aargh. the anon access of the whattf repo is broken again |
| 15:08 | <krijnh> | Ping |
| 19:28 | <zcorpan_> | hmm, perhaps i should add more tests that check EOF handling in pseudo-comments |
| 19:29 | <zcorpan_> | to make sure that we don't do funny stuff like reparsing :) |
| 19:59 | <zcorpan_> | naw, reparsing would be a separate bug |
| 20:33 | <bewest> | launching on a friday? |
| 20:39 | <zcorpan_> | http://intertwingly.net/blog/2007/06/28/Publishing-a-Blog-From-a-mod-atom-Store |
| 20:56 | <bewest> | mod_atom? |
| 20:58 | <zcorpan_> | when i posted the link, the page wasn't well-formed |
| 21:00 | <zcorpan_> | Planet’'s was Planet’'s |
| 21:28 | <zcorpan_> | othermaciej: [13:22] <zcorpan> om_sleep: forgot to end your sentence again? http://www.w3.org/mid/E40DB09C-1333-4FC2-B9E0-A83CADE75C4E⊙ac |
| 21:31 | <othermaciej> | zcorpan_: yeah, I did, I hope my point was clear |
| 21:32 | <zcorpan_> | ", then that would be great." ? :) |
| 21:42 | <othermaciej> | yeah |
| 22:02 | <Hixie> | my parser is unfortunately not re-entrant |
| 22:02 | <Hixie> | which is making it hard to process " " characters in the trailing end phase exactly per spec without duplicating code |
| 22:26 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=70 |
| 22:31 | <Hixie> | zcorpan_: commented |
| 22:39 | <met_> | hsivonen: why is Konqueror blank for HTML5 on http://hsivonen.iki.fi/doctype/ ? |
| 22:39 | <hsivonen> | met_: because I have not tested |
| 22:40 | <met_> | I have some virtuals with Konq, have you some test which I can try? |
| 22:40 | <met_> | or it is more complicated? |
| 22:41 | <hsivonen> | met_: the leftmost cell on each row link to a test |
| 22:41 | <met_> | thanks 8-) |
| 22:42 | <Philip`> | If I remember correctly, Konq 3.5 was identical to "Moz & Safari" on all of those tests |
| 22:43 | met_ | hasn't runed his openSUSE virtual for month, it is checking file system 8-( |
| 22:51 | <met_> | ok it's Konq 3.5.5 |
| 22:53 | <met_> | hsivonen: it's the blue rectagles test? (according to safari, there is no note about Konq) |
| 22:55 | <hsivonen> | Philip`: oops. I've forgotten to act on that report |
| 22:55 | <hsivonen> | Philip`: sorry |
| 22:55 | <met_> | probably not exactly, I see some differences from the Konq 3.2 you have there |
| 22:55 | <hsivonen> | met_: the blue rectangles tests full standards vs. something else |
| 22:57 | <hsivonen> | Philip`: fixed |
| 22:57 | <hsivonen> | Philip`: thanks |
| 22:57 | <met_> | donot work, If I went throug Konq3.2 column I see different results even for some quirks |
| 22:58 | <hsivonen> | met_: do you still have Konq 3.2? |
| 22:59 | <met_> | no 3.5.5 (mentioned above), there was something fixed probably |
| 22:59 | <met_> | not usefull for you |
| 22:59 | <hsivonen> | met_: most likely they landed the code hyatt adapted from Gecko way back in the Safari 1.0 cycle |
| 23:00 | <hsivonen> | or 0.9 rather |
| 23:02 | <met_> | I see even difference between XHTML transitional and strict, you have both Q |
| 23:06 | <hsivonen> | met_: Konq 3.2 is 3.2. Moz & Safari is 3.5 |
| 23:07 | <met_> | yes I have just tested whole table Konq 3.5.5 is exactly like Moz+Saf column |
| 23:19 | <met_> | 2004-10-28 Stephan Kulow <coolo⊙ko> |
| 23:19 | <met_> | * html/html_documentimpl.cpp (determineParseMode): adding a fixed list of |
| 23:19 | <met_> | doctypes to enable quirks mode on (derived from Webcore, but majorly revised) |
| 23:19 | <met_> | * enable strict CSS parsing also for transitional doctypes |
| 23:19 | <met_> | from http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/ChangeLog?view=markup&pathrev=632575 |
| 23:20 | <met_> | 2004 it's pretty old |
| 23:20 | <hsivonen> | met_: thanks |
| 23:21 | <hsivonen> | I wonder how the ICU4J encoding detector differs from Mozilla chardet |
| 23:22 | <met_> | and here is the KHTML source function HTMLDocumentImpl::determineParseMode http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp?revision=628618&view=markup |
| 23:23 | <met_> | khml has even different file names from webkit source - it has to be nightmare with merging |
| 23:24 | <hsivonen> | why the difference in file names? |
| 23:28 | <met_> | html_documentimpl.cpp from KHTML is HTMLDocument.cpp in webkit |
| 23:28 | <met_> | different convention probably |
| 23:33 | <met_> | Does anyone know, why Safari sents to flick and yahoo different uastring? |
| 23:35 | <met_> | it tries to look as older version for this domains, it's harcoded in http://www.koders.com/noncode/fid469663037C7D987803483ECADC6068A0AD6B40F2.aspx#L3579 |
| 23:37 | <hsivonen> | met_: I don't know but it isn't hard to guess why. most likely Yahoo is doing bad UA sniffing |
| 23:38 | <hsivonen> | or then they are doing good UA sniffing to work around a WebKit bug and the new WebKit doesn't fix the bug |
| 23:38 | <met_> | hsivonen: it is much different |
| 23:39 | <hsivonen> | yes |
| 23:39 | <met_> | only in version number |
| 23:39 | <met_> | and also send Macintosh even if i work on Windows |
| 23:40 | <met_> | oh so late, going to sleep, bye |