| 00:15 | <heycam> | TabAtkins, thanks, fixed the broken links |
| 00:18 | <TabAtkins> | zcorpan: No, that example shouldn't be valid. That falls into the "we know declaratively that it'll stamp something out there" case. |
| 00:19 | <TabAtkins> | I think in those cases, the content model should just be strictly transparent? |
| 06:51 | <gsnedders> | http://slashdot.org/comments.pl?sid=3912831&threshold=-1&commentsort=0&mode=nested&pid=44127847 — dbaron's desk isn't a good response to that, is it? :P |
| 08:14 | <zcorpan> | hmm, the only case-sensitive css properties are variables, right? |
| 08:14 | <zcorpan> | and they are exposed in a separate interface, so i can pretend that all properties are insensitive |
| 08:18 | <SimonSapin> | zcorpan: yes |
| 08:18 | <zcorpan> | thanks |
| 08:19 | <SimonSapin> | if we add anything case-sensitive in the future, it will be because it’s author-defined and thus probably in a separate interface like variables |
| 08:20 | <zcorpan> | are properties normalized to lowercase somewhere? |
| 08:21 | Ms2ger | waves hands |
| 08:26 | MikeSmith | wonders if Ms2ger is waving his own hands, or somebody else's hands |
| 08:26 | <Ms2ger> | MikeSmith, yours |
| 08:27 | <MikeSmith> | damn that's where they went |
| 09:33 | <annevk> | FWIW, I started patching https://github.com/annevk/url again |
| 09:35 | <annevk> | I hope to get a bit further this time around and work on the test suite through my own JavaScript implementation of the specification. I realize that makes me the single point of failure for three pieces that really ought to be done by separate people, but nobody else seems to care about fixing URLs... Which is surprising in my mind, but I'm sure there's a reasonable explanation. |
| 09:36 | <annevk> | The other goal, as mentioned already, is to make parsing idempotent. That we lost that property is bad and we should claim it back. |
| 11:35 | <matjas> | annevk++ |
| 11:51 | <SimonSapin> | zcorpan: implementations probably normalize to lower-case at some point, but not sure what you mean |
| 11:51 | <zcorpan> | SimonSapin: i mean in the specs, if i can assume that they are lowercase for the purpose of CSSOM |
| 11:52 | <SimonSapin> | I seem to recall "If there is a property that is a ASCII case-insensitive match for the parameter, …" text in CSSOM |
| 11:54 | <zcorpan> | yeah, i've just changed it to fold to lowercase and do a case-sensitive compare. i added "A supported CSS property must be in its lowercase form for the purpose of comparisons this specification." |
| 11:55 | <zcorpan> | seems like a saner model to store them in lowercase |
| 11:56 | <Ms2ger> | Or as an enum |
| 11:56 | <SimonSapin> | implementation can do string interning or something, the spec shouldn’t have to be aware of that |
| 11:57 | <zcorpan> | sure, i mean model for the spec |
| 11:58 | <zcorpan> | either the spec preserves case in its "declarations" and does case-insensitive compares last minute, or it folds stuff to lowercase at the start and does case-sensitive comparisons |
| 11:58 | <zcorpan> | i prefer the latter |
| 11:58 | <SimonSapin> | you still need to fold parameters to the various methods |
| 11:58 | <zcorpan> | yep |
| 14:06 | <SimonSapin> | what does the html5lib serializer do with attribute order? |
| 14:07 | <SimonSapin> | I’m getting a huge diff in the generated version of css-syntax because I get a different attribute order than TabAtkins |
| 14:24 | <zcorpan> | i think that might have changed relatively recently in html5lib |
| 14:25 | <zcorpan> | so make sure you have the same version, i guess |
| 14:25 | <SimonSapin> | I hope it’s deterministic, within a html5lib version |
| 14:26 | <zcorpan> | probably is |
| 14:26 | <zcorpan> | though i haven't looked at the code, but i've never noticed them changing for me :-) |
| 14:26 | <SimonSapin> | TabAtkins: are you using 1.0b2 for what’s is the CSSWG repo? |
| 14:48 | <GPHemsley> | SimonSapin: Attribute order in html5lib is a recent issue that we had with anolis. Basically, if the tree builder doesn't maintain attribute order, it's non-deterministic. (gsnedders could probably explain more.) |
| 14:50 | <SimonSapin> | GPHemsley: Tab’s processor is using lxml I think |
| 14:50 | <SimonSapin> | couldn’t we sort on output? |
| 14:59 | <dglazkov> | good morning, Whatwg! |
| 15:02 | <gsnedders> | SimonSapin: It's whatever order the tree API stores it in, basically. Which in lxml's case is explicitly undefined. |
| 15:02 | <gsnedders> | SimonSapin: So there's no guarantee of stability. |
| 15:03 | <SimonSapin> | that sucks |
| 15:03 | <gsnedders> | SimonSapin: There's a alphabetical_attributes=True|False option on the serializer which will reorder all attributes into alphabetical order |
| 15:03 | <SimonSapin> | ah, I guess that’s what I want |
| 15:03 | <SimonSapin> | what does anolis do? |
| 15:04 | <gsnedders> | SimonSapin: We can't blindingly reorder it, otherwise people who want things to roundtrip without changing order, using a tree API that preserves order, are screwed over by us reordering it. |
| 15:04 | <SimonSapin> | yeah, I understand why it’s not the default |
| 15:04 | <gsnedders> | Blame fantasai for screaming at me to change it for years. :P |
| 15:05 | <gsnedders> | But yeah, we're now as deterministic as the underlying storage. Which makes sense, really. |
| 15:08 | <SimonSapin> | so what tree builders preserve the order? |
| 15:08 | <gsnedders> | lxml does currently, although it's explicitly defined as being undefined. |
| 15:09 | <SimonSapin> | ew |
| 15:09 | <gsnedders> | Blame fantasai. |
| 15:09 | <gsnedders> | Her fault. |
| 15:09 | <SimonSapin> | for lxml? |
| 15:09 | <gsnedders> | No, for wanting the behaviour in html5lib despite the underlying behaviour being undefined |
| 15:10 | <SimonSapin> | the alternative being always sorting? |
| 15:10 | <gsnedders> | Ja. |
| 15:10 | <SimonSapin> | ok |
| 15:10 | <gsnedders> | This is what we previously did |
| 15:10 | <SimonSapin> | if the option to sort is still there, that’s fine |
| 15:10 | <SimonSapin> | I’m ranting at lxml |
| 15:11 | <gsnedders> | I think the problem for Stefan is that libxml2 has it as undefined, so he can't guarantee anything that doesn't. |
| 15:11 | <SimonSapin> | so I’m ranting at libxml2 |
| 15:11 | <gsnedders> | Eventually we'll find out where you're really ranting :P |
| 15:12 | <SimonSapin> | hehe |
| 15:13 | Ms2ger | wants a useful tree api in python at some point |
| 15:14 | <SimonSapin> | Ms2ger: define useful |
| 15:15 | <Ms2ger> | One that preserves order for attributes and doesn't do .tail, say |
| 15:15 | <SimonSapin> | I’m considering making a new tree api for cssselect (or its successor) |
| 15:15 | <SimonSapin> | so text nodes instead? |
| 15:15 | <Ms2ger> | Yeah |
| 15:15 | <SimonSapin> | why? |
| 15:16 | <Ms2ger> | Say you have <a>x<b>y</b>z</a> |
| 15:16 | <Ms2ger> | How do you remove the b element? |
| 15:16 | <SimonSapin> | you have to append b.tail to a.text, which is annoying |
| 15:17 | <Ms2ger> | Right |
| 15:17 | <Ms2ger> | And how do you do it if a.text is None? |
| 15:17 | <SimonSapin> | more annoyance |
| 15:18 | <SimonSapin> | although (a.text or '') is not so bad |
| 16:40 | <TabAtkins> | SimonSapin: No, I'm using 0.95, because that's what version it was on when I last pulled. |
| 16:41 | <TabAtkins> | SimonSapin: I'm fine with doing alphabetical_attributes if that's supported on my version, too. |
| 16:43 | <TabAtkins> | SimonSapin: Also, I'd appreciate a new tree API that doesn't require me to fuck around with .tail. |
| 16:43 | <TabAtkins> | I understand the reasons for lxml's design, but that doesn't make it any less annoying for editing HTML. |
| 16:49 | <SimonSapin> | TabAtkins: do you want to stay on 0.95? lxml’s undefined-but-happens-to-preserve-order with html5lib 1.0 is probably good enough |
| 16:50 | <TabAtkins> | SimonSapin: Assuming that alphabetic_attributes works in .95, I don't see why we shouldn't just impose a deterministic ordering on attributes. |
| 16:50 | <SimonSapin> | I only care about getting the same output on different systems with the same input |
| 16:51 | <TabAtkins> | Right. |
| 16:51 | <SimonSapin> | why stay with 0.95, though ? |
| 16:51 | <TabAtkins> | Because that means I don't have to try and figure out why pip upgrade was failing? |
| 16:52 | <SimonSapin> | oh :p |
| 16:59 | <SimonSapin> | TabAtkins: just use sudo it’ll be fine ;) |
| 17:00 | <TabAtkins> | ...yeah, that was probably my issue. |
| 17:00 | <SimonSapin> | actually |
| 17:00 | <SimonSapin> | sudo pip uninstall stuff |
| 17:00 | <SimonSapin> | then pip install --user |
| 17:00 | <SimonSapin> | should be saner |
| 17:01 | <TabAtkins> | Cool, done. |
| 17:01 | <TabAtkins> | Where did this get dropped into? |
| 17:02 | <SimonSapin> | ~/.local |
| 17:04 | <SimonSapin> | TabAtkins: ok. Pull css-syntax, regenerate and see if the output changes |
| 17:05 | <TabAtkins> | It did, yes. |
| 17:05 | <SimonSapin> | :/ |
| 17:06 | <TabAtkins> | All attribute order churn, yeah. |
| 17:06 | <SimonSapin> | on 1.0b2 ? |
| 17:06 | <TabAtkins> | So, I'm not seeing an alphabetical option in htmlserializer |
| 17:06 | <TabAtkins> | Yeah. |
| 18:01 | <TabAtkins> | SimonSapin: Do you see an alphabetic attribute option in html5lib? Or is it supposed to be in lxml or something? |
| 18:56 | <Hixie_> | ok all that remains is element definition prose, and examples |
| 19:19 | <annevk> | Hixie_: I guess you noticed already it'll be commit 8000? |
| 19:27 | <Hixie_> | annevk: indeed |
| 19:27 | <Hixie_> | annevk: that's one reason i'm doing it as a big checkin :-) |
| 19:27 | <Hixie_> | (lamest reason ever) |
| 19:27 | <Hixie_> | (also, not the main reason) |
| 19:28 | <Hixie_> | (but it did stop me from making a typo fix separately first) |
| 19:34 | <tantek> | Hixie, that is pretty lame. You're not a numerologist. |
| 19:34 | <tantek> | besides, base 10? I mean c'mon. ;) |
| 19:39 | <TabAtkins> | tantek: Back-compat forces us to use base 10. |
| 20:15 | <JimJibber> | Anyone know why The dizzie rascal set on the stage version is blanked, but the same set is on the BBC 3 stream? |
| 20:56 | <Hixie_> | TabAtkins: oh i have no superstitions, it's just to make it easier to remember which checkin was 8000 :-) |
| 21:41 | <Hixie_> | hey does cloneNode() default to true or not? |
| 21:41 | <Hixie_> | spec says true, chrome seems to say false? |
| 21:47 | <Hixie_> | http://www.whatwg.org/specs/web-apps/current-work/#the-template-element |
| 22:18 | <gsnedders> | TabAtkins: html5lib 1.0b2 has a alphabetical_attribute option on html5lib.serialize and html5lib.serializer.HTMLSerializer |
| 22:45 | <Hixie_> | rafaelw: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 http://html5.org/tools/web-apps-tracker?from=7999&to=8000 |
| 22:46 | <rafaelw> | Excellent. On my todo list to review. |
| 22:46 | <rafaelw> | Thanks |
| 22:47 | <Hixie_> | cool |
| 22:55 | <TabAtkins> | gsnedders: Ah, I'm looking at the google code repo, and it's not showing it. I presume your repo is elsewhere now. |
| 22:57 | <gsnedders> | TabAtkins: As Google Code says on the home page, in massive letters, we have moved. |
| 22:58 | <TabAtkins> | If I were to click to the homepage, rather than reading the page I landed at which showed the exact class I was interested in, I'd have seen that. ^_^ |
| 23:02 | <gsnedders> | I should totally get around to booking hotel in SF. But that means decided when I'm going there (from San Jose). Decisions, man, decisions! |
| 23:03 | <gsnedders> | I guess it probably depends on who wants to meet up down around there. |
| 23:03 | <Hixie_> | so the next thing to fix is the parser's assumption in the html section that we're not in a foreign section (or that if we are, that the tokens it's generating are going to match html nodes, not foreign ones) |
| 23:07 | <TabAtkins> | gsnedders: Anyway, thanks for adding the option. Using it now. |