00:18
<TabAtkins>
aleray: The html5lib authors are in Europe, so probably aren't watching the channel now.
00:18
<aleray>
ok
00:19
<aleray>
be right back tommorow then
00:19
<aleray>
thanks
06:27
<zcorpan>
is there a pull request for https://github.com/w3c/web-platform-tests/tree/master/old-tests/submission/Opera/media ? i didn't find anything in the list of pull requests
06:59
<zcorpan>
TabAtkins: shouldn't StreamInit be EventStreamInit etc?
07:47
<jgraham>
zcorpan: I can't see any evidence of a PR for those tests
07:48
<jgraham>
By which I mean "I can't see a commit that modifies that path except for the one that created it", so it is possible that my git0fu is just too weak
07:50
<jgraham>
zcorpan: You should make one :)
07:51
<jgraham>
(I think the problem might have been that it wasn't clear what "the right place" for those tests was)
08:39
<aleray>
hi, I'm trying to create an html scrapper using html5lib in python. After parsing the page, I often get broken html. Here is a minimal example: http://dpaste.com/1064087/ is there anything wrong with it?
08:40
<jgraham>
Define "broken html"?
08:50
<aleray>
jgraham, html i didn't write :P
08:51
<jgraham>
aleray: html5lib doesn't make any guarantees that the output conforms to authoring requirements. All it promises is that given random mal-formed input, the tree created will be the same as the DOM tree in browsers.
08:52
<jgraham>
It is quite possible to create a tree that is "broken" for some value of "broken"
08:52
<aleray>
jgraham, that's what i'm looking for
08:52
<jgraham>
i.e. html5lib is not supposed to be like tidy
08:52
<jgraham>
What are you looking for?
08:52
<aleray>
have the same rendering as in web browser
08:53
<jgraham>
I guess you don't mean "rendering" since there are no graphics involved
08:53
<aleray>
so i don't get why http://dpaste.com/1064087/ output is different from just wgetting the page
08:54
Philip`
wonders whether tree.write tries to emit HTML or XML
08:54
<jgraham>
It's different because that code uses to html5lib parse the page and reserialize it. wget just reads the bytes off the wire.
08:55
<jgraham>
That's also a good point
08:55
<aleray>
when i look at, let say, a copy of nytimes homepage fetched with wget and one fetched with my code look different in my browser
08:55
<jgraham>
YOu probably don't want to use XML serialization
08:55
<aleray>
jgraham, ahhh
08:56
<jgraham>
aleray: More like Philip`, ahhh :)
08:57
<aleray>
oups confused... do you see what I mean jgraham ?
09:00
<jgraham>
aleray: Try replacing tree.write('/tmp/foo.html') with open('/tmp/foo.html', 'w').write(html5lib.serialize(tree, tree="lxml"))
09:01
<aleray>
jgraham ok I try!
09:02
<aleray>
jgraham, humm "UnicodeEncodeError: 'ascii' codec can't encode character u'\xb7' in position 4245: ordinal not in range(128)"
09:02
<aleray>
I will never get how coding works :P
09:02
<Ms2ger>
s/'w'/'wb'/?
09:03
<jgraham>
encoding="utf8" to the serializer or something
09:04
<aleray>
oh yeah!
09:04
<aleray>
thanks
09:04
<aleray>
a lot
09:06
<aleray>
:)
09:19
<zcorpan>
reyre__: i added your comment here https://critic.hoppipolla.co.uk/showcomment?chain=74 - feel free to raise more issues there if you find any (ask jgraham if you need assistance with critic)
09:55
<zcorpan>
Switched to branch 'submission/opera-web-messaging-2'
09:55
<zcorpan>
Your branch and 'upstream/master' have diverged,
09:55
<zcorpan>
and have 2 and 1146 different commits each, respectively.
10:04
zcorpan
wonders what to do, if anything
10:05
<annevk>
So I noticed someone gave up editing CSSOM?
10:06
<annevk>
He switched all the tooling around. Fixed no bugs. And then gave up? And still got paid for that too I reckon. Sometimes I wish media would pay some attention to the bullshit that's going on.
10:12
<marcosc>
:)
10:13
<Ms2ger>
Turns out editing isn't so simple after all?
11:18
<Ms2ger>
Anyone feel like reviewing https://github.com/w3c/web-platform-tests/pull/45 ? :)
11:19
<zcorpan>
annevk: do you recall why cssom-view specs MouseEvent.screenX etc? http://www.w3.org/mid/CANpe7K1J-9q52ekEe3W65MRTP_Z4Vocyp1urVXK05yp9U9U+KQ⊙mgc
11:20
<odinho>
jgraham: You should keep the commit info when you are moving commits next time.
11:20
<odinho>
jgraham: Either by using a patch (git format-patch + git am), or just cherry-picking it. IMHO
11:21
<zcorpan>
Ms2ger: i'll have a look
11:22
<annevk>
zcorpan: because that guy cannot read?
11:23
<annevk>
zcorpan: it should be part of the "User Interaction" specification I think, but only if it defines such things as whether or not it's pixels and what box we're talking about, etc.
11:23
<annevk>
(and hit testing)
11:24
<jgraham>
odinho: I didn't move a commit. I recreated it
11:24
<jgraham>
Because moving it would have left the file in the wrong place still
11:25
<jgraham>
s/recreated it/created a new one/
11:27
<annevk>
I took a crack at replying to glazou on that www-tag thread.
11:27
<annevk>
I must be missing something since it all seems so obvious. http://lists.w3.org/Archives/Public/www-tag/2013Apr/0059.html
11:29
<annevk>
marcosc: also, it seems you said much the same thing in the beginning. I'm surprised how quickly glazou turned to "you probably never worked for such companies". That's some bad faith.
11:36
<Ms2ger>
annevk, hm, can I still test that a.href reflects as a URL?
11:37
<odinho>
jgraham: Ohwell, it's possible to rewrite the patch too, but that's more involved :-)
11:37
<annevk>
Ms2ger: I guess
11:38
<jgraham>
odinho: Yeah, I could have done something insane or I could have just not bothered
11:38
<Ms2ger>
And where did a.media go?
11:39
<annevk>
Ms2ger: killed?
11:40
<Ms2ger>
I must have missed that memo
11:41
<Ms2ger>
Is blame.r7000 the most recent one?
11:42
<Ms2ger>
Ooh, http://www.whatwg.org/specs/web-apps/current-work/blames-list.cgi
11:45
<Ms2ger>
Heh, date.pubDate
11:46
<zcorpan>
https://github.com/w3c/web-platform-tests/pull/45 is not in http://w3c-test.org/web-platform-tests/submissions/ ?
11:48
<Ms2ger>
Is now
11:50
<Ms2ger>
Ah, here we are: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20521
11:59
<MikeSmith>
hsivonen: about the validator HTML4 thing, I'm rewriting the Schematron stuff in Java
11:59
<MikeSmith>
a la Assertions.java
12:00
<MikeSmith>
if that's not a good idea, lemme know
12:00
<MikeSmith>
but that will remove the Schematron dependency
12:00
<MikeSmith>
and thus the performance bottlenecks
12:00
<hsivonen>
MikeSmith: if the W3C still wants to run an HTML4 validator, it's a good idea
12:00
<MikeSmith>
yeah
12:00
<MikeSmith>
we need to actually
12:01
<MikeSmith>
we need for the validator.nu-based service to become the default service, replacing the existing legacy validator
12:02
<MikeSmith>
and a requirement of that is, it has to have HTML4 support
12:02
<odinho>
zcorpan: Should be no reason to wait on the web messaging tests, because you're saying they are okay, right?
12:02
<MikeSmith>
so this will give us that
12:03
<zcorpan>
odinho: i thought there was a requirement that somebody other than me needs to review them
12:04
<Ms2ger>
zcorpan, eh, you're a smart guy, go for it
12:04
<odinho>
Yeah. If you say they're good, should be okay.
12:06
<zcorpan>
annevk reviewed 6 files and found 1 issue
12:07
<darobin>
I didn't know that there was any kind of assertion in HTML4 that could be conducive to the writing of a validator
12:08
<zcorpan>
darobin: the html4 support in v.nu isn't an implementation of the html4 spec
12:10
<odinho>
zcorpan: Well, but the old process was, "wait a few days on a mailing list, then move them". But you say noone looked at them here inside Opera either?
12:11
<jgraham>
I did some level of review
12:11
<odinho>
zcorpan: We mostly find bugs after approvement also. Hard to catch everything in review.
12:11
<jgraham>
But not really "is this correct per spec"
12:11
<darobin>
zcorpan: what, you mean it doesn't check for case-insensitive numbers? I'm shocked...
12:11
<jgraham>
There are other reasons to like review e.g. it means that more than one person knows what is tested
12:11
<zcorpan>
darobin: what are case-insensitive numbers?
12:12
<MikeSmith>
darobin: we just inherited the assertions from a file that Petr Nalevka wrote back in the day
12:12
<MikeSmith>
what he based them on I'm not sure
12:12
<jgraham>
But since there are approximately 5 people in the world that have shown any interest in doing test review so far…
12:13
<MikeSmith>
darobin: but it's mostly assertions about ancestor-descendant restrictions
12:13
<jgraham>
Actually I guess 6 since Tina reviewed the SSE tests
12:13
<Ms2ger>
Oh, wow, someone got itemValue right while implementing a new element in Gecko, without me telling them
12:13
<darobin>
zcorpan: it's something that HTML4 has, e.g. http://www.w3.org/TR/html401/struct/tables.html#adef-rowspan
12:13
<MikeSmith>
darobin: like, a label element must not contain a nested label element
12:14
<jgraham>
Apparently review also allowed Ms2ger to have the occasional pleasant surprise
12:14
<darobin>
rowspan = number [CN] (where [CN] means case insensitive)
12:14
<odinho>
jgraham: Yes, to the bulk that :-)
12:14
<odinho>
s/bulk/bulk of/
12:14
<darobin>
MikeSmith: yeah I know, I was mostly poking fun at HTML4, not expecting people to take me seriously :)
12:14
<zcorpan>
darobin: [CN] means case *neutral*
12:15
<MikeSmith>
zcorpan: I think the html4 support in v.nu attempts to be an implementation of the HTML4 except that it doesn't use SGML parsing
12:15
<darobin>
gee, you kill the fun out of everything zcorpan
12:15
<zcorpan>
MikeSmith: the schema is an implementation of XHTML 1.0
12:15
<MikeSmith>
darobin: well I actually wonder if those assertions are stated normatively in the HTML4 spec. I doubt they are actually
12:15
<MikeSmith>
zcorpan: true
12:16
<darobin>
MikeSmith: maybe some are in the DTD?
12:17
<MikeSmith>
you mean as a comment?
12:17
<MikeSmith>
ah, o or SGML exclusions?a
12:18
<Ms2ger>
MikeSmith, looking for normative content in HTML4?
12:18
<MikeSmith>
I don't think the DTD has any excluations
12:18
<Ms2ger>
You must be new here
12:18
<zcorpan>
ok i merged web-messaging-2
12:18
<Ms2ger>
Now web-messaging-1?
12:19
<jgraham>
Then web-messaging-liftoff?
12:20
<MikeSmith>
Ms2ger: I am trying to put a piece of new cloth unto an old garment
12:21
<MikeSmith>
but I fear for that which is put in to fill it up taketh from the garment, and the rent is made worse
12:21
<MikeSmith>
at least Jukka seems to think so
12:21
<MikeSmith>
though he didn't put it in quite those words
12:22
<Ms2ger>
The rent is too damn high
12:22
<smaug____>
Ms2ger: possible an element which I reviewed?
12:22
Ms2ger
drops from 945 Fail to 191 Fail
12:23
<Ms2ger>
smaug____, nah, track
12:23
<MikeSmith>
Ms2ger: nicely riffed
12:23
<smaug____>
ah
12:23
<smaug____>
Ms2ger: didn't bz review that :)
12:23
smaug____
can't recall
12:23
<Ms2ger>
He is reviewing, yes
12:23
<Ms2ger>
And not too happy :)
12:25
<Ms2ger>
jgraham, a question...
12:25
<Ms2ger>
If I go to https://critic.hoppipolla.co.uk/6dda8721?review=5, tick a box, and submit the review...
12:25
<Ms2ger>
Then the new page it loads has other boxes ticked
12:26
Ms2ger
poofs for a bit
12:40
karlcow
reading www-tag and being sad about humanity
12:41
<annevk>
karlcow: I hope the latter did not follow from the former, 'cause then you might be in for a surprise
12:48
<hsivonen>
what if the former followed from the latter?
12:52
<annevk>
heh
13:02
<karlcow>
:)
14:03
<annevk>
Why is data:text/xml,<?xml version="1.0" encoding="bullshit"?><x/> well-formed?
14:03
<annevk>
I cannot find a statement in the standard that forbids that. Browsers seem to use utf-8...
14:15
<darobin>
bast [16:17] html-testsuite (master) $ echo '<?xml version="1.0" encoding="bullshit"?><x/>' | xmllint -
14:15
<darobin>
-:1: parser error : Unsupported encoding bullshit
14:15
<darobin>
<?xml version="1.0" encoding="bullshit"?><x/>
14:15
<darobin>
annevk: ^^
14:16
<annevk>
Okqy, but why does it think it's in error?
14:16
<annevk>
Why as in what am I missing in http://www.w3.org/TR/xml/#charencoding why
14:17
<gsnedders>
"It is a fatal error when an XML processor encounters an entity with an encoding that it is unable to process."
14:19
<hsivonen>
darobin: what do Chrome and IE do with that
14:19
<annevk>
That's some ambiguous use of entity
14:19
<darobin>
annevk: not in the context of the XML spec
14:19
<hsivonen>
darobin: my motivation to change Gecko for encoding bullshit is pretty low
14:20
<darobin>
hsivonen: I can't say I'm violently in favour either
14:21
<darobin>
hsivonen, annevk: Chrome gives an error
14:22
<darobin>
as does Safari
14:22
<darobin>
I'm running too much crap at this specific moment to load up an IE VM
14:22
<darobin>
I would expect it to dislike it though
14:22
<gsnedders>
annevk: How is that ambiguous?
14:23
<darobin>
gsnedders: I think he's thinking of entity references
14:23
<annevk>
darobin: I'm getting a blank page in IE
14:23
<annevk>
darobin: hsivonen: using http://dump.testsuite.org/xml/encoding-bullshit.xml
14:24
<annevk>
hsivonen: it does seem like something we could fix though at some point
14:24
<hsivonen>
annevk: great name for a test file
14:25
<hsivonen>
annevk: I'd rather implement XML5 than make XML 1.0 fail harder
14:25
<hsivonen>
annevk: but if you are writing patches these days...
14:26
<hsivonen>
annevk: since the encoding stuff is a hack outside expat, there's no easy way to make the YSoD show up with a sensible message in this case
14:26
<hsivonen>
one would need to write a non-expat-driven way to cause a YSoD for this
14:26
<annevk>
I want to give patching a try again someday. Not sure if making XML stricter is going to be the start :-)
14:27
<annevk>
Seems weird that expect would not ask the browser if the encoding is supported.
14:27
<hsivonen>
annevk: the encoding stuff happens before expat has a chance to do anything
14:27
<annevk>
Ah I see
14:28
<hsivonen>
expat's own encoding API is so weird that instead of using it, we do the conversion to UTF-16 outside expat and tell expat it's dealing with UTF-16
14:28
<annevk>
The whole encoding thing is kinda undefined too because the encodings are undefined. XML's black box.
14:29
<hsivonen>
if you can claim EXI is an encoding for XML, surely you can say this is XML on top of the Encoding Standard
14:29
<hsivonen>
or something
14:29
<hsivonen>
anyway, I have many other encoding-related patches to write first
15:47
<timeless>
hello world
15:47
<timeless>
anyone here play w/ <track>s and Cue objects?
15:47
<timeless>
i'm having problems w/ cue.onenter in Chrome
15:47
<timeless>
it works if i set a breakpoint on it, but it doesn't seem to fire otherwise :o
16:10
<Greg1>
Hi everyone - I'm reading about futures right now and am curious on browser support. And do I need an additional library for it.
16:11
<Ms2ger>
No browser support
16:11
<jgraham>
They haven't resolved yet
16:11
<Greg1>
I actually just ran into an issue yesterday where the callbacks weren't effective and this could be useful
16:11
<Greg1>
I figured as much - too bad
16:14
<darobin>
Greg1: I would expect them to start hitting browsers relatively soon though
16:14
<darobin>
also, I expect shims
16:15
<Greg1>
Awesome, are you guys working with the big 3 on this then (Chrome, FF, and IE)? And there will be decent backwards compatibality correct.
16:16
<annevk>
Greg1: https://github.com/slightlyoff/DOMFuture/ has an implementation in script
16:17
<slightlyoff>
we're looking to implement very shortly
16:17
<annevk>
Greg1: Google/Mozilla are on board with regards to implementing near term as far as I know, dunno about Microsoft
16:17
<slightlyoff>
(chromium that is)
16:17
<Greg1>
Oh ok - good
16:18
<gsnedders>
(MS basically never say anything, and then release a build.)
16:18
<darobin>
yeah
16:18
<slightlyoff>
Greg1: we need it to fix a ton of APIs that are pretty crufty right now (Web Crypto, IDB, geolocation, etc.)
16:18
<Greg1>
That's unfortunate - you would think they would want to reach out to devs
16:18
<darobin>
but we know that individual MSFTers like futures in general
16:18
<Greg1>
Why wouldn't they
16:18
<slightlyoff>
darobin: yep. Had a productive discussion with luke hoban at the last TC39
16:19
<darobin>
Greg1: the problem isn't that MS doesn't want to talk to dev, they really do want to
16:19
<gsnedders>
Not quite as amusing as Opera's old situation: you knew exactly what we were implementing, even though we couldn't say a thing, because of what feedback we were sending on the spec.
16:19
<slightlyoff>
darobin: and an MSFT person posted out on public script coord with some alternatives, so I think they're looking at it
16:19
<darobin>
the problem is that they're being watched like crazy by the EU so that they can never announce anything unless they're 100% certain that it ships
16:19
<Greg1>
Oh, interesting
16:19
<darobin>
slightlyoff: yeah I saw that; they've been looking for a while, they have something like that in Win8
16:20
<darobin>
Greg1: the problem IIRC is that at some point they announced support for something but eventually yanked it before shipping
16:20
<slightlyoff>
darobin: yes, and part of the design process was understandign all the choices they made in WinJS
16:20
<darobin>
this caused other browser vendors to implement that thing
16:20
<slightlyoff>
darobin: turns out they implemented 2 versions in WinJS
16:20
<gsnedders>
darobin: Longhorn was entirely that.
16:20
<darobin>
which in turn was cited as anticompetitive behaviour
16:20
<darobin>
I'm not a huge fan of MS's products, but the way the EU's been treating them has been unfair
16:20
<gsnedders>
darobin: Promised the world, shipped nothing. Middle management was running scared of saying anything publicly, even when they have a ready-to-ship product internally.
16:21
<darobin>
slightlyoff: well why only do one version, right? :)
16:21
<slightlyoff>
darobin: well, you live and learn
16:21
<slightlyoff>
which is sort of the A+/Q experience
16:21
<slightlyoff>
everyone keeps iterating on one or another bit of the core contract
16:21
<slightlyoff>
what we have now is really minimal for a reason
16:22
<Greg1>
slightlyoff: Sounds good
16:22
<Greg1>
So for now then I should use promises then
16:22
<slightlyoff>
Greg1: or you could use the p(r)ollyfill
16:22
<slightlyoff>
Greg1: they should interop (assuming your Promises impl is A+ compatible)
16:23
<Greg1>
Do you have a link to a library that you guys prefer that would match that spec?
16:24
<Greg1>
I get quite a few when going to p(r)ollyfill
16:24
<annevk>
Greg1: I just gave you a link
16:25
<Greg1>
annevk: hmmm... I don't see it (I'm using the Pidgin client)
16:26
<Ms2ger>
https://github.com/slightlyoff/DOMFuture/
16:26
<Greg1>
Thanks Ms2ger
16:26
<Ms2ger>
Np
16:53
<KyleBarnhart>
Hi
16:53
<KyleBarnhart>
I have a question regarding direction rtl
16:55
<KyleBarnhart>
If i have a box that's rtl with left 100px and width 50px does it go from 50px-100px of 100px-150px?
16:55
<KyleBarnhart>
*or not of
16:58
<KyleBarnhart>
I ask this because the WebVTT spec states that for a video width of 640px, if the direction is rtl and horizonal position of 45%, the left should be 352px and width 352px. That shoots it out of bound but makes sense if the width is going to the left instead of to the right.
17:01
<KyleBarnhart>
If I'm not clear about the direct rtl, I'm refering to right-to-left text such as arabic or hebrew
17:09
<dglazkov>
good morning, Whatwg!
17:11
WeirdAl
offers the stock mock response: meh
17:11
<WeirdAl>
:)
17:15
<jgraham>
dglazkov doesn't actually respond here, he just has a "good morning" script that does the text and marks the logs yellow
17:39
<dglazkov>
I totally respond here!
18:23
<Ms2ger>
"The Mobile Web Test Suites Working Group is launching today its first call for contributions to the Open Mobile Web Test Suite:"
18:23
<Ms2ger>
I wonder what happened to that
18:29
<jgraham>
It turns out that calling for contributions is easy and making contributions is hard?
18:29
<Ms2ger>
Hey man, they made a mobile version of the DOM1 test suite
18:30
<jgraham>
"yay"
18:31
<TabAtkins>
KyleBarnhart: directionality of abspos doesn't matter unless you're resolving an overconstrained situation.
18:32
<TabAtkins>
KyleBarnhart: Assuming that 'right' is "auto", then it'll work the same in rtl as ltr.
18:41
<scott_gonzalez>
Do web components have to be included via <link> or can the <element> be inline in the page?
18:42
<KyleBarnhart>
ok, thank you. There appears to be a bug in the spec.
18:42
<KyleBarnhart>
I've sent writting to the mailing list.
18:52
<scott_gonzalez>
dglazkov: Do you know if custom elements work in Canary without the polyfill?
18:55
<jgraham>
Holy crap, if anne doesn't like the email from critic just wait until he discovers the spam-fest that is github
18:56
<Ms2ger>
One email per comment?
18:56
Ms2ger
would be perfectly happy without tests for document.all, too
18:58
<gsnedders>
jgraham: Don't make me ping the review and spam you!
19:00
Philip`
loves review systems that end up sending you 37 emails for a single patch (mostly consisting of bots saying "I'm about to build this" and then saying "I built this")
19:02
<jgraham>
Yeah, one email per comment
20:11
<manu-db>
Ignore this if you need to get work done: "you work for W3 eh? undermining human society for illicit gains?" http://pastebin.com/raw.php?i=k92m5auk
20:18
<TabAtkins>
manu-db: Hahahahaha
20:18
<manu-db>
dude, keep reading, it gets so much better.
20:19
<TabAtkins>
wow, lolwut
20:20
<manu-db>
Also, I think we're going to try Futures in the JSON-LD API, experimentally at first and if the group likes them, we think we have a way forward to REC.
20:21
<TabAtkins>
Yay!
20:23
<gsnedders>
manu-db: Gold, absolute gold.
20:24
<TabAtkins>
Must be some weird meme-disease running around lately.
20:24
<gsnedders>
manu-db: And because it's always a target: it's all these semweb activities diverting resources from the important problems like solving the mathematical flaws in JS/DOM.
20:25
<manu-db>
gsnedders: You can't deny that the plan is working.
20:31
<astearns>
"anyone who understands the problem is party [to it's continuance]" - isn't he implicating himself, here (or perhaps only himself?)
20:34
<gavinc>
manu-db: Wow.
20:37
<hober>
reads like the timecube guy
20:38
<TabAtkins>
hober: Have you read the steelmanning of Timecube? http://squid314.livejournal.com/327646.html
20:38
<TabAtkins>
(Steelman is the opposite of strawman - interpret an argument in the strongest possible fashion, giving it every benefit of the doubt.)
20:39
manu-db
loves the timecube guy, we actually have a timecube clock in our offices.
20:39
<gavinc>
reads like every city council meeting here... sigh
21:03
<hober>
TabAtkins: i hadn't seen that, no
21:03
<hober>
TabAtkins: have you seen http://html5timecube.com/ ?
21:03
<TabAtkins>
Hahaha, no.
21:04
<divya>
thnx hober
21:04
<divya>
that was valuable.
21:05
<hober>
don't thank me, thank jernoble
21:05
jernoble
bows.
21:08
<MikeSmith>
hsivonen: OK I just now landed a change a the removes the schematron dependency from the HTML4 backend of v.nu, replaced with custom Java checker, a la Assertions.sch
21:08
<MikeSmith>
win 25
21:09
<Ms2ger>
lose 26
22:24
<jamesr_>
hober: nice
22:25
<jamesr_>
hober: do you know who runs it?
22:25
<jamesr_>
it's only using -webkit- prefixed transform properties
22:34
<hober>
jamesr_: "don't thank me, thank jernoble"
22:34
<jernoble>
jamesr_: or in this case, blame jernoble.
22:35
<jernoble>
jamesr_: guess i need a github repo. ;)
22:35
<jamesr_>
what about all those IE10 users? they need to experience the timecube too!
22:35
<jernoble>
i guess i'll doom them to be forever educated stupid.
23:13
<TabAtkins>
zcorpan: Based on CSSWG discussion, the CSS parsing quirks should be handled at the value level, not the parsing level. As such, I'd like to push the quirks back into your spec, and just normatively reference it from the appropriate specs as we revise them.
23:14
<TabAtkins>
zcorpan: What's the best way to send you suggested text?
23:14
<TabAtkins>
zcorpan: (Gonna define a <quirky-color> and <quirky-length> value, and then define how the set of quirky properties handle those types.)