| 01:31 | Seta00 | wonders what would be a good way for <input> to support multiple files |
| 01:32 | <Hixie> | it already does, assuming you mean <input type=file> and assuming you mean in the spec |
| 01:32 | <Hixie> | <input type=file multiple> |
| 01:34 | <Seta00> | Hixie, oh, nice. I was helping my mom, Flash was being silly when she was trying to upload some photos to Facebook, and the "classic" uploader uses multiple <input type=file> elems, which is awful |
| 01:34 | Seta00 | checks the impl status on |file multiple| |
| 02:42 | <Hixie> | ok i give up |
| 02:42 | <Hixie> | how do i make an <input type=text> exactly fill a table-cell ? |
| 02:42 | <Hixie> | horizontally |
| 02:42 | <Hixie> | (vertically it should use whatever height it needs) |
| 02:44 | <othermaciej> | width: 100% doesn't work? |
| 02:45 | <Hixie> | width:100% seems to give it the width of the browsing context (?) |
| 02:45 | <Hixie> | (on an unrelated note, firefox's 3d dom view is ludicrously gratuitous and i love it) |
| 02:46 | Hixie | tries stuffing more nodes into the dom so there's a block between the table-cell and the input |
| 02:49 | <Hixie> | nope, still no luck |
| 02:49 | <Hixie> | wtf |
| 02:49 | <othermaciej> | what are you using to size the table cell? |
| 02:49 | <othermaciej> | (I assume something explicit since otherwise it would shrink to fit the input and give you what you want anyway) |
| 02:50 | <Hixie> | the table cell is in a table that has a fixed width. the table has two columns, the other cells in the table have text, and i'm hoping for the two columns to magically size based on the content in the other cells |
| 02:50 | <Hixie> | maybe i need to make the input width:auto and make it the cell itself |
| 02:51 | <Hixie> | nope |
| 02:51 | <othermaciej> | this seems to do what I expect: |
| 02:51 | <othermaciej> | <table width="100%" style="border: 1px solid black;"> |
| 02:51 | <othermaciej> | <tr><td>boo</td><td style="border: 1px solid black;"><input style="width: 100%;"></td></tr> |
| 02:52 | <Hixie> | does it work if an earlier row has so much text in its second cell that it wraps to multiple lines? |
| 02:53 | <Hixie> | (table has a fixed width of some number of ems) |
| 02:56 | <Hixie> | hmmm... i think i know what's going on |
| 02:56 | <Hixie> | my table is inside a div with overflow:auto so i didn't notice that my table actually is much wider than i want |
| 02:56 | <Hixie> | because of an earlier cell having unbreakable wide text |
| 02:57 | <Hixie> | is there a white-space value that forcibly cuts extra-wide text? |
| 03:09 | <othermaciej> | word-break: emergency I think |
| 03:09 | <othermaciej> | but I don't believe that works in all browsers |
| 03:15 | <zewt> | AryehGregor: re: CDNs: and if you don't want to use https for latency reasons, that's more reason to want verification with http+aes |
| 03:18 | <zewt> | very bizarre that someone's actually claiming that Blob.close() isn't the same as neuter; that seems self-evident |
| 03:23 | <Hixie> | othermaciej: didn't see to help in webkit |
| 03:26 | <Hixie> | word-break: break-word did it |
| 07:34 | <zcorpan> | "This bug has over 130 bugs duplicated against it. What a number !!" https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c220 (almost standards mode quirk) |
| 07:38 | <zcorpan> | "somewhat quirky mode" https://bugzilla.mozilla.org/show_bug.cgi?id=153032#c7 |
| 07:51 | <annevk> | so if you call Blob.close() it would invoke XMLHttpRequest.abort() if passed to send() |
| 07:52 | <annevk> | that seems somewhat insane |
| 07:56 | <annevk> | why is http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#position_options_interface not a dictionary? |
| 07:56 | <annevk> | is nobody reviewing those drafts? |
| 07:57 | <rniwa> | annevk: sadly, very few people understand how WebIDL works |
| 07:58 | <annevk> | actually, it has NoInterfaceObject so it's not so bad, I guess they might not have updated their draft yet |
| 07:58 | <annevk> | rniwa: seems like it |
| 07:58 | <MikeSmith> | scott_gonzalez: please ping me when you're back -- wanted to ask if you'd been able to get validation working with nu.validator.servlet.VerifierCommandLine class (and if not I can help you get it working) |
| 07:58 | <rniwa> | annevk: I think what they meant was Dictionary |
| 07:58 | <rniwa> | but didn't know how to use it properly :) |
| 07:58 | <rniwa> | annevk: happens |
| 07:58 | <zcorpan> | or maybe it didn't exist when they wrote that |
| 07:58 | <rniwa> | even I didn't know WebIDL had dictionary 'til recently because nobody had used it |
| 08:00 | <zcorpan> | btw, you're reading an outdated TR/ draft :-P |
| 08:03 | <zcorpan> | ok i have no idea how to spec the almost standards quirk |
| 08:06 | <annevk> | rniwa: yeah, the problem is that other people copy such patterns without knowing what is going on o_O |
| 08:06 | <annevk> | rniwa: witness public-web-notification |
| 08:06 | <annevk> | anyway, no damage done yet and feedback to geolocation sent |
| 08:06 | <annevk> | zcorpan: who said I was reading that draft? :) |
| 08:07 | <zcorpan> | annevk: well you complained that it didn't use a dictionary, so you must have read some of it :-P |
| 08:08 | <annevk> | I read the editor's draft, then found a permanent pointer to the error |
| 08:09 | <annevk> | not sure why I thought that was useful... |
| 08:35 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#the-line-height-calculation-quirk |
| 08:37 | <zcorpan> | hmm that's not correct, i should probably say "non-collapsed whitespace" or some such |
| 08:39 | <zcorpan> | there |
| 09:08 | <zcorpan> | so at one extreme, we have moz, where any border, padding or margin of an inline breaks out of the line height quirk. at the other end, we have opera and ie9, where none of border, padding or margin break out of the quirk. webkit makes border-left, border-right, padding-left and padding-right break out |
| 09:09 | <zcorpan> | i've specced webkit for now |
| 09:43 | <zcorpan> | "What we do is act as if there was an empty inline element at |
| 09:43 | <zcorpan> | the start of every line box, which has a line-height the same as the block's. |
| 09:43 | <zcorpan> | This causes the line-height of the box to be the minimum height of each line |
| 09:43 | <zcorpan> | box in the block, as required by CSS2. In Quirks mode only, we need to avoid |
| 09:43 | <zcorpan> | generating that anonymous inline." (https://bugzilla.mozilla.org/show_bug.cgi?id=24186 ) |
| 09:43 | <zcorpan> | where does css require that? |
| 09:55 | <zcorpan> | "If the inline box contains no glyphs at all, it is considered to contain a strut (an invisible glyph of zero width) with the A and D of the element's first available font." http://www.w3.org/TR/CSS21/visudet.html#leading ? |
| 09:57 | <zcorpan> | though that doesn't say that an anonymous inline should be present at the start of blocks |
| 09:59 | <zcorpan> | oh, not blocks, line boxes |
| 10:21 | <zcorpan> | "Any text that is directly contained inside a block container element (not inside an inline element) must be treated as an anonymous inline element." http://www.w3.org/TR/CSS21/visuren.html#anonymous but that doesn't say to generate an anonymous inline element when there's no text and then an inline element |
| 10:41 | <zcorpan> | aaaah. "On a block container element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element. " |
| 10:49 | <zcorpan> | ok, another quirk specced. http://simon.html5.org/specs/quirks-mode#the-blocks-ignore-line-height-quirk |
| 11:04 | <zcorpan> | hmm. wonder why i was redirected to the japanese version of mdn when trying to log in |
| 12:53 | <bga> | http://ondras.zarovi.cz/demos/rubik/ |
| 13:32 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#the-percentage-height-quirk probably has something wrong (moz aborts on body if i read the source correctly but http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1369 doesn't seem to match that) |
| 13:40 | <annevk> | zcorpan: shouldn't http://simon.html5.org/specs/quirks-mode#html be in HTML? |
| 13:41 | <zcorpan> | yeah |
| 13:42 | <zcorpan> | i've filed a spec bug for <font> |
| 13:42 | <zcorpan> | the other quirk maybe we can drop |
| 13:42 | <annevk> | zcorpan: the steps in 3.1 seem to suggest that valid values such as "currentcolor" are ignored |
| 13:43 | <zcorpan> | annevk: it's not ignored, it just gets the normal css treatment |
| 13:44 | <annevk> | "then a token in the property's value token must be interpreted using the following algorithm" |
| 13:44 | <annevk> | the algorithm does not state anything like that |
| 13:46 | <annevk> | zcorpan: maybe you want to point out somewhere that ideally quirks are defined as part of where the features are defined, but that this specification is filling the gaps for now? and maybe point from there to e.g. the HTML parser quirk, document.compatMode, ... |
| 13:51 | <zcorpan> | annevk: fixed 3.1 and 3.2 |
| 13:51 | <zcorpan> | annevk: i could point that out in an email to www-style |
| 13:52 | <annevk> | yeah maybe that's better |
| 13:52 | <annevk> | I wish :any-link was implemented everywhere |
| 14:06 | <scott_gonzalez> | MikeSmith: Jörn Zaefferer started working on it, but he said it had a lot of dependencies and the build was taking a really long time so he stopped. |
| 14:06 | <scott_gonzalez> | MikeSmith: We're looking for somethings mall that we can include in the jQuery UI repo and run as part of our build. |
| 14:06 | <scott_gonzalez> | *something small |
| 14:07 | <MikeSmith> | I see |
| 14:07 | <MikeSmith> | scott_gonzalez: I can probably put together a standalone Relax NG schema |
| 14:08 | <MikeSmith> | which in case you don't know what that is, it's like a DTD |
| 14:08 | <MikeSmith> | you'd probably still need to use Java to do checking with that |
| 14:08 | <MikeSmith> | but it would be just one dependency |
| 14:09 | <scott_gonzalez> | Java as a dependency should be fine. We used YUI Compressor for a long time. |
| 14:09 | <MikeSmith> | OK |
| 14:10 | <MikeSmith> | the tradeoff is, it would not be able to do checking that's as complete as what validator.nu does |
| 14:10 | <scott_gonzalez> | What kinds of validations would be missing? |
| 14:10 | <MikeSmith> | an example is, validator.nu checks charset values against the IANA registry, to make sure they are registered values |
| 14:10 | <MikeSmith> | and it does the same thing for encoding names |
| 14:10 | <scott_gonzalez> | Ok, well we only use utf-8 :-) |
| 14:11 | <MikeSmith> | ok |
| 14:12 | <scott_gonzalez> | That type of stuff should be fine. I mostly just want to make sure we don't have any misspelled tags/attributes, unclosed tags, etc. |
| 14:12 | <MikeSmith> | OK |
| 14:12 | <annevk> | should stop checking against the IANA registry |
| 14:12 | <annevk> | and instead UTF-8, warn for anything else in http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html and otherwise scream |
| 14:13 | <annevk> | instead only accept utf-8* |
| 14:13 | <MikeSmith> | yeah we could do that eventually |
| 14:13 | <MikeSmith> | we didn't have anything like the Encoding spec before |
| 14:13 | <MikeSmith> | but right now we are just following what the HTML5 spec requires |
| 14:14 | <MikeSmith> | if the HTML spec is changed to reference the Encoding spec, then we change the validator |
| 14:14 | <MikeSmith> | scott_gonzalez: so I think I can have something for you by next week |
| 14:15 | <scott_gonzalez> | MikeSmith: That'd be fantastic. |
| 14:16 | <annevk> | MikeSmith: yeah, still have to finish some boring/difficult algorithms :/ |
| 14:17 | <MikeSmith> | yeah |
| 14:17 | <MikeSmith> | I talked to Richard about the Encoding spec btw |
| 14:18 | <MikeSmith> | I think he's worried it's too restrictive |
| 14:18 | <annevk> | well, that was the goal |
| 14:23 | <annevk> | oh that is disappointing |
| 14:23 | <annevk> | the math in deviceorientation is external |
| 14:26 | <jgraham> | External in what sense? |
| 14:27 | <annevk> | <object> |
| 14:31 | <annevk> | grrr |
| 14:31 | <annevk> | W3C and their silly tons of groups each reinventing WebApps |
| 14:31 | <annevk> | and a couple of us who're not quite, but near to "oh well" cleaning up the mess |
| 14:35 | <zewt> | that's why I cringed when I heard about these "community groups"; seems like nothing but more fragmentation |
| 14:41 | <annevk> | pretty much the only thing I can still get upset over; people not doing the right thing because "oh my god; charter expires; cannot get to PR; cannot get to CR" |
| 14:52 | <hsivonen> | "Thanks for clarifying that it is not browser innovation and competition that this is enabling. |
| 14:52 | <hsivonen> | " |
| 14:52 | <hsivonen> | foolip++ |
| 14:55 | <zcorpan> | ok i made something up, it's probably wrong. http://simon.html5.org/specs/quirks-mode#the-percentage-height-quirk |
| 14:55 | <zcorpan> | that's it for today folks |
| 16:28 | <dglazkov> | good morning, Whatwg! |
| 16:28 | <dglazkov> | and hatwig! |
| 16:57 | <bga_> | hm. let we build ui for japan. text from up to down |
| 16:57 | <bga_> | i can not imagine how it will look. vertical button, vertical tab items ... |
| 16:58 | <bga_> | any related images? |
| 17:11 | <Ms2ger> | zcorpan++ |
| 17:11 | Ms2ger | is all for making things up in specs |
| 17:14 | <bga_> | http://i.msdn.microsoft.com/dynimg/IC93452.png |
| 17:15 | <bga_> | seem nobody want to support tradition writing system of japanise |
| 17:16 | <bga_> | but support arabic right to left is ok |
| 17:23 | <bga_> | http://ompldr.org/vY3oyYg/japaniseWindow.png |
| 17:23 | <bga_> | some concept |
| 17:33 | <michel_v> | is it widely requested? |
| 17:35 | <michel_v> | somehow related: I wonder if boustrophedon is doable with some JS |
| 17:35 | <michel_v> | something that would dynamically make lines be ltr then rtl then ltr etc |
| 17:43 | <michel_v> | bga_: actually, are there fonts for up to down writing? |
| 17:43 | <michel_v> | nevermind, there's those that are used in books |
| 17:48 | <bga_> | michel_v i dont know how it required by real world. But its possible |
| 17:48 | <bga_> | http://ompldr.org/vY3oycA/japaniseSimpleDialog.png http://ompldr.org/vY3oybg/japaniseMessageBox.png |
| 17:49 | <bga_> | seems its enough to understand concept |
| 17:50 | <karlcow> | michel_v: http://la-grange.net/2007/07/23-japanese-typography |
| 17:55 | <karlcow> | hmm interesting I had not noticed that Lion had vertical layout now in textEdit http://photos.appleinsider.com/LionTE2.png |
| 17:56 | <bga_> | im not alone :) |
| 17:58 | <michel_v> | oh, interesting |
| 17:58 | <michel_v> | karlcow: yeah, saw that in books before. not sure how well that translates in terms of readability on screen |
| 17:58 | <niloy> | transform: rotate(-90deg) |
| 17:58 | <michel_v> | which is a medium that you usually can not rotate (except for mobile devices) |
| 17:59 | <michel_v> | niloy: more to it than that. you'd have to also rotate the japanese characters back 90 degrees |
| 17:59 | <niloy> | ooh ya |
| 18:02 | <Hixie> | foolip: oops, missed some e-mails. |
| 18:02 | <Hixie> | foolip: (re my latest e-mail to you) |
| 18:10 | <Ms2ger> | MikeSmith, yt? |
| 18:16 | <Hixie> | foolip: ok, now i've replied. |
| 18:18 | <Hixie> | i'm amused by the http+aes-criticising people saying that they think it should be in a different spec, but not volunteering to edit one, given that when i first wrote it one of teh first things i said was that i was hoping someone would put it in another spec for me... |
| 18:19 | <Ms2ger> | That still amuses you? :) |
| 18:20 | <Hixie> | well it's like they think it's a big revelation that it should be in a different spec |
| 18:20 | <Hixie> | as if someone has ever argued otherwise |
| 18:21 | <Ms2ger> | But surely you want all the stuff in your spec! ;) |
| 18:21 | <Ms2ger> | Hmm, I haven't heard anybody call it "Ian's spec" lately |
| 18:25 | <aklein> | smaug____: yt? curious if you have any thoughts on http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0145.html |
| 18:27 | <Ms2ger> | He's on a call |
| 18:49 | <smaug____> | aklein: meeting... |
| 19:11 | <smaug____> | aklein: I'll reply to that later this week |
| 19:11 | <aklein> | smaug____: ok, thanks |
| 19:11 | <smaug____> | (once I've decided what I want the behavior to be :) ) |
| 19:11 | <aklein> | :) |
| 19:11 | smaug____ | will do now only mutationobservers for few days |
| 19:11 | <smaug____> | +reviews, and some more reviews |
| 19:12 | <Ms2ger> | \o/ |
| 19:12 | <aklein> | smaug____: if it helps at all, the test cases I referred to are up on https://bugs.webkit.org/show_bug.cgi?id=80549 |
| 19:17 | <smaug____> | Ms2ger: I also need to not read public-html to maintain the remainings of my mental health. |
| 19:18 | <Ms2ger> | I never read public-html, and I'm still insane :) |
| 19:19 | <smaug____> | indeed. What would you become after reading public-html... scary |
| 19:21 | <Ms2ger> | :) |
| 19:46 | <Philip`> | Should http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3Ediv%20%7B%20content%3A%20%22A%22%20%7D%3C%2Fstyle%3E%0D%0A%3Cdiv%3EB%3C%2Fdiv%3E result in "A" or "B"? |
| 19:47 | <Philip`> | (Recentish Opera says A, recentish Firefox says B) |
| 19:49 | <Ms2ger> | Depends |
| 19:50 | <Ms2ger> | css3-content (use to) say A |
| 19:50 | <Ms2ger> | (That spec still has "Ian Hickson, Opera Software") |
| 19:50 | <Ms2ger> | And still follows Opera |
| 19:53 | <Philip`> | Does something else say something else? |
| 19:53 | <Ms2ger> | Ah, it does have "This specification is not being actively maintained, and should not be used as a guide for implementations. It may be revived in the future, but for now should be considered obsolete." |
| 19:54 | <Ms2ger> | CSS21 only defined content for pseudos |
| 20:00 | <jgraham> | Yeah, so apparently that feature causes us a few site compat issues |
| 20:00 | <Ms2ger> | Really? :( |
| 20:00 | <jgraham> | Well it seems like it's a small enough number that we could sitepatch or something |
| 20:02 | Philip` | was curious since he found a site that it breaks |
| 20:02 | <jgraham> | But it's not really clear if the smart thing is to drop it and assume it will go away, or wait for someone to start maintaining the spec |
| 20:02 | <jgraham> | (and then for others to implement) |
| 20:09 | <jgraham> | Philip`: Pointer? |
| 20:16 | <annevk> | if we drop content:url() too, annevankesteren.nl breaks |
| 20:16 | <annevk> | not really sure that's acceptable |
| 20:16 | <Ms2ger> | Pff |
| 20:17 | <Ms2ger> | Who uses that |
| 20:17 | <smaug____> | add sitepatch for annevankesteren.nl |
| 20:17 | annevk | raises hand |
| 20:21 | <Philip`> | jgraham: http://www.malideveloper.com/ (right sidebar) |
| 20:29 | <jgraham> | Philip`: Oh, that site is annoying |
| 20:29 | <jgraham> | But thanks |
| 20:36 | <Philip`> | Annoying for more reasons than the autoplaying video? |
| 20:37 | <jgraham> | No, mainly for the autoplaying, autolooping, noisy video |
| 22:03 | <rniwa> | jgraham, annevk: yt? |
| 22:04 | <rniwa> | AryehGregor: yt? |
| 22:24 | <Hixie> | new otherWindow.Path() -- should it be associated with window.document or otherWindow.document? |
| 22:24 | <Hixie> | what do we have in the way of precedent on this front? |
| 22:24 | <jgraham> | rniwa: kind of here |
| 22:25 | <Hixie> | new otherWindow.Image().ownerDocument.window == otherWindow |
| 22:25 | <rniwa> | jgraham: hi, can we all agree that we shouldn't do: http://dev.w3.org/csswg/css3-regions/#dom-namedflow ? |
| 22:25 | <Hixie> | i guess i'll follow that pattern |
| 22:25 | <rniwa> | jgraham: css3 region spec is introducing a new dynamic node list that contains the list of all elements that belong to the same named flow |
| 22:25 | <rniwa> | which means that accessing elements in this node list would require style resolution :( |
| 22:26 | <hober> | there's a lot wrong with the regions om stuff |
| 22:26 | <rniwa> | hober: hi hober |
| 22:26 | <rniwa> | hober: can we ask www-style folks to fix that? |
| 22:27 | <jgraham> | rniwa: yeah, that sounds daft |
| 22:27 | <hober> | rniwa: you could post a followup to http://lists.w3.org/Archives/Public/www-style/2012Feb/1337.html |
| 22:30 | <jgraham> | I'm not really clear why the draft is so obsessed with making everything live. I think that's just confusing |
| 22:31 | <jgraham> | (as well as being bad for other reasons, particularly in the nodelist case) |
| 22:31 | <astearns> | jgraham: what do you mean by 'live'? |
| 22:32 | <rniwa> | hober: yeah... my email address has been kicked out of www-style for some mail deamon errors :( |
| 22:32 | <rniwa> | apparently my mail deamon was spamming theirs |
| 22:33 | <rniwa> | jgraham: I agree. |
| 22:34 | <rniwa> | jgraham: but then some people prefer it be live :) |
| 22:35 | <Hixie> | a = new Path(); a.moveTo(100,100); a.lineTo(100,200); var b = new Path(); b.moveTo(200,100); b.lineTo(200,200); a.addFill(b); a.lineTo(300,100); a.lineTo(300,200); context.fill(a); |
| 22:36 | <Hixie> | er, make that last fill(a) be stroke(a); |
| 22:36 | <Hixie> | what should get painted? |
| 22:37 | <Hixie> | i think the answer is a vertical line next to a backwards N |
| 22:37 | <Hixie> | anyone disagree? |
| 23:10 | <Hixie> | how does http://www.whatwg.org/specs/web-apps/current-work/#path-objects (incomplete) look to people so far? |
| 23:10 | <Hixie> | Philip`: your opinion in particular would be most welcome |
| 23:56 | <Hixie> | ok i give up |
| 23:56 | <Hixie> | wtf should the directionality of a Path object be? |
| 23:56 | <Hixie> | ltr or rtl? |
| 23:56 | <Hixie> | or based on something, and if so, what? |
| 23:57 | <Hixie> | the "obvious" answer is to base it on the element passed to the Path constructor, if any, or else the root element of the Document of the Window on which the constructor was called, if any, or else ltr |
| 23:57 | <Hixie> | but that seems like a quite complicated answer |
| 23:59 | <heycam> | how does directionality matter? |
| 23:59 | <heycam> | oh for the text layout |
| 23:59 | <heycam> | methods |
| 23:59 | <heycam> | I would say take the direction property of the element passed in |
| 23:59 | <heycam> | and ltr otherwise |
