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