| 04:28 | <MikeSmith> | join #infobot |
| 04:28 | <MikeSmith> | oops |
| 05:32 | <MikeSmith> | cool http://caniuse.com/feed.php?id=136 |
| 07:25 | <MikeSmith> | IANA directly sent me some questions and comments about the application/microdata+json |
| 07:25 | <MikeSmith> | if I forward it to you on list somewhere, can you reply? |
| 07:26 | <MikeSmith> | Hixie: ↑ |
| 07:31 | <annevk> | whoa, three people are now going to edit XMLHttpRequest |
| 07:31 | <annevk> | I wonder how that goes |
| 07:32 | <MikeSmith> | annevk: XHR1 or real XHR? |
| 07:33 | <annevk> | No idea actually, presumably real XMLHttpRequest? |
| 07:33 | <annevk> | I'm somewhat skeptical about the appointed editors, but we'll see |
| 07:38 | <MikeSmith> | annevk: speaking of editors I don't remember Hallvord doing much with the clipboard spec any time lately |
| 07:39 | <MikeSmith> | wonder if he's planning to keep maintaining it or not |
| 08:29 | <MikeSmith> | System Applications WG charter just now finally approved |
| 08:29 | <MikeSmith> | congrats to abarth |
| 08:29 | <MikeSmith> | let the good times roll |
| 08:35 | <SimonSapin> | MikeSmith: is this WG meant to standardize what boot2gecko has been doing, or something like it? |
| 08:36 | <MikeSmith> | SimonSapin: http://www.w3.org/2012/09/sysapps-wg-charter |
| 08:37 | <MikeSmith> | http://www.w3.org/2012/09/sysapps-wg-charter#rec-track |
| 08:37 | <MikeSmith> | and http://www.w3.org/2012/sysapps/ |
| 08:38 | <MikeSmith> | http://www.w3.org/2012/sysapps/#roadmap |
| 08:39 | <hsivonen> | I get the discussion on the security model will be “fun” |
| 08:39 | <hsivonen> | s/get/bet/ |
| 08:39 | <MikeSmith> | yup |
| 08:39 | <SimonSapin> | fun in what sense? |
| 08:39 | <MikeSmith> | SimonSapin: in the "not fun" sense |
| 08:40 | <SimonSapin> | like hard to get right? |
| 08:40 | <MikeSmith> | yah |
| 08:40 | <hsivonen> | SimonSapin: like a long list of prior art and people with differing opinions |
| 08:40 | <MikeSmith> | abarth gots a draft already at http://abarth.github.com/sysapps/drafts/security.html |
| 08:41 | <hsivonen> | Mozilla has become better at proposal naming. Tizen tries with e.g. “Bluetooth”, but Mozilla has “Web Bluetooth” |
| 08:41 | <hsivonen> | worked with Audio for Chrome |
| 08:42 | <MikeSmith> | http://abarth.github.com/sysapps/drafts/runtime.html#differences-from-the-web-platform is also worth reading |
| 08:56 | <MikeSmith> | hsivonen: btw dunno if you noticed that the W3C HTML5 spec now allows absolute URLs in rel values |
| 08:56 | <MikeSmith> | in addition to the standard keywords and registered keywords |
| 08:56 | <MikeSmith> | so I wrote a patch the supports that |
| 08:56 | <MikeSmith> | for the validator |
| 08:56 | <MikeSmith> | should we make that support W3C-only? |
| 08:57 | <MikeSmith> | dunno how you feel about whether it's a good idea or not to allow URLs there |
| 09:08 | <hsivonen> | MikeSmith: oh it wasn’t allowed before? I’ve lost track. |
| 09:08 | <MikeSmith> | hsivonen: wasn't allowed before |
| 09:08 | <hsivonen> | MikeSmith: does the W3C allow upper-case ASCII in those URLs? |
| 09:08 | <MikeSmith> | Hixie wontfixed it I think. lemme find the bug |
| 09:09 | <hsivonen> | didn’t I even write a CP for this at some point? |
| 09:09 | <MikeSmith> | hsivonen: I think the HTML5 spec says they're treated case-insenstively |
| 09:09 | <MikeSmith> | hsivonen: oh, don't remember if you did |
| 09:09 | MikeSmith | looks for the issue |
| 09:09 | <zcorpan> | i thought it was allowed before but then hixie removed the url support (maybe only in the whatwg version) |
| 09:09 | <zcorpan> | but i might be making that up |
| 09:10 | <hsivonen> | MikeSmith: http://lists.w3.org/Archives/Public/public-html/2011Oct/0058.html |
| 09:10 | <hsivonen> | MikeSmith: I’m ok with what I wrote in that email |
| 09:11 | <MikeSmith> | OK |
| 09:11 | MikeSmith | reads |
| 09:12 | <MikeSmith> | hsivonen: OK, that's the way I got it implemented anyway, I think. Because I'm just using the common.data.uri.absolute / w:iri datatype |
| 09:12 | <hsivonen> | MikeSmith: ok |
| 09:12 | <MikeSmith> | that is, already ignoring the ASCII-only restriction in the HTML5 spec |
| 09:14 | <hsivonen> | it’s kinda sad, though, that some people want to be able to put URLs there |
| 09:14 | <MikeSmith> | hsivonen: I'm not sure any real people actually want to |
| 09:14 | <danbri> | like http://www.w3.org/TR/2012/WD-rdfa-in-html-20120911/ ? |
| 09:15 | <danbri> | FWIW schema.org prefers the RDFa Lite idiom, where @property carries the property and relationship names (to avoid forcing publishers to guess whether @property or @rel is the place to use) |
| 09:15 | <MikeSmith> | danbri: that's an extension of the spec that already defines looser requirements on rel values |
| 09:16 | <MikeSmith> | danbri: ah good |
| 09:16 | <danbri> | I like how extensions can legalise things |
| 09:16 | <MikeSmith> | hsivonen: patch (small) https://gist.github.com/3817679 |
| 09:16 | <danbri> | wish real laws worked that way ;) |
| 09:16 | <MikeSmith> | heh |
| 09:16 | <MikeSmith> | that would be cool |
| 09:17 | <danbri> | in http://www.w3.org/TR/2012/REC-rdfa-core-20120607/ I see only prefixed terms and simple terms, not full links |
| 09:17 | <MikeSmith> | hsivonen: you'll see the one other thing is I changed the wording on the error message that gets emitted if the rel value is not an absolute URL or valid keyword |
| 09:17 | <MikeSmith> | if you don't like that wording lemme know |
| 09:17 | danbri | assumes mikesmith and ivanherman coordinate constantly on such stuff |
| 09:18 | <MikeSmith> | well |
| 09:18 | <MikeSmith> | not so constantly |
| 09:18 | <MikeSmith> | but now and then yeah |
| 09:19 | <danbri> | :) |
| 09:19 | <danbri> | I'm very interested to learn of non-schema.org uses of Microdata btw |
| 09:19 | <MikeSmith> | the RDFa WGers as much seem to think URLs are ugly and so we should come up with all kinds of ways to protect users from seeing them |
| 09:19 | <danbri> | I just tell RDF people to buy a ****ing short domain name, these days |
| 09:20 | <MikeSmith> | heh |
| 09:20 | <danbri> | there's a lot of different between http://ogp.me/foo and http://www.w3.org/1999/02/22-rdf-syntax-ns#foo |
| 09:21 | <MikeSmith> | I will be surprised if any large number of normal users ever start using RDFa or Microdata for any reason other than to get the search-engine juice or some other real benefits instead of hypothetical ones |
| 09:22 | <danbri> | is someone suggesting otherwise? |
| 09:22 | <MikeSmith> | I don't think the syntax or whatever existing tool support is going to make much of a difference to normal authors either way |
| 09:22 | <MikeSmith> | danbri: no, I guess not, true |
| 09:22 | <danbri> | having helpful checkers and authoring tools ought to be able to improve data quality |
| 09:22 | <danbri> | having more than one high profile consumer would really help too |
| 09:23 | <MikeSmith> | yup |
| 09:23 | <danbri> | currently too many people (re schema.org) just go with whatever looks good in Google Rich Snippets |
| 09:26 | <a-ja> | fwiw: coding polyglot uF/uF2/microdata is royal pita |
| 09:26 | <danbri> | can you summarise the woes? what is baseline painfulness of polyglot? |
| 09:26 | <danbri> | or do you mean mixing those systems, not mixing xhtml/html Polyglot? |
| 09:26 | <Ms2ger> | Heh, polyglot |
| 09:26 | <Ms2ger> | People actually do that? |
| 09:28 | <a-ja> | tried and abandoned as ridiculously non-semantic |
| 09:28 | <a-ja> | div/span-itis |
| 09:29 | <a-ja> | actually, abandoning uF would make it not so bad....cept noone parses for it yet |
| 11:12 | <sps> | hi! |
| 11:12 | <sps> | is here hsivonen? |
| 11:13 | <sps> | someone can help me? |
| 11:16 | <payman> | sps: You can try asking your question and finding out :) |
| 11:17 | <sps> | I want to know what is the relationship between pixel/point and real dimension on screen |
| 11:19 | <sps> | If I want to display a text with a height of 2cm on a screen with 128x1024 with 83.6ppi how many pixel I need to set on a text software for Win7 OS? |
| 11:20 | <sps> | and the same height on a screen of 800x600? |
| 11:24 | <payman> | sps: "height: 2cm"? http://www.w3.org/TR/css3-values/#absolute-lengths |
| 11:25 | <payman> | (or what do you mean by text software?) |
| 11:25 | <sps> | yes 2cm |
| 11:26 | <sps> | sorry I mean a software like Word, LibreOffice, ecc... |
| 11:27 | <sps> | or any other software that displays text on the screen |
| 11:28 | <payman> | well, what I mentioned should work in a web browser. |
| 11:28 | <sps> | ok |
| 11:28 | <sps> | and for others? |
| 11:30 | <payman> | I don't know. |
| 11:31 | <jgraham> | Hmm, CSS 2cm won't always be 2cm |
| 11:31 | <jgraham> | It will be a specific number of CSS pixels |
| 11:35 | <zcorpan> | but it should be about 2cm if you pinch your fingers at an arm's length with the intended viewing distance :-) |
| 11:36 | <sps> | that is? |
| 11:37 | <payman> | jgraham: can't it be more precise if you use it with media queries? |
| 11:38 | <annevk> | media queries uses the same crappy units |
| 11:38 | <sps> | and so? |
| 11:43 | <jgraham> | It isn't possible on the Web Platform to specify precise physical dimensions |
| 11:43 | <jgraham> | This should be clear if you consider a laptop displaying a 2cm square |
| 11:43 | <payman> | how about print media? |
| 11:44 | <jgraham> | If you connect that to a projector, you wouldn't expect it to remain at 2cm |
| 11:44 | <zcorpan> | payman: depends on the intended viewing distance to the printed material :-) |
| 11:44 | <jgraham> | That would be totally useless, not to mention impossible to actually pull off |
| 11:44 | <hsivonen> | sps: jgraham is right. There is no way to specify true physical dimensions on the Web Platform |
| 11:44 | <payman> | so it depends on the reference pixel? |
| 11:44 | <jgraham> | Because with a projector you don't know the physical size of the image in advance |
| 11:45 | <hsivonen> | payman: yes. CSS cm, etc., are all fixed multiples of CSS px |
| 11:45 | <jgraham> | payman, sps: All CSS units are per-spec effectively angular units |
| 11:46 | <zcorpan> | a css pixel is an angle from the user to the intended viewing distance, where the resolution is 96 CSS pixels per physical inch at an arm's length, or some such (iirc) |
| 11:46 | <zcorpan> | and all other css units get translated to css pixels |
| 11:46 | <hsivonen> | (Even Prince cannot guarantee how exactly your PDF gets printed) |
| 11:47 | <jgraham> | http://www.w3.org/TR/css3-values/pixel1.png |
| 11:47 | <payman> | mmm, web platform is pretty useless. |
| 11:47 | <payman> | (for this use case at least) |
| 11:48 | <jgraham> | "The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch)." |
| 11:48 | <jgraham> | payman: It's hard to imagine how it could be any other way |
| 11:48 | <jgraham> | px could be a physical unit |
| 11:49 | <jgraham> | But then people would complain about it being too thin on high resolution devices |
| 11:49 | <annevk> | what does 2ch mean for a font without 0 |
| 11:49 | <annevk> | seems like something that ought to be defined |
| 11:50 | <payman> | jgraham: yeah, but wouldn't it be nice to have a css unit that translates ubiquitously to standard metric unit? |
| 11:51 | <jgraham> | payman: It would only make sense for printed media |
| 11:51 | <jgraham> | Given how good browsers aren't at printing, this doesn't seem like the most pressing problem |
| 11:53 | <payman> | so I guess sps might have better luck softwares other than web browsers. |
| 11:53 | <payman> | +using |
| 11:53 | <jgraham> | Yes, if you want precise, media-specific, layout, the web stack isn't welloptimised for your use case |
| 11:54 | <jgraham> | (the rule is something like "'precise', 'media independent', choose one) |
| 12:08 | <sps> | mmm |
| 12:15 | <sps> | ok, you said: in css we have absolute units but really visualization depends on distance from screen |
| 12:17 | <sps> | but I want relation real/virtual for screen display not for browser, but for usul software on OS |
| 12:18 | <sps> | sorry, for usual software |
| 12:20 | <sps> | for example: how many points I have to set text on MS Word to have a text with a real height of 2cm on my screen? |
| 12:45 | <sps> | I read this: http://hsivonen.iki.fi/units/ |
| 12:46 | <zcorpan> | sps: that seems outdated |
| 12:46 | <sps> | I know that in typography a 1inch text height is equivalent to 72 points. But if I try to visualize a 72pt text on MS Word I see an uppercase text with an height of 1.8cm with a zoom of 90% (real ppi=89.3/96, on Windows following your suggestion), and 2cm with a zoom of 100%. When I try to print it I get a text with an height of 1.8cm, the same I see in my screen. In MS Word, with a 90% zoom, I see a dimension of page quite real. |
| 12:55 | <sps> | no-one can help me? |
| 12:56 | <SimonSapin> | sps: is this a question on MS Word or on CSS? |
| 12:58 | <hsivonen> | I marked http://hsivonen.iki.fi/units/ as outdated. Sorry about failing to do so earlier. |
| 13:02 | <matjas> | zcorpan: just came across http://simon.html5.org/test/html/rendering/color-attributes/parseColorString.js after writing out the algo in JS myself |
| 13:02 | <matjas> | zcorpan: the “replace non-BMP symbols with `00`” step is missing |
| 13:02 | <zcorpan> | matjas: that's likely outdated |
| 13:03 | <matjas> | zcorpan: I used something like this for that part http://pastebin.com/raw.php?i=LFGaGKhp |
| 13:03 | <zcorpan> | matjas: the dom uses 16-bit code units so code points above BMP get turned into '00' anyway |
| 13:04 | <matjas> | zcorpan: I see, I was writing something that needed to work in Node, though |
| 13:04 | <hsivonen> | sps: When you set the font size to 72 pt, you are not setting the capital letter height to 1 inch |
| 13:05 | <hsivonen> | sps: you are just mapping the internal coordinate space of the font |
| 13:05 | <hsivonen> | sps: the capital letters are not required to be 1 em high |
| 13:07 | <hsivonen> | and the em in fonts is just a font-dependent multiple of internal units |
| 13:08 | <hsivonen> | you should assume no relationship between the metrics of the letter M and the em |
| 13:09 | <hsivonen> | speaking of font internal units, I wonder if there’s a spec or documentation about which of the 3 way of computing the line height of a TTF/OTF font browsers are supposed to use |
| 13:10 | <matjas> | zcorpan: step 11 in the algo has changed, but the change doesn’t seem to match Opera/Chrome/Safari’s implementation (unless I implemented it incorrectly) |
| 13:10 | <matjas> | s/While input's length not a multiple of three/While input's length is zero or not a multiple of three/ |
| 13:10 | <matjas> | weird |
| 13:13 | <hsivonen> | fonts are not so dissimilar from the Web. weird legacy: http://typophile.com/node/13081 |
| 13:51 | <annevk> | zcorpan: how would they get turned into 00 if you do not handle surrogates specifically? |
| 14:34 | <sedovsek> | o/ |
| 14:34 | <sedovsek> | One question... |
| 14:34 | <sedovsek> | t = document.createTextNode(' ') |
| 14:34 | <sedovsek> | el.appendChild t |
| 14:34 | <sedovsek> | setTimeout( |
| 14:34 | <sedovsek> | -> el.removeChild t |
| 14:34 | <sedovsek> | 0 |
| 14:34 | <sedovsek> | ) |
| 14:34 | <sedovsek> | This does not cause refflow? |
| 14:34 | <sedovsek> | While t = document.createTextNode('x') does? |
| 14:35 | <sedovsek> | (the code above is CoffeeScript). I add an empty element to cause reflow. |
| 14:42 | <zcorpan> | annevk: a code point above BMP are two code units, and each code unit gets converted to a 0, ergo 00 |
| 14:46 | <annevk> | zcorpan: oh, the input is code points? |
| 14:47 | <zcorpan> | to the spec's algorithm, yes. although the wording around code points and code units changed at some point |
| 14:48 | <annevk> | oh I thought we were discussing http://simon.html5.org/test/html/rendering/color-attributes/parseColorString.js |
| 14:48 | <zcorpan> | the input to that is a JS string |
| 14:49 | <annevk> | yeah so looks like that will fail |
| 14:49 | <zcorpan> | why? |
| 14:57 | <annevk> | zcorpan: well if the spec talks about 8 code points and you take 8 code units you're in trouble |
| 14:58 | <zcorpan> | annevk: the spec replaces code points above BMP with '00' before doing any interesting processing so it ends up the same |
| 14:58 | <zewt> | (i don't know what you guys are talking about, but it sounds gross) |
| 14:58 | <annevk> | sorry you had to explain that twice |
| 14:59 | <zcorpan> | np :-) |
| 15:11 | <matjas> | zcorpan: ah, my bad indeed, for JS engines that’s an unnecessary step |
| 16:47 | <MikeSmith> | been trying to make Henri's htmlparser code not emit errors "unescaped" semicolon-less ampersands but finding that in most cases the code emits the errors without ever getting to the point of seeing if there's a semicolon at the end or not |
| 16:48 | <MikeSmith> | instead what it's doing is first making sure the character sequence after the ampersand matches a sequence that begins a know entity |
| 16:49 | <MikeSmith> | known named character reference |
| 16:49 | <MikeSmith> | and if it reaches the point where the sequence does not begin a known named character reference, it emits and error at the point |
| 16:49 | <MikeSmith> | and doesn't bother to see if there's any following semicolon |
| 16:59 | <dglazkov> | good morning, Whatwg! |
| 18:58 | <Hixie> | still no opinions on adding trim=""? https://www.w3.org/Bugs/Public/show_bug.cgi?id=17972 |
| 18:59 | <Hixie> | too soon? shouldn't happen? should happen soonest? |
| 19:07 | <annevk> | neutral :) |
| 19:10 | <tantek> | Hiixe, has sufficient need been demonstrated for trim=""? |
| 19:11 | <Hixie> | i dunno |
| 19:11 | <tantek> | sounds like a nice-to-have |
| 19:11 | <Hixie> | the people in the bug (mostly moz people) seem quite emphatic |
| 19:11 | <Hixie> | but yeah |
| 19:11 | <zewt> | sounds reasonable based on the first post but doesn't sound critical--I never expect client-side validation to be an exact match to server-side validation |
| 19:13 | <tantek> | looks like all theoretical talk |
| 19:13 | <zewt> | definitely agree that stripping for all @required is breaking and a bit nuts |
| 19:13 | <tantek> | let's see some error rate numbers |
| 19:14 | <tantek> | as opposed usability hypothesizing by non-usability people |
| 19:14 | <tantek> | I'd punt |
| 19:14 | <tantek> | show me the data |
