06:41 | <zcorpan> | i don't understand the purpose of CSSConditionRule http://dev.w3.org/csswg/css-conditional/#the-cssconditionrule-interface |
07:41 | <jgraham> | gsnedders: Well it is possible I broke the review earlier. Or it is possible that you should ask jl :) |
07:59 | <zcorpan> | do events have a document associated with them? |
08:07 | <zcorpan> | they do |
08:07 | <zcorpan> | at least for the purpose of pageX |
08:15 | <zcorpan> | or maybe a window |
08:21 | <Ms2ger> | UIEvents, that is |
08:23 | <zcorpan> | MouseEvent |
08:53 | <zcorpan> | anyone feel like bikeshedding? https://www.w3.org/Bugs/Public/show_bug.cgi?id=17152 |
09:19 | zcorpan | isn't sure what to make of https://www.w3.org/Bugs/Public/show_bug.cgi?id=14072 |
10:06 | <hsivonen> | zcorpan: I much prefer your attitude in that bug report |
10:07 | <hsivonen> | zcorpan: that sort of thing, if added, is exactly the sort of thing that hasty WebKit ports would fail to get right and that would require clueful manual testing and, hence, go untested |
10:08 | <zcorpan> | hsivonen: i'm almost tempted to spec the attributes to return 24 |
10:08 | <hsivonen> | even Firefox for Android gets things of that nature wrong |
10:08 | <zcorpan> | it would reduce fingerprinting |
10:08 | <hsivonen> | has Screen.colorDepth ever existed? |
10:09 | <jgraham> | Got to love the attitude of "it doesn't matter if anyone wants to use or implement this, because I believe it's The Right Thing To Do (TM)" |
10:09 | <hsivonen> | zcorpan: it's a shame that Firefox for Android uses 16-bit color on full color devices |
10:10 | hsivonen | wonders what Firefox for Android returns |
10:12 | <hsivonen> | zcorpan: Firefox for Android actually returns 16 for screen.colorDepth |
10:12 | <hsivonen> | which is actually right! |
10:12 | <zcorpan> | hsivonen: thanks |
10:12 | hsivonen | is surprised to see an API of this nature return true data |
10:13 | <hsivonen> | (16 being right for the *browser* but not the *device*, but the browser won't let you access the full capability of the device) |
10:15 | <jgraham> | hsivonen: Presumably if it's hardcoded to be 16, it's not hard to get the property right |
10:16 | <hsivonen> | jgraham: maybe |
10:16 | <jgraham> | If you had a mix of 16 and 24 and 12 and whatever, it would be much harder to get right |
10:16 | <hsivonen> | well, Gecko in general has a mix |
10:16 | <hsivonen> | but Gecko is forced to 16 on Android |
10:16 | <hsivonen> | which is sad in my opinion |
10:17 | <jgraham> | What's the reason? |
10:17 | <hsivonen> | jgraham: N800 was 16-bit, so things were made 16-bit |
10:17 | <hsivonen> | jgraham: then Fennec started running on 24-bit devices, but the N800 hard-coding persisted |
10:17 | <jgraham> | So it's "forced" in the sense that some of the code doesn't work on > 16bits? |
10:18 | <hsivonen> | jgraham: then changing to 24-bit would have regressed perf relative to the 16-bit status quo |
10:18 | <hsivonen> | jgraham: so switching to 24-bit is still actually a topic up for debate :-( |
10:18 | <hsivonen> | jgraham: it's forced in the sense that removing the forcing would regress memory footprint / perf |
10:19 | <jgraham> | OK, so it actually is forced |
10:19 | <jgraham> | More like #ifdef ANDROID; COLOR_DEPTH=16 than "huge swathes of code would need to be rewritten to support >16bits on android" |
10:19 | <hsivonen> | right |
10:23 | <zcorpan> | interesting |
10:23 | <zcorpan> | hsivonen: feel free to chime in on www-style |
11:12 | <gsnedders> | jgraham: Oh, I think I'm just misunderstanding how Critic handles it |
11:12 | <gsnedders> | jgraham: It's fine, I think |
11:13 | <gsnedders> | jgraham: But I would like to see all that reviewed :) |
11:35 | <jgraham> | gsnedders: Oh, you want me to run the review system *and* do the review? :p |
11:35 | <jgraham> | OK, I will look (not not now) |
11:44 | <karlcow> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete-tel |
11:44 | <karlcow> | ASCII digits and U+0020 SPACE characters, prefixed by a U+002B PLUS SIGN character (+) |
11:45 | <karlcow> | I was wondering if minus sign should be allowed too. |
11:45 | <karlcow> | so this +1-617-253-5702 and +1 617 253 5702 would be allowed |
11:45 | <karlcow> | https://tools.ietf.org/html/rfc3966 |
11:46 | karlcow | has a tendency to type +1-617-253-5702 in his address books |
12:08 | <gsnedders> | jgraham: Yay! |
12:08 | <jgraham> | s/not not/but not/ |
12:08 | <gsnedders> | jgraham: I guessed that :) |
12:09 | <jgraham> | Not sure what the "Yay" was for… |
12:12 | <gsnedders> | jgraham: It getting reviewed after, like, a month. |
13:01 | <zcorpan> | should an <svg> stay upright in vertical writing modes? |
13:02 | <zcorpan> | <img> (with svg in it) does. in blink/webkit, <svg> doesn't. |
13:02 | <SimonSapin> | zcorpan: what do <object>, <iframe> and <img> do? |
13:03 | <SimonSapin> | zcorpan: "The content of replaced elements do not rotate due to the writing mode: images, for example, remain upright. … |
13:03 | <SimonSapin> | However replaced content involving text (such as MathML content or form elements) should match the replaced element's writing mode and line orientation if the UA supports such a vertical writing mode for the replaced content." |
13:04 | <SimonSapin> | http://dev.w3.org/csswg/css-writing-modes/#writing-mode |
13:04 | <zcorpan> | SimonSapin: yeah. that doesn't clarify things much for me :-( |
13:04 | <zcorpan> | <svg> is an image |
13:04 | <SimonSapin> | I’d say ask fantasai |
13:04 | <zcorpan> | <svg> supports setting writing-mode of <text> etc |
13:09 | <zcorpan> | in IE10 <svg> is upright |
13:11 | karlcow | would say that the content of the SVG is a different context. |
13:12 | <karlcow> | >There is usually only one direction for all text throughout a book, but there are cases where horizontal writing mode is used in certain parts of vertically composed books (see [Fig.19]). Tables, captions for illustrations, running heads, and page numbers are usually composed horizontally in a page with a vertical writing mode. — http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading1_3 |
13:38 | <jgraham> | Is inline <svg> replaced content? |
13:39 | <pdr|uk> | jgraham, I think so |
13:52 | <zcorpan> | jgraham: yes |
13:53 | <zcorpan> | hmm, in scrollIntoView i've assumed that the element has the same writing mode as the scrolling box, but that's not necessarily the case |
14:36 | <mounir> | Hixie: ping |
15:14 | <dglazkov> | good morning, Whatwg! |
15:14 | <Ms2ger> | G'day |
16:25 | <mounir> | Hixie: un-ping |
16:50 | <Ms2ger> | SimonSapin, I would approve of more mathematical proofs in specs ;) |
16:52 | <SimonSapin> | well, this one is not strictly required to define the feature |
16:54 | <SimonSapin> | Ms2ger: it’s a bonus so that the next person doesn’t spen a few hours getting the math wrong like I did :) |
16:55 | <SimonSapin> | s/spen/waste/ |
17:07 | <SimonSapin> | Eh. The one time I write math on a mailing list, I get it wrong :) |
17:07 | <Ms2ger> | SimonSapin, sounds like bz wants to see the proof ;) |
17:44 | <marcdm> | Ms2ger, do u know anything about the testing framework used in html5lib-py? |
17:45 | <Ms2ger> | No |
17:45 | <marcdm> | Does anyone? :( |
17:52 | <marcdm> | Can anyone tell me if the different treewalkers support similar APIs? |
20:47 | <jgraham> | marcdm: Depends what you mean |
20:47 | <jgraham> | The point of treewalkers is that they all have the same external API |
20:47 | <jgraham> | But obviously different internal APIs |
20:48 | <jgraham> | Esentially they normalise the process of iterating a tree over several tree formats |
21:11 | <marcdm> | jgraham: I went looking at the code and found out how it/they work |
21:11 | <marcdm> | just created instances of them and poked around in ipython |
21:13 | <marcdm> | I was trying to write a test to expose a bug in html5lib-python ... but couldn't figure out how to reproduce it using another treewalker from etree |
22:35 | <Hixie> | TabAtkins: in case it dropped off your radar, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22118 |