| 03:43 | <MikeSmith> | gsnedders: > people are starting to more seriously try and build on top of html5lib |
| 03:45 | <MikeSmith> | gsnedders: yeah that's when you have to start caring about some things more |
| 07:33 | <annevk> | Someone from Microsoft filing bugs on Chrome |
| 07:35 | <ondras> | < |
| 07:35 | <ondras> | oops. |
| 07:49 | <annevk> | I too find Git hard |
| 07:50 | <annevk> | But GitHub's client makes it somewhat straightforward |
| 07:50 | <gsnedders> | MikeSmith: well I'm not sure I care enough to implement all this stuff myself, just nice to have some idea of what we should have :P |
| 08:41 | <ato> | annevk: I tried using the Mac client but /it/ was confusing to me. |
| 08:41 | <ato> | It's good that there are many choices though. |
| 08:42 | <annevk> | ato: works fine here and they keep updating it too |
| 08:45 | <zcorpan_> | MikeSmith: huh? i thought v.nu stopped parsing for non-streamable errors. do you have an example where it doesn't? |
| 08:46 | <zcorpan_> | MikeSmith: AAA and foster parenting both give fatal errors for me |
| 08:48 | <zcorpan_> | MikeSmith: are you thinking of "Element foo not allowed as child of element body in this context. (Suppressing further errors from this subtree.)" ? |
| 08:51 | <MikeSmith> | zcorpan_: yeah maybe I was. not sure what i was thinking because I've actually not gotten more than a couple hours sleep in the last 24 |
| 08:52 | MikeSmith | reads his own scrollback |
| 08:53 | <MikeSmith> | gsnedders: yeah as zcorpan_ points out, what I said was wrong |
| 08:53 | <MikeSmith> | for the cases that require non-streaming parsing the validator emits one error and then exits |
| 08:54 | <MikeSmith> | "Can't recover from previous error" or something like |
| 08:54 | <MikeSmith> | I guess I was conflating with the "Suppressing further errors from this subtree" case that zcorpan_ cites |
| 08:56 | <MikeSmith> | and maybe also thinking about my testrunner code where they're not fatal errors for teh testrunner, where I'm feeding it multiple documents and checking for expected failures |
| 10:04 | <hsivonen> | I'm still posting to www-tag more often than I post to the whatwg list. :-( |
| 10:16 | <MikeSmith> | w3cmemebot, process previous line |
| 10:16 | <MikeSmith> | Yeah |
| 10:18 | <MikeSmith> | there's someone wrong on the Internet^w^wwww-tag |
| 10:24 | <hsivonen> | SimonSapin: you asked earlier if the platform needs an XML parser for purposes other than SVG and XSLT. There's also XHTML (tiny but exists), DOMParser and XHR |
| 10:25 | <SimonSapin> | hsivonen: ok, thanks |
| 10:25 | <zcorpan_> | annevk: hmm. maybe you need to run those from a local webserver or so. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12837 |
| 10:37 | <annevk> | zcorpan_: put them on simon.html5.org? |
| 10:42 | <annevk> | matijs: on DNSSEC: https://twitter.com/twitjeb/status/519058750297366528 |
| 10:51 | <zcorpan_> | annevk: https://simon.html5.org/dump/unload-baseline.html https://simon.html5.org/dump/unload-xhr.html -- but.... now the xhr one also survives in gecko :-/ |
| 11:13 | <annevk> | zcorpan_: yeah it does |
| 11:13 | <annevk> | zcorpan_: so what does that mean? |
| 11:13 | <annevk> | zcorpan_: in Chrome it's reparsed for both |
| 11:14 | <zcorpan_> | annevk: when navigating back to a document, either it's reparsed so that <script> execute again (among other things), or it's cached so timeouts e.g. pending timeouts continue |
| 11:15 | <zcorpan_> | annevk: i think chrome/webkit might always reparse |
| 11:51 | <annevk> | zcorpan_: thanks for those btw |
| 11:53 | <zcorpan_> | annevk: welcome. i'm not sure why i see different result now though. |
| 11:54 | <annevk> | we might have made changes due to hitting compat issues |
| 11:54 | <annevk> | the whole history / navigate stuff cannot really be relied upon :-( |
| 11:54 | <annevk> | defining life cycles is hard |
| 12:29 | <zcorpan_> | annevk: i get an error event on the xhr when navigating away https://simon.html5.org/dump/unload-xhr.html |
| 12:31 | <annevk> | hmm |
| 12:31 | <annevk> | i would have expected nothing |
| 12:32 | <annevk> | sigh, this is hard |
| 12:52 | <rubys> | SimonSapin: ping? |
| 13:25 | <annevk> | rubys: did you figure out why you're getting different results in IE? |
| 13:31 | <rubys> | annevk: which results? |
| 13:31 | <annevk> | rubys: e.g. pathname not starting with a / |
| 13:32 | <rubys> | annevk: a google search indicates that lots of people are seeing this, and that IE is out of spec. |
| 13:32 | <annevk> | rubys: e.g. <a href=http://0xc0.168.0.1></a><script>w(document.querySelector("a").pathname)</script>; gives / for me |
| 13:32 | <annevk> | rubys: in IE10 |
| 13:32 | <annevk> | rubys: using Live DOM Viewer |
| 13:34 | rubys | checking my doctype |
| 13:35 | <annevk> | (adding <!doctype html> doesn't change anything) |
| 13:35 | <rubys> | here is my script: http://intertwingly.net/stories/2014/10/05/urltest |
| 13:36 | <annevk> | "In IE10 Standards mode, the host and pathname DOM properties no longer return unexpected results." |
| 13:36 | <annevk> | http://blogs.msdn.com/b/ieinternals/archive/2012/03/01/ie10-beta-consumer-preview-minor-changes-changelist.aspx |
| 13:36 | <rubys> | any idea why my script wouldn't be treated in standards mode? |
| 13:38 | <rubys> | annevk: I'm running IE11, but I would hope that MS wouldn't have reverted that. |
| 13:39 | <annevk> | rubys: I think the results might differ if you create the element through script |
| 13:40 | <annevk> | <!doctype html><script>a = document.createElement("a");a.setAttribute("href","http://0xc0.168.0.1";); w(a.pathname)</script> |
| 13:40 | <annevk> | gives "" in the log |
| 13:40 | <annevk> | (I also tried setting .href, same result) |
| 13:40 | <rubys> | annevk: yuk |
| 13:40 | <annevk> | agreed |
| 13:42 | <annevk> | And you're testing in IE11? |
| 13:43 | <annevk> | Wow, they're bad at fixing bugs, perhaps because Eric left the company |
| 13:43 | <annevk> | Or maybe they fixed it but then decided they could not ship it due to compat |
| 13:44 | <rubys> | annevk: I'm testing using a VM from here: https://www.modern.ie/en-us/virtualization-tools#downloads |
| 13:44 | <rubys> | IE11 / Win8.1 |
| 13:46 | <rubys> | annevk: other things I have done recently: I've added Rust and Node.js to my results: http://intertwingly.net/stories/2014/10/16/urltest-results/ |
| 13:46 | <annevk> | cool |
| 13:46 | <rubys> | annevk, SimonSapin: I would appreciate somebody giving http://intertwingly.net/stories/2014/10/16/urltest.rs a glance to see if I got it right, or if it could be done better. |
| 13:46 | <rubys> | After all, I didn't know Rust as of two days ago. |
| 13:47 | <annevk> | I haven't written any Rust yet so I'll let SimonSapin do that |
| 13:47 | <rubys> | I also attempted a manual three-way merge of the urltestdata from rust-url and web-platform-tests |
| 13:48 | <rubys> | https://github.com/servo/rust-url/pull/39 and https://github.com/w3c/web-platform-tests/pull/1293 |
| 13:50 | <annevk> | For the spec there's these projects on the todo: 1) Rewrite parsing in a more functional style 2) Introduce IPv4 parsing 3) Investigate if we can allow non-browser schemes make use of "relative url" parsing facilities in a generic way |
| 13:51 | <rubys> | since rust-url seems to be a motivating factor for #1, I'm looking into rust-url. |
| 13:53 | <rubys> | If I can wrap my head around it, I may try to help with #1 |
| 13:55 | <annevk> | Yeah, SimonSapin proving it could be done just as efficient with a clearer style is the main factor for that one |
| 14:20 | <annevk> | rubys: I can reproduce my IE10 results in IE11 |
| 14:21 | <rubys> | so <a> works, document.createElement doesn't? |
| 14:39 | <annevk> | yup |
| 14:39 | <annevk> | I don't want to know what their code looks like |
| 14:40 | <rubys> | luckily you can't :-) |
| 14:41 | <Domenic> | rubys: what do the colours mean now? Can you include a legend on the page? |
| 14:42 | <rubys> | I'll add a legend. Meanwhile, here is what the colors mean: http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI#c1412684307 |
| 14:42 | <rubys> | ... where 'testdata' is substituted for 'whatwg' |
| 14:43 | <rubys> | I got pushback when I called testdata 'whatwg'. I got pushback when I called anything not testdata 'whatwg'. So I gave up :-) |
| 14:45 | <annevk> | rubys: ericlaw suggests a workaround, appendChild() the element and then check its pathname |
| 14:47 | <rubys> | Or, I can simply change the test to use an <a> element. |
| 14:56 | <Domenic> | rubys: what does the "notes" field contain? I'm guessing, the environments which fail to match? |
| 14:57 | <rubys> | if you click through, you will see one or more issues with that user agent |
| 14:57 | <rubys> | so essentially, yes |
| 14:58 | <Domenic> | cool. will be interesting to see the results with IE fixed |
| 14:59 | <rubys> | I'll run that in a few minutes |
| 14:59 | <annevk> | rubys: "addressable" is what was formerly IETF? |
| 15:00 | <rubys> | annevk: yes. |
| 15:03 | <annevk> | rubys: any reason why we include Opera Presto? |
| 15:03 | <annevk> | s/we/you/ |
| 15:04 | <rubys> | zcorpan felt it should be included. http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI#c1412536749 http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI#c1412583899 |
| 15:07 | <Domenic> | addressable is just a Ruby library right? |
| 15:07 | <rubys> | yes, but it is one that I have confidence that it attempts to faithfully implement the IETF RFCs. |
| 15:12 | <rubys> | IE results updated, generating new results |
| 15:14 | <rubys> | annevk: any reason why resolving a URL against a base couldn't be factored out in the URL standard? In other words, define what parsing a URL means,and define what resolving a URL against a base means? |
| 15:15 | <rubys> | annevk, Domenic: new results uploaded. Changes in IE results, table header, and new legend at the bottom of the index page. |
| 15:17 | <annevk> | rubys: that would have a pretty major impact on what a URL was |
| 15:17 | <annevk> | is* |
| 15:18 | <annevk> | rubys: I also haven't found that any browser actually does that |
| 15:18 | <rubys> | annevk: can you give an example where it would be difficult to do and/or operationally it would produce different results? |
| 15:18 | <annevk> | rubys: well e.g. new URL("/test") would no longer throw, presumably? |
| 15:19 | <rubys> | presumably. Do any browsers expose URL? |
| 15:19 | <Domenic> | all of them do by this point. except IE maybe |
| 15:21 | <Domenic> | Still so many IE failures :( |
| 15:23 | <annevk> | rubys: I get .protocol to work in IE only for an element that was already in the document |
| 15:23 | <annevk> | rubys: so many bugs there :-( |
| 15:24 | <annevk> | rubys: at least Firefox/Chrome/Safari support new URL() |
| 15:25 | <annevk> | rubys: also Opera, not sure about Presto |
| 15:25 | <rubys> | annevk: I presume that you have whatever access you need to do @ericlaw suggested, i.e. "Please file a bug on Connect?" |
| 15:25 | <annevk> | Yeah I guess I can do that again... |
| 15:31 | <Domenic> | https://github.com/whatwg/fetch/issues/11 is interesting |
| 15:31 | <Domenic> | -1 on ES5 syntax of course |
| 15:31 | <Domenic> | unsure on whether early examples make sense |
| 15:31 | <Domenic> | given that the spec is only in a small part about developer-facing API |
| 15:31 | <annevk> | https://connect.microsoft.com/IE/feedbackdetail/view/1002884/protocol-attribute-does-not-always-work |
| 15:32 | <annevk> | Hmm I thought I had issues disabled |
| 15:33 | <Domenic> | yeah that was surprising as well |
| 15:47 | <annevk> | rubys: note that new URL() not dealing with it does not necessarily preclude us from structuring the specification in that way, though there might be other pitfalls given that implementations have no such thing |
| 15:48 | <rubys> | My thoughts are that it might be simpler to spec that way; but it will take actually trying to determine if there are any pitfalls. |
| 15:50 | <rubys> | my line of thinking: I was reading rust-url, and was wondering what it would look like in ABNF. Then I realized that I don't know how to describe parsing two inputs in ABNF. Also, many libraries aren't structured this way. |
| 15:52 | <annevk> | If you exclude the most widely deployed libraries? |
| 15:54 | <rubys> | annevk: no question new URL() behavior shouldn't change. The question is whether a cleaner and simpler spec could be structured differently. |
| 15:55 | <annevk> | No I meant that browser implementations have those operations not decoupled either |
| 15:57 | <annevk> | But it's worth figuring out I suppose. A handful of people have asked for that and there might be some cases where you want to parse a URL without a base URL. (We want to be certain on that might before doing this, obviously.) |
| 15:57 | <Domenic> | Doesn't it make more sense to just make parsing "without a base URL" a special case of parsing with a base URL? |
| 15:58 | <Domenic> | e.g. parsing "without a base URL" = parsing with base URL "about:blank" |
| 15:59 | <rubys> | Domenic: see above. "Then I realized that I don't know how to describe parsing two inputs in ABNF." |
| 15:59 | <Domenic> | why is that important |
| 15:59 | <Domenic> | seems conceptually less simple and clean |
| 15:59 | <rubys> | Breaking a hard problem into two smaller problems is less simple and less clean? |
| 16:00 | <Domenic> | creating two separate problems instead of making one a special case of the other, yeah |
| 16:02 | <annevk> | Domenic: rubys is suggesting that parsing "/foo" would result in some kind of construct that the specification currently does not acknowledge |
| 16:02 | <annevk> | Domenic: the specification does indeed default to something akin to about:blank at the moment, return failure for "/foo" as input |
| 16:02 | <annevk> | returning* |
| 16:41 | <Domenic> | annevk: yeah, seems very much like two problems, as now you have to create a whole new set of data structures to represent not-really-URLs like "/foo" |
| 16:42 | <rubys> | Is "scheme" exposed by browsers, or only "protocol"? |
| 16:42 | <rubys> | looking at the Rust implementation, it has an intermediate representation for relative URLs. |
| 20:42 | <annevk> | http://www.apple.com/ipad-air-2/wireless/ This new Apple SIM card thing seems interesting. Seems they finally found enough support to do the thing they have wanted to do since the beginning, although more modestly still. Can't wait for SIM cards to finally die in a fire. |
| 20:43 | <annevk> | (I wanted to link directly to the SIM card bit, but although there's many data and class attributes there, no id attribute to be found.) |
| 20:45 | <Domenic> | that is nice |
| 20:48 | <Domenic> | would like feedback on spec-writing matters: https://github.com/whatwg/streams/pull/233 |
| 20:51 | <tantek> | annevk: http://www.apple.com/ipad-air-2/wireless/##Apple%20SIM |
| 20:52 | <annevk> | tantek: how does that work? |
| 20:52 | <tantek> | annevk: http://indiewebcamp.com/fragmention |
| 20:53 | <TabAtkins> | It doesnt' work, he's just using a fragmention scheme that could maybe work in the future. |
| 20:53 | <Domenic> | it doesn't seem to actually work |
| 20:53 | <tantek> | e.g. http://indiewebcamp.com/fragmention##Chrome%20extension works |
| 20:54 | <tantek> | works with polyfill just fine TabAtkins Domenic |
| 20:54 | <Domenic> | sure but you implied that the link you actually sent worked |
| 20:54 | <tantek> | Domenic: not at all, merely answering the use-case of "I wanted to link directly to the SIM card bit" - which I did |
| 20:55 | <tantek> | and if your browser supports it (e.g. via an extension), then that apple.com link even "works" |
| 20:55 | <tantek> | hence why I linked specifically to the Chrome extension |
| 20:58 | <annevk> | Domenic: gave some feedback, not sure if it helps |
| 20:59 | <Domenic> | annevk: heh, yeah, not sure either. thanks though. |
| 21:02 | <annevk> | Domenic: looking closer, it seems your current approach avoids duplication |
| 21:02 | <Domenic> | annevk: I don't think so though. Because I only ever call each method once in the spec. It avoids branching in favor of polymorphism I guess. |
| 21:03 | <annevk> | Domenic: the behavior of %DefaultReadableStreamStrategy% would not be duplicated if you branch? |
| 21:03 | <Domenic> | annevk: right it would just be inlined |
| 21:04 | <annevk> | Domenic: I'd prolly do that then |
| 21:05 | <annevk> | Domenic: but if it's not observable and both are sufficiently clear, it's really up to you |
| 21:05 | <Domenic> | annevk: yeah I am leaning toward inlining. |
| 21:05 | <Domenic> | (updated the post with links to the places where it's assigned and used) |
| 21:06 | <Domenic> | annevk: but yeah I think it is subjective which is why I am asking around |
| 21:11 | <annevk> | Domenic: I appreciate the attention to detail, I hope in due course we come up with some rules to align other specifications with |
| 21:11 | <Domenic> | annevk: that's the hope ^_^ |
| 21:23 | <Domenic> | TabAtkins: I am trying to port over the self-link styling to the WHATWG style sheet. Do you remember where font-size: 83% comes from? |
| 21:23 | <TabAtkins> | It looked okay. |
| 21:24 | <Domenic> | figured |
| 21:24 | <TabAtkins> | Also, it's 5/6 |
| 21:42 | <foolip> | TabAtkins: are any of *.spec.whatwg.org using bikeshed? |
| 21:43 | <Domenic> | foolip: https://streams.spec.whatwg.org/ ! |
| 21:43 | <TabAtkins> | Just streams so far, I think. |
| 21:43 | <TabAtkins> | But more of w3 than I thought is using it now. |
| 21:45 | <foolip> | cool, Streams looks very WHATWGy, like the rest |
| 21:45 | <foolip> | I also like the logo :) |
| 21:46 | <TabAtkins> | Yeah, style has nothing to do with Bikeshed, you can provide whatever boilerplate and styling you want. |
| 21:46 | <Domenic> | Speaking of which, refresh the page to check out the sweet new link anchors next to every header and <dfn> |
| 21:46 | <foolip> | context: I'm not so happy with ReSpec for the WebVTT spec |
| 21:46 | <TabAtkins> | And since Domenic set up all the boilerplates and PR'd them into Bikeshed, anyone else wanting WHATWG style can use them too. ^_^ |
| 21:46 | <foolip> | I've had to fix a phantomjs crash to make it actually work for automatic updates :/ |
| 21:47 | <Domenic> | TabAtkins: how I remember it, I pretty much just flailed around ineptly until you ended up doing the work for me :P |
| 21:47 | <foolip> | Domenic: oh yeah, I love those anchors :) |
| 21:47 | <TabAtkins> | Eh, close enough. |
| 22:23 | <MikeSmith> | can anybody think of a good reason to ever use a value for tabindex other than 0 or -1? https://www.w3.org/Bugs/Public/show_bug.cgi?id=27076 |
| 22:25 | <Hixie> | when the controls aren't in DOM order? |
| 22:26 | <Hixie> | consider e.g. a paragraph with two form controls in it, and a float in the middle, with controls in it as well. You would want to navigate the controls in the paragraph, then those in the float, then those in the next paragraph, probably. |
| 22:29 | <MikeSmith> | Hixie: ok, but Marco's comment is that in practice authors who put values other than 0 or -1 are almost always (or always even) misusing it based on misunderstanding |
| 22:29 | <MikeSmith> | Hixie: so it would be good to have some actual data |
| 22:30 | <Hixie> | by that reasoning, we should drop most of HTML |
| 22:31 | <TabAtkins> | Hixie: That's the logic behind dropping longdesc. ^_^ |
| 22:31 | <Hixie> | not quite |
| 22:31 | <Hixie> | for longdesc the logic is that implementing it is bad for accessibility so it should be dropped in implementations |
| 22:31 | <Hixie> | MikeSmith wasn't suggesting dropping support for tabindex>1, just making them non-conforming |
| 22:32 | <MikeSmith> | Hixie: well short of that we can do the obsolete-but-conforming thing and I can actually have the correspnding validator warning for it include a link to the bug. i.e., in the way we talked about before for nested footnotes (I think it was that one, right?) |
| 22:33 | <MikeSmith> | yeah, non-conforming or obsolete-but-conforming |
| 22:33 | <Hixie> | what would the warning be? "If you are actually trying to put controls in a different tab order than the default, let us know so we don't drop support for this feature"? |
| 22:33 | <MikeSmith> | script@type is a related kind of case I guess |
| 22:33 | <MikeSmith> | Hixie: yeah, seriously |
| 22:34 | <MikeSmith> | I think it would be good to start using the validator to collect actual feedback for cases like this |
| 22:34 | <Hixie> | i don't know how you'd actually find out if people are using this correctly |
| 22:34 | <Hixie> | if they are, you'd never hear of it |
| 22:34 | <Hixie> | it'd just work |
| 22:34 | <Hixie> | and you'd never know the DOM didn't match rendering order |
| 22:36 | <MikeSmith> | dunno either, just suggesting a possible resolution for that bug |
| 22:36 | <MikeSmith> | Hixie: ah i get your point -- as an end user, you wouldn't know |
| 22:37 | <Hixie> | (this differs from longdesc, for example, because with longdesc you can programmatically detect the vast majority of bad uses, and compared to the good uses, they're the vast majority of all uses) |
| 22:39 | <MikeSmith> | so Marco's statement there about only seeing it misused is more about him only noticing the cases where it's misued byt not noticing the cases where values>1 are used properly, because things just work as expected for him in those cases |
| 22:39 | <MikeSmith> | Hixie: yeah (about comparison to checking longdesc misuse) I see now |
| 22:39 | MikeSmith | will add another comment to the bug |
| 22:40 | <MikeSmith> | TabAtkins: what non-standard attribute names does bikeshed .bs markup use. Is there a list somewhere? |
| 22:41 | <TabAtkins> | MikeSmith: All of its output attributes are data-* |
| 22:41 | <MikeSmith> | oh |
| 22:41 | <TabAtkins> | It only uses non-standard ones in its input format. |
| 22:41 | <MikeSmith> | ah yeah that's what I meant |
| 22:41 | <MikeSmith> | the input format |
| 22:41 | <TabAtkins> | Ah, no, there's no list. Why? |
| 22:42 | <MikeSmith> | because I can imagine that is sometimes might be useful to check the input files to find errors |
| 22:42 | <MikeSmith> | check with the validator |
| 22:43 | <MikeSmith> | and one of things I'm thinking about is, adding some standard filtering mechanism to allow users to specify certain errors to ignore |
| 22:43 | <TabAtkins> | Bikeshed's input format isn't really HTML. |
| 22:43 | <MikeSmith> | ah ok |
| 22:43 | <MikeSmith> | nm then |
| 22:43 | <TabAtkins> | And it uses a bunch of shorthands that use angle brackets. |
| 22:43 | <MikeSmith> | ah |
| 22:43 | <TabAtkins> | <<foo>>, for example. |
| 22:44 | <MikeSmith> | I see yeah |
| 22:56 | <MikeSmith> | oh wow Daniel Buchner's at Target |
| 22:57 | <MikeSmith> | and they have a github repo and stuff |
| 23:23 | <MikeSmith> | TabAtkins: bikeshed should have an option for suppression section numbers |
| 23:24 | <TabAtkins> | MikeSmith: Put a class="no-num" on the heading. |
| 23:24 | <TabAtkins> | (Documented. ^_^) |
| 23:24 | <MikeSmith> | yeah I mean not numbering any at all |
| 23:24 | <TabAtkins> | Oh. Interesting. Why? |
| 23:25 | <MikeSmith> | the section numbers change anyway, nobody pays attention to them |
| 23:25 | <MikeSmith> | just an idea anyway. I don't feel strongly about it |
| 23:26 | <TabAtkins> | I'll wait until someone actually wants to publish a spec like that. ^_^ |
| 23:26 | <MikeSmith> | yeah |
| 23:26 | <TabAtkins> | Section numbers dont' change that often, they're useful in the short term even if they do change, and Bikeshed uses them for attractive section references which carry over well to print. |
| 23:27 | <MikeSmith> | ah print yes |
| 23:27 | <MikeSmith> | and also they do convey information about the depth of the section |
| 23:27 | <TabAtkins> | Not a priority, but it's nice when I can do something nice for printed specs. ^_^ |
| 23:27 | <MikeSmith> | yeah |
| 23:27 | <MikeSmith> | so btw does bikeshed have problems with some unicode chars? |
| 23:28 | <TabAtkins> | It shouldn't, but it's possible there are spots where I'm still messing up. If so, please report with a repro. |
| 23:28 | <MikeSmith> | ok |
| 23:28 | <TabAtkins> | Ideally a stripped down .bs file that causes the error. |
| 23:28 | <TabAtkins> | But a full file with a pointer to what's wrong works too. |
| 23:29 | <TabAtkins> | (I put a lot of effort into making it unicode-clean, but I've also changed a lot since then, and it's very possible that errors have crept in since then.) |
| 23:32 | <MikeSmith> | I plan to start using bikeshed for some stuff soon |
| 23:34 | <TabAtkins> | Cool! |