| 07:03 | <zcorpan> | TabAtkins: what is the use case for selecting all attributes? |
| 10:26 | <zcorpan> | http://html5.org/tools/web-apps-tracker?from=8510&to=8511 what a lovely typo |
| 10:31 | <MikeSmith> | hah yeah |
| 12:15 | <hsivonen> | I just realized that Latvian Firefox and Lithuanian Mac/Linux Firefox ship with a fallback that's not even in the menu in IE11. |
| 12:25 | <hsivonen> | and for Romanian, Firefox, Chrome and IE all have different fallbacks |
| 12:26 | <Ms2ger> | Should ask the [qa-] people |
| 12:29 | <Ms2ger> | zcorpan_, thanks a lot for all the reviews, btw |
| 12:30 | <zcorpan_> | Ms2ger: welcome |
| 12:30 | <zcorpan_> | did we have a convention for helper .html files? put in resources/ ? |
| 12:31 | <Ms2ger> | I don't think we have one |
| 12:31 | <jgraham> | zcorpan_: No, but resources is quite common |
| 12:31 | <jgraham> | There isn't a need for such a convention |
| 12:31 | <jgraham> | (except consistency for humans) |
| 12:31 | <zcorpan_> | oh, the runner figures it out anyway? |
| 12:32 | <Ms2ger> | As long as they don't include th.js |
| 12:32 | <jgraham> | Yeah, a helper file is anything that doesn't link to testharness.js, specify a reference url, or have -manual in the name |
| 12:32 | <jgraham> | (roughly) |
| 12:33 | <zcorpan_> | ok |
| 12:33 | <Ms2ger> | So the Scooby Doo algorithm, basically |
| 12:43 | <MikeSmith> | sigh https://github.com/h5bp/mobile-boilerplate/wiki/The-Markup#wiki-mobile-viewport-optimization |
| 12:44 | <MikeSmith> | I guess <meta name="HandheldFriendly" content="True"> and <meta name="MobileOptimized" content="320"> are in every HTML document on the Web that uses html5boilerplate as a template |
| 12:44 | <MikeSmith> | along with other winners such as <meta http-equiv="cleartype" content="on" |
| 12:45 | <MikeSmith> | *mobile version of html5boilerplate |
| 12:51 | <MikeSmith> | jgraham: you're saying that the testrunner figures that out programatically? |
| 12:52 | <zcorpan_> | MikeSmith: file a bug on h5bp? |
| 12:52 | <MikeSmith> | jgraham: "doesn't link to testharness.js, specify a reference url, or have -manual in the name" I mean |
| 12:52 | <zcorpan_> | MikeSmith: it uses voodoo. yama yama yama yama yama... |
| 12:53 | <jgraham> | MikeSmith: Yes, that's what I'm saying |
| 12:53 | <MikeSmith> | zcorpan_: I should file a bug on that but I don't want to invest the time needed to follow up with it |
| 12:53 | <MikeSmith> | nice |
| 12:53 | <jgraham> | Well specifically the code for generating a manifest figures it out programatically |
| 12:54 | <zcorpan_> | MikeSmith: feel free to cc me |
| 12:55 | <MikeSmith> | jgraham: so that allows the testrunner to ignore the whole conformance-checkers tree. Which is good. But there are about 1300 HTML files in there so maybe it should have some other way to flag that while tree as "ignore" (if it doesn't already) |
| 12:55 | <MikeSmith> | zcorpan_: OK |
| 12:57 | <jgraham> | MikeSmith: There is a blacklist of directories, it would be easy to add conformance-checkers to that |
| 12:57 | <MikeSmith> | ok |
| 12:57 | <MikeSmith> | I will make a PR to add it then I guess |
| 12:58 | <MikeSmith> | because there are no real test in there |
| 12:58 | <MikeSmith> | well, not browser tests |
| 12:59 | <jgraham> | Thanks |
| 13:00 | <MikeSmith> | in other news I am finding that http://mosh.mit.edu/ is indeed pretty great |
| 13:01 | <MikeSmith> | for, e.g., when you need to ssh and you're on flaky wifi |
| 13:03 | Ms2ger | read mosh.pit.edu |
| 13:03 | <MikeSmith> | heh |
| 13:04 | <MikeSmith> | well it's nice when you, say, are forced to scribe a f2f meeting and you also have to use the "Mozilla Guest" wifi network that drops out every 17 minutes or so |
| 13:06 | <Ms2ger> | At that point, you make a Mozillian scribe :) |
| 13:07 | <MikeSmith> | hmm yeah I like that plan better |
| 13:07 | <jgraham> | If it's anything like Mozilla-London, that WiFi probably (unintentionally) provides the "free wifi" for the cafe next door |
| 13:09 | <MikeSmith> | ah |
| 13:09 | <zcorpan_> | anyone want to defend insertAdjacentHTML? (eseidel suggested removing it from blink along with the other two insert*) |
| 13:09 | <hsivonen> | jgraham: I thought it was intentional. |
| 13:09 | <zcorpan_> | miketaylr: can you grep for "insertAdjacent(Text|HTML|Element)" ? :-) |
| 13:10 | <MikeSmith> | zcorpan_: huh I thought that was used in Web content and performed pretty fast now |
| 13:10 | <Ms2ger> | zcorpan_, *HTML is widely implemented, unlike the others |
| 13:10 | <jgraham> | hsivonen: Well I meant "unintentional" in the sense that we don't have a specific deal to provide free wifi, as far as I know |
| 13:10 | <jgraham> | It's just that the signal reaches |
| 13:10 | <Ms2ger> | And I think sicking liked it to wean people off innerHTML += |
| 13:10 | <MikeSmith> | zcorpan_: https://twitter.com/html5/status/134485735024762880 |
| 13:11 | <zcorpan_> | MikeSmith: *HTML is 0.036% of page views apparently |
| 13:11 | <MikeSmith> | wow |
| 13:11 | <MikeSmith> | well seems like people should use it more |
| 13:11 | <wilhelm> | MikeSmith: Oh, I haven't tried that one yet. |
| 13:11 | <MikeSmith> | what Ms2ger said |
| 13:11 | <MikeSmith> | wilhelm: mosh? |
| 13:11 | <jgraham> | That seems like quite a lot? |
| 13:11 | <wilhelm> | Yes. |
| 13:11 | <Ms2ger> | Also, I'm interested in -moz-grid, in case anybody has data |
| 13:12 | <zcorpan_> | ok i'll put a word for *HTML |
| 13:12 | <MikeSmith> | wilhelm: it seems to works as advertised. There's a android SSH client, JuiceSSH, that supports it too |
| 13:13 | <hsivonen> | jgraham: ok |
| 13:13 | <MikeSmith> | zcorpan_: see also https://hacks.mozilla.org/2011/11/insertadjacenthtml-enables-faster-html-snippet-injection/ from hsivonen |
| 13:14 | MikeSmith | oh that's the same reference as the twitter one I see |
| 13:15 | <hsivonen> | Surely Blink isn't seriously considering removing insertAdjacentHTML to improve mobile performance? |
| 13:15 | <MikeSmith> | they seem to be going a little overboard with the remove all the things frenzy |
| 13:15 | <zcorpan_> | hsivonen: no :-) more to remove legacy cruft, but i'm writing an email now arguing that *HTML should not be considered legacy cruft |
| 13:16 | <Ms2ger> | MikeSmith, ssh |
| 13:21 | <davve``> | There it not even a UseCounter for insertAdjacentHTML so it hasn't been on the table before. Probably just a misunderstanding. |
| 13:21 | <Ms2ger> | davve``, wait, if there is no usecounter, where did zcorpan_ get his figure from? |
| 13:24 | <zcorpan_> | hmmm. oh, seems i misread the email. that was for insertAdjacentElement. |
| 13:24 | <davve> | Ms2ger: 0.036% is insertAdjacentElement, I think. |
| 13:25 | <davve> | http://www.chromestatus.com/metrics/feature/timeline/popularity/141 |
| 13:27 | <Ms2ger> | Interesting how much it drops on the weekend |
| 13:28 | <Ms2ger> | Oh wow, captureEvents is huge |
| 13:43 | <MikeSmith> | w00t I've now made 100 w-p-t commits |
| 13:43 | <zcorpan_> | jgraham: https://critic.hoppipolla.co.uk/r/790 |
| 13:43 | <MikeSmith> | most of them shouldn't count but I'll take them anyway |
| 13:43 | <Ms2ger> | Congratulations :) |
| 13:44 | <MikeSmith> | Ms2ger: thanks now I have only 743 to go before I catch up with you. So watch out |
| 13:44 | <Ms2ger> | :D |
| 13:44 | <zcorpan_> | Ms2ger: how many chocolates is 100 commits? |
| 13:45 | <Ms2ger> | Meh, most of those shouldn't really count ;) |
| 13:45 | <zcorpan_> | or maybe it's lines reviewed that generates chocolate |
| 13:46 | <Ms2ger> | I should clearly get you some more :) |
| 14:29 | <zcorpan_> | i don't object to that :-D |
| 14:30 | <Ms2ger> | I should also get Leif Arne some |
| 14:51 | <miketaylr> | zcorpan: sure thing |
| 14:54 | <zcorpan> | neato |
| 15:05 | <hsivonen> | we have a new w3schools: http://www.html-5.com/tutorials/basic-html-code.html |
| 15:05 | <hsivonen> | unfortutely found out via a bugzilla comment complaining how Firefox handles that |
| 15:06 | <Ms2ger> | Wow, that page looks straight out of the early naughties |
| 15:09 | <wilhelm> | It puzzles me that there are real humans out there taking the time to create something like that. |
| 15:12 | <zcorpan> | good thing it has links to about and contact in the footer: http://www.html-5.com/about.html http://www.html-5.com/contact.html |
| 15:14 | <zcorpan> | "WARNING: Be careful when looking for web sites for learning HTML, especially when it comes to things that are treated differently by different browsers." http://www.htmlattributes.com |
| 15:17 | wilhelm | blinks. |
| 15:18 | <wilhelm> | So w3schools is run by a Norwegian complay with 5 employees and an annual turnover of 2.3M USD. |
| 15:20 | <wilhelm> | Snake oil certainly is a booming business. http://www.refsnesdata.no/certification/w3certified.asp?id=3020062 |
| 15:24 | <MikeSmith> | it wouldn't require much more effort from them to actually make it a worthwhile site |
| 15:30 | <wilhelm> | It would require qualities like "good taste" and "understanding the subject matter", though. |
| 15:32 | <Hixie> | hsivonen: can you elaborate on the difference between ff 25 and ff 26, as far as encodings go? |
| 15:32 | <Hixie> | hsivonen: is 26 where you have the fallback be tld-based? |
| 15:33 | <Hixie> | hsivonen: and is "locale" in the table the locale of the build? |
| 15:34 | <Hixie> | hsivonen: also, if you could send feedback on http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0097.html that would be great |
| 15:48 | <hsivonen> | Hixie: no substantial difference between 25 and 26. The two mainly show how much the numbers vary between two releases without changes. |
| 15:48 | <hsivonen> | Hixie: locale of the build, yes |
| 15:49 | <Hixie> | ok, cool |
| 15:49 | <hsivonen> | Hixie: I'll take a look at the email hopefully in near future |
| 15:51 | <Hixie> | thanks |
| 16:21 | <TabAtkins> | zcorpan: I've done loops through all attributes in Python code before. Useful when you can't process things by name, because the name is open-ended (like data-*). |
| 17:12 | <BS-Harou> | Hi, I'm looking into commentsµdata. What I found is that http://schema.org/Comment encodes the creative work by someone while http://schema.org/UserComments encodes the action event of doing a comment. Can anyone give me a real world example of when I would want to use UserComments rather than Comment? Also the Article#comment property (according to schema.org) refers to UserComments rather than Comment which seems weird. Can I jsut specify |
| 17:12 | <BS-Harou> | the itemtype as Comment and use CreativeWork(/Comment) itemprops instead? |
| 17:15 | <scor> | BS-Harou: you should ask this on http://lists.w3.org/Archives/Public/public-vocabs/ - I've been advocating to get rid of UserComments the way it's implemented now, so your feedback would be useful there |
| 17:26 | <BS-Harou> | thanks :) |
| 18:20 | <benvie> | Domenic_: I'm trying to formulate comments describing the expected results of Promise.race, but I'm not actually sure what governs the resolution order |
| 18:20 | <benvie> | Domenic_: https://bugzilla.mozilla.org/show_bug.cgi?id=941920#c13 |
| 18:20 | <benvie> | how can I describe that the result of Promise.race([1, 2]) is deterministic? |
| 18:28 | <benvie> | Domenic_: nevermind, got it! |
| 18:47 | <Domenic_> | benvie: ok! :) |
| 19:00 | <tantek> | BS-Harou, scor, or you could ask in #schema also. |
| 19:37 | <benvie> | Domenic_: sorry to bother you again. Could you sanity check the order of Task Queue operations I've outlined in this comment? https://bugzilla.mozilla.org/show_bug.cgi?id=941920#c15 |
| 19:39 | <Domenic_> | benvie: what code is that referring to? |
| 19:39 | <benvie> | the quotes code at the top of the comment, `let p1 = Promise.resolve(2); let p2 = Promise.resolve().then(() => 2);` |
| 19:40 | <benvie> | er Promise.resolve(1) |
| 19:40 | <Domenic_> | benvie: ah ok. in that case yeah looks right. |
| 19:40 | <benvie> | Domenic_: excellent, thanks! |
| 20:34 | <Hixie> | TabAtkins: tab order interaction with the 'order' property -- who is correct, chrome or firefox? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2850 |
| 20:34 | <Hixie> | (chrome uses dom tree order to find the next focusable area, firefox uses rendering tree order) |
| 20:36 | SamB | kind of wishes there was some way to interject text between <li> in an <ol>. Unindented. Or, heck, start a new <ol>, if he could just ask that the numbering pick up where the previous appropriately-nested <ol> ... |
| 20:36 | <Hixie> | picking up again is something i want to do |
| 20:36 | <Hixie> | let me see if there's a bug one it... |
| 20:37 | <SamB> | Hixie: well, firefox's sounds more likely to do what the user will expect in the absense of any attention to tab order from the stylesheet author |
| 20:37 | <Hixie> | don't see anything on file, so if you want to track it, http://whatwg.org/newbug . But it's probably not going to happen any time soon, since even reversed="" isn't yet describable with CSS. |
| 20:38 | <Hixie> | (actually, maybe this would be easier than reversed="") |
| 20:38 | <SamB> | hmm, I'm not sure how CSS is supposed to do the counting anyway ... |
| 20:38 | <Hixie> | there's 'counter' properties |
| 20:39 | <Hixie> | re focus, i'm thinking firefox is right too... |
| 20:39 | <TabAtkins> | I just got in, one sec. |
| 20:39 | <TabAtkins> | Hixie: http://dev.w3.org/csswg/css-flexbox/#order-accessibility is clear, 'order' doesn't affect tab-order. |
| 20:39 | <Hixie> | oh, interesting |
| 20:40 | <TabAtkins> | (This was added after a rather useful review by the i18n wg.) |
| 20:40 | <Hixie> | i'm not sure this makes sense |
| 20:40 | <Hixie> | how do you write a web page that behaves sanely both with and without flex? |
| 20:41 | <SamB> | I knew there was a reason I worded it the way I did ;-) |
| 20:41 | <TabAtkins> | Write it with a sane ordering in the raw markup, and then use flexbox as necessary to re-order things visually. |
| 20:41 | <SamB> | TabAtkins: well, how do you keep the USER sane |
| 20:41 | <Hixie> | right but you want the tab order to follow the visual order, usually |
| 20:41 | <SamB> | can CSS set the tab order? |
| 20:41 | <TabAtkins> | With even a modicum of care, this'll give you a *more useful* tab ordering, as the useful stuff is at the front. |
| 20:41 | <Hixie> | so if it's reorderd, you want a different tab order than if it's not |
| 20:42 | <Hixie> | SamB: in theory, but not in practice, as far as i know |
| 20:42 | <TabAtkins> | It's a flaw that tab order is affected by whether you want your sidebar on the left or on the right. |
| 20:42 | <TabAtkins> | SamB: Yeah, there's a property for it, but no implementations. |
| 20:42 | <SamB> | Chrome might want to practice that ;-) |
| 20:42 | <Hixie> | TabAtkins: if you sidebar is on the left, surely you want it earlier in the tab order than if it's on the right. no? |
| 20:43 | <SamB> | TabAtkins: hmm, yes, it's a flaw, but at least it's easy for the user to understand |
| 20:43 | <TabAtkins> | No, you almost always want sidebar to tab after content. |
| 20:43 | <TabAtkins> | As it has less important links in it. |
| 20:43 | <TabAtkins> | Note that 'order' is basically a vastly easier, less hacky way to do reordering that you can already do today with floats and negative margins. |
| 20:43 | <TabAtkins> | The old "holy grail" layouts. |
| 20:44 | <Hixie> | take www.whatwg.org/ |
| 20:44 | <Hixie> | would it be wrong to use CSS to reorder the links? |
| 20:44 | <SamB> | ... is it possible to say "I want this element's contents to have generally earlier tab order than that other element" in user CSS? |
| 20:44 | <Hixie> | seems like it's purely presentational what order they come in |
| 20:44 | <SamB> | even if nothing will actually do it |
| 20:44 | <Hixie> | SamB: there's a nav-index property in css3 ui, but nobody implements it currently as far as i know |
| 20:45 | <TabAtkins> | Hixie: If the ordering is changed because a different order makes sense, then that different order probably makes sense in all media, and should be in the source. |
| 20:45 | <SamB> | I mean as opposed to having to do something that matches each tabable element |
| 20:45 | <Hixie> | TabAtkins: i change the order randomly based purely on aesthetic grounds, though. the logical order is unrelated to what order they are shown in. |
| 20:45 | <Hixie> | TabAtkins: i mean, it seems to me like this is a perfect use of flex 'order' |
| 20:45 | <TabAtkins> | Then it doesn't matter, except insofar as using the various CSS methods wont' affect tab order, so it'll be confusing. |
| 20:45 | <Hixie> | right |
| 20:46 | <SamB> | TabAtkins: if the tab order bears no resemblance to the visual order whatever, and there are more than a handful of items, users are not going to be happy about that |
| 20:46 | <Hixie> | hence it seems like you'd want it to follow rendering order... |
| 20:46 | <TabAtkins> | This isn't an order-specific thing, though. Flexbox can lay things out right-to-left, or bottom-to-top. Grid can put things in any order whatsoever. |
| 20:46 | <TabAtkins> | The correct solution, which we want to pursue at some point in the future, is a more global switch that says "use a visual tab order". |
| 20:47 | <Hixie> | i guess i don't understand why you wouldn't want that to be the default |
| 20:47 | <TabAtkins> | Because it's not the default, and we can't change it to be the default, probabyl. |
| 20:47 | <SamB> | Hixie: well, having a switch would be an improvement either way |
| 20:47 | <Hixie> | it's the default in firefox, as far as i can tell |
| 20:47 | <Hixie> | why wouldn't we be able to make it the spec default? |
| 20:47 | <SamB> | actually I think it's BETTER to say that the default is unspecified |
| 20:47 | <TabAtkins> | What is the default in Firefox? Having it affected by 'order'? Or having it be visual order? |
| 20:48 | <Hixie> | yeah |
| 20:48 | <SamB> | because the user might change it anyway |
| 20:48 | <SamB> | in their userstyle |
| 20:48 | <Hixie> | TabAtkins: hence my question above about firefox vs chrome on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2850 |
| 20:48 | <SamB> | (without using !important) |
| 20:49 | <Hixie> | anyway i guess i can leave the default order undefined for now |
| 20:49 | <Hixie> | since it's mostly a UI issue |
| 20:49 | SamB | eagerly anticipates grid |
| 20:50 | <SamB> | hmm, though, can that steal nested elements from their parents? |
| 20:50 | <TabAtkins> | Hixie: Okay, FF adjust tab-index with 'order', but not anything else. It's violating the spec. |
| 20:51 | <TabAtkins> | For example, check out http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2851 |
| 20:51 | <SamB> | it's not as if the HTML spec doesn't wilfully violate dozones of other specs ;-) |
| 20:51 | <TabAtkins> | Like I said, this is *not* an 'order'-specific issue, and we shouldn't try to hack 'order' by itself. |
| 20:51 | <Hixie> | yeah i don't think it should be defined per 'order' |
| 20:52 | <SamB> | what else is there at the moment? |
| 20:52 | <Hixie> | my real question here is when you've got a control focused that isn't in the tab order at all (tabindex=-1), and you hit tab, should i pick the next control in the dom tree, or the next control in the rendering tree? |
| 20:52 | <TabAtkins> | If you want HTML to say that tab ordering should be visual, go for it. Won't affect me at all. |
| 20:53 | <TabAtkins> | DOM tree is how it works today. |
| 20:53 | <Hixie> | (right now it's "should follow platform conventions" for the tab order of controls that are in the order, fwiw) |
| 20:54 | <SamB> | that sounds like a sane default |
| 20:54 | <Hixie> | DOM tree is how it works today _in chrome_. in firefox, it's not. |
| 20:54 | <TabAtkins> | Are there any FF exceptions besides 'order'? |
| 20:54 | <SamB> | whatever "platform conventions" might mean ;-) |
| 20:54 | <Hixie> | (see e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2852 ) |
| 20:54 | <Hixie> | dunno |
| 20:54 | <Hixie> | i can't think of any other ways to affect rendering tree order |
| 20:55 | <SamB> | TabAtkins: what else is there that unambiguously reorders things in the rendering tree? |
| 20:55 | <SamB> | in firefox, I mean |
| 20:55 | <SamB> | what does IE do? |
| 20:55 | <Hixie> | (flex-direction just reverses the order for layout, but the rendering tree itself is still the same as the dom tree, right? same with floats, abs pos...) |
| 20:55 | <TabAtkins> | SamB: The notion of "reorders" is ambiguous itself. Does flex-direction:row-reverse reorder things? |
| 20:56 | <SamB> | TabAtkins: I'd lean towards "no" |
| 20:56 | <TabAtkins> | And any notion of 'order' pretty much goes out the window when you involve Grid. |
| 20:56 | <TabAtkins> | (Grid does define an ordering that is used by some things in the spec, but it's fairly arbitrary.) |
| 20:56 | <Hixie> | part of the problem with using the DOM tree is that the focusable areas aren't always _in_ the DOM tree, or they map to multiple elements, or multiple areas map to one element, which makes it hard to use the DOM tree |
| 20:56 | <SamB> | TabAtkins: I dunno, there are some typical notions of order in tables |
| 20:57 | <TabAtkins> | SamB: Tables dont' overlap cells, though. And they're clearly row-major. |
| 20:57 | <TabAtkins> | Hixie: I get that. |
| 20:58 | <SamB> | I meant abstract tables, not necessarily HTML tables |
| 20:58 | <SamB> | but yes, abstract tables don't overlap cells either |
| 20:58 | <Hixie> | i guess i can just use the control group order, that's a (more or less) defined order that handles this already |
| 20:59 | <Hixie> | (HTML tables actually can overlap cells in edge cases) |
| 20:59 | <TabAtkins> | "can", but it's allowed to not overlap them. |
| 21:00 | <Hixie> | in the HTML model, they are just defined to overlap. |
| 21:01 | <Hixie> | how it renders is a CSS issue. |
| 21:01 | <Hixie> | :-) |
| 21:01 | <SamB> | TabAtkins: I don't see a way they could not overlap |
| 21:01 | <SamB> | are you proposing that the overlapping bit be shoved into a different "column"? |
| 21:01 | <TabAtkins> | You just push the columns over more. It's nasty. |
| 21:02 | <Hixie> | btw that's one of the things we should drop when we get around to updating the table spec |
| 21:02 | <Hixie> | all the browsers do overlap |
| 21:02 | <SamB> | but in any case, well-behaved HTML tables do not perpetrate such evil |
| 21:02 | <SamB> | Hixie: is this actually *allowed*, or is the behavior just specified-ish? |
| 21:03 | <Hixie> | how do you mean? |
| 21:03 | <SamB> | can conforming documents have overlapping table cells? |
| 21:03 | <Hixie> | conforming documents can't, no. |
| 21:03 | <Ms2ger> | I think not |
| 21:03 | <Hixie> | but it's not "just specified-ish". it's specified. |
| 21:03 | <Hixie> | in painful detail. |
| 21:04 | <SamB> | Hixie: it sounded like there was an alternative behavior here that you wanted to drop because nobody actually implements that alternative anyway |
| 21:05 | <Hixie> | CSS table rendering is only vaguely defined. (or at least, was only so, last i checked) |
| 21:05 | <Hixie> | one of the ways it's vague is that handling of overlapped cells involves multiple permissible renderings. |
| 21:05 | <Hixie> | i'm saying we should tighten it down to just allow what is commonly implemented. |
| 21:06 | <TabAtkins> | Huh. Am I doing something wrong here? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2854 |
| 21:06 | <TabAtkins> | Yeah, when we actually define table rendering, that shit'll get thrown out. |
| 21:06 | <TabAtkins> | My rowspans and colspans dont' seem to work in that table. |
| 21:06 | <SamB> | hmm, you mean like it would be allowed to just let one table cell "own" that gridcell and the other table cell(s) could be potentially non-rectangular? |
| 21:06 | <Hixie> | TabAtkins: you have your rowspan and colspan backwards |
| 21:07 | <Hixie> | TabAtkins: (you can tell that they're working, the top right cell is a few pixels wider than the one below it) |
| 21:07 | <Hixie> | SamB: what do you mean by "allowed"? |
| 21:07 | <Hixie> | SamB: i'm not proposing any authoring conformance criteria changes |
| 21:07 | <TabAtkins> | Ah, durp. |
| 21:07 | <SamB> | I mean under the current unspecified table rendering |
| 21:07 | <Hixie> | SamB: i forget what the precise allowed renderings are |
| 21:10 | <Hixie> | hmmm |
| 21:10 | <Hixie> | so normally, tabbing around a dialog jumps you to the start from the end |
| 21:11 | <Hixie> | but what if you're a <dialog> inside an iframe? |
| 21:13 | <SamB> | hmm, I don't really know what <dialog> is, but why do you mention the iframe? |
| 21:14 | <Hixie> | well normally if you have an iframe, tabbing from the last thing in the iframe tabs to the thing after the iframe in the parent doc |
| 21:15 | <Hixie> | so if we have a dialog in the iframe, does tabbing from the end return you to the top of the dialog, as if it was a real separate window, or does it tab you out of the doc to the parent doc |
| 21:18 | <SamB> | maybe it should be possible to choose? |
| 21:18 | <Hixie> | how? |
| 21:18 | <SamB> | well, perhaps something on the iframe? |
| 21:18 | <Hixie> | (making things an option is rarely the sign of good design, btw) |
| 21:18 | <Hixie> | when would you use one vs the other? |
| 21:18 | SamB | goes to read up on dialog ... |
| 21:25 | <SamB> | hmm, dialogs in iframes sound kind of ... confusing to start with |
| 21:25 | <Hixie> | yeah, no kidding |
| 21:25 | <Hixie> | probably best to allow tabbing out |
| 21:26 | <SamB> | yes, probably |
| 21:57 | <SamB> | hmm, this whole "commands" thing seems kind of odd |
| 21:58 | <SamB> | what, exactly, is it for? |
| 22:04 | <SimonSapin> | Hixie: I’m importing CSS2.1 commit history from CVS. There are commits by ijacobs, ihickson, and ian. Do you know who is the third? |
| 22:04 | <Hixie> | heh |
| 22:05 | <Hixie> | sample edits? |
| 22:05 | <SimonSapin> | all from 1997 |
| 22:06 | <Hixie> | get a copy from then and look at the editor's list? |
| 22:08 | <Hixie> | i bet it's ijacobs. are there any edits from ijacobs before the last edit from ian? |
| 22:09 | <Hixie> | try to correlate edits to what is written in https://lists.w3.org/Archives/Member/w3c-css-wg/1997JulSep/0227.html |
| 22:09 | <Hixie> | see if any of the edits mention san jose around the time of https://lists.w3.org/Archives/Member/w3c-css-wg/1997JulSep/0146.html |
| 22:10 | <Hixie> | see if there's any chapter-10 edits that correspond to the same timeframe as https://lists.w3.org/Archives/Member/w3c-css-wg/1997OctDec/0056.html |
| 22:11 | <SimonSapin> | There are commits from ijacobs both before and after the time range of commits from ian, but not in the middle |
| 22:11 | <SimonSapin> | It’s probably him, thanks |
| 22:12 | <Hixie> | np |
| 22:46 | <tantek> | Hixie, you didn't join CSSWG til at least 1998, how would you have CVS edits in 1997? |
| 22:48 | <Hixie> | i didn't join til 2000, i didn't even join www-style until dec 1998 iirc |
| 22:59 | <tantek> | Hixie that sounds about right. |
| 23:24 | <Hixie> | fascinating |
| 23:24 | <Hixie> | tabbing from the first input in the following case leads you to the second input: <input tabindex=-1><input tabindex=2><input tabindex=1> |
| 23:25 | <Hixie> | but in the following case, it leads you to the third: <input tabindex=-1><iframe srcdoc="<input tabindex=2><input tabindex=1>"> |
| 23:25 | <Hixie> | (in chrome) |
| 23:25 | <Hixie> | (in firefox, it leads you to the viewport of the iframe, which is what the spec will actually require) |
| 23:26 | <Hixie> | (assuming there's no dialogs around) |
| 23:30 | <Hixie> | tantek: in retrospect, if i'd known then that 16 years later i'd be speccing focus navigation around iframes, something that should have been specced in HTML4 in 1997 at the latest, i dunno if i'd have bothered to subscribe. :-P |
| 23:31 | <tantek> | Hixie, I believe the expression you're looking for is, ignorance was bliss. |
| 23:32 | <Hixie> | i think it's more "ignorance leads to poor decisions" :-P |