16:59:29 RRSAgent has joined #css 16:59:29 logging to http://www.w3.org/2017/02/01-css-irc 16:59:31 RRSAgent, make logs public 16:59:31 Zakim has joined #css 16:59:33 Zakim, this will be Style_CSS FP 16:59:33 ok, trackbot 16:59:34 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:59:34 Date: 01 February 2017 16:59:41 Present+ 17:00:04 Present+ 17:00:08 present+ dauwhe 17:00:17 tantek has joined #css 17:00:26 represent 17:00:29 ScribeNick: dael 17:00:29 er, i mean 17:00:32 present+ 17:00:34 present+ 17:00:37 present+ dael 17:00:39 resist+ 17:00:40 present+ rachelandrew 17:01:00 Tomorrow is Groundhog Day in the US. 17:01:07 present+ 17:01:31 present+ 17:02:08 present+ 17:02:10 :) 17:02:21 present+ 17:03:11 present+ 17:03:18 Rossen__: One more minute. 17:03:27 Rossen__: start time = 9:04PT 17:03:27 present+ Florian 17:04:04 fremy has joined #css 17:04:09 Rossen__: Let's get going. 17:04:24 Rossen__: As usual, are there any extra agenda items? 17:04:29 present+ 17:04:41 Rossen__: I'll take that as a no. 17:04:48 present+ 17:04:50 Topic: Consider visibility in 'speak: auto' 17:04:59 https://github.com/w3c/csswg-drafts/issues/511 17:05:11 zcorpan has joined #css 17:05:19 Rossen__: Before we jump in, yesterday we did have the inagural call for the a11y/CSS TF. 17:05:22 Hello 17:05:30 Rossen__: We had a number of attendees from CSS & APA. 17:05:52 Rossen__: WE did jump into one or two technical discussions that we're resolved, but we discussed speak and speak-as. 17:06:01 Rossen__: With that I wanted to see if fantasai made it 17:06:03 fantasai: I'm here 17:06:20 Rossen__: So let's jump into speak: auto 17:06:21 SteveZ has joined #css 17:06:23 Present+ 17:06:32 present+ 17:06:40 present+ ChrisL 17:06:49 antenna_ has joined #css 17:06:52 fantasai: THe issue was that some of the a11y folks during tpac asked us to consider visibility when keying the speak auto value because currently they account for display and visibility. 17:07:01 jcraig: https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0206.html 17:07:04 present+ 17:07:19 [pause for jcraig to join] 17:07:35 US Toll Number: +1-617-324-0000 17:07:35 Access code:641 037 413 17:07:35 Mobile Auto Dial:+1-617-324-0000,,,641037413# 17:07:41 present+ 17:08:03 Rossen__: While we wait for jcraig...um. 17:08:05 s/Access code:641 037 413// 17:08:12 Rossen__: Is there a reason to not just resolve? 17:08:14 present + 17:08:18 IanPouncey has joined #css 17:08:39 q+ 17:08:39 Rossen__: This is the same as the algo for name and description. It matches exactly. I'd be interested in if there are are any reasons to not do otherwise. 17:08:43 s/Mobile Auto Dial:+1-617-324-0000,,,641037413#// 17:08:53 Rossen__: WE can wait on jcraig before we resolve, but I'd be interested to hear from the rest. 17:08:57 tmichel has joined #css 17:09:30 present+ 17:09:42 Bert: Seems to me a bit confusing if visibility: hidden equates to speak: none. It's more like volume 0. It takes up space. THe audable translation takes no time 17:09:44 zcorpan, got it 17:09:47 ack me 17:10:34 fantasai: That's true in a strict sense, but people are doing layouts with layers so the space isn't precieved as taking up space. Having to go as volume 0 would jsut be a bunch of dead silence which is useless. Even ifn visual layout where you leave space you don't in the aurel (sp?) canvase 17:10:53 fantasai: I don't think it's useful normally. If you really want it you can set volume to 0 yourself. 17:11:04 /aurel/aural/ 17:11:05 +1 to fantasai's comment. we don't want dead air (radio term) 17:11:17 :) 17:11:18 Rossen__: I'm not 100% sure what it means to take audio to 0. Do you meant the entire volume of the current instance of this web content? 17:11:22 it would be the volume of the element set on, not globally 17:11:29 Rossen__: Plus this matches the name computation algo. 17:11:34 q? 17:12:23 jcraig: I agree with fantasai comment. We don't want dead air. I think I agree with Jessie and others that by default visibility and display should effect speech output. 17:12:35 Things work correctly in terms of descendants being able to override visibility:hidden with visibility:visible (but descendants being unable to override display:none), right? 17:12:38 s/should/shouldn't 17:12:45 Rossen__: Anyone else? 17:12:52 s/dead air (radio term)/dead air (radio term) or periods of unexplained silence/ 17:12:53 that would imply a sort of auto value, which depends on display and visibility 17:13:09 Rossen__: To dbaron question: this is in fact the behavior we support in edge 17:13:17 Rossen__: This is what's currentlys pecced by AAM spec. 17:13:22 IanPouncey has left #css 17:13:30 Rossen__: My expectation would be this prop matches that behavior as well. 17:13:36 dbaron, 'speak: always' is intended to override 'display: none' for speech output, and does per spec 17:13:43 present? 17:14:06 Rossen__: I see chatter on IRC. Is there a reason it's not on call? 17:14:13 [troubles with muting] 17:14:22 rossen raised it as a concern... it is definitely a desired feature to have something invisible to the visual rendering and rendered to speech 17:14:35 dbaron: As long as the auto value does the right thing for display and visbility for decendants that seems fine 17:14:38 present+ jcraig 17:14:45 rrsagent, make minutes 17:14:45 I have made the request to generate http://www.w3.org/2017/02/01-css-minutes.html jcraig 17:14:50 fantasai: That's a good point. I'll be careful when I edit in the spec to make sure that works correctly. 17:14:53 q? 17:15:00 Rossen__: Let's call for consensus 17:15:12 zakim, who is noisy? 17:15:12 I am sorry, jcraig; I don't have the necessary resources to track talkers right now 17:15:29 Rossen__: Prop: Speak: auto matches the AAM computation in how it takes visbility: hidden and display: none into consideration 17:15:32 Rossen__: Obj? 17:15:43 RESOLVED: speak: auto matches the AAM computation in how it takes visbility: hidden and display: none into consideration 17:15:54 Topic: [css-ui] New CR publishing request 17:15:56 https://lists.w3.org/Archives/Public/www-style/2017Jan/0074.html 17:15:59 q+ 17:16:02 agenda? 17:16:25 jcraig: the agenda is in the title 17:16:54 Florian: If anyone has reviewed I'm happy to hear about it. THere is a DoC and an updated change section. I think we're close to PR. I'm in the middle of completing the test suite. They'll be written by end of this week. Majority pass in 2 browsers. 17:17:01 tantek: I concur. It's in good shape. 17:17:01 +1 to publishing 17:17:16 ChrisL_: I looked at DoC. Looks complete. Changes looks good. It looks in order. 17:17:20 Rossen__: Obj? 17:17:23 +1 17:17:25 jcraig, ? 17:17:37 RESOLVED: New CR publication for CSS UI 17:17:43 Rossen__: ChrisL_ you'll help? 17:17:51 ChrisL_: Yes. First step is transiation request. 17:18:05 I will do the transition request 17:18:06 Topic: CSS Display items 17:18:18 rrsagent, here 17:18:18 See http://www.w3.org/2017/02/01-css-irc#T17-18-18 17:18:37 fantasai: I'll start with create a display property value for visually hiding an element while making it available for AT 17:18:43 https://github.com/w3c/csswg-drafts/issues/560 17:19:01 fantasai: There were several GH issues asking for something to have display: none in visual rendering but have content rendered to speech. 17:19:14 fantasai: I said it's the speak property, but no one impl it. It's been in CR for 4 years. 17:19:33 fantasai: Question there, which is the last comment on the link, is what do we want to do. 17:20:09 fantasai: 1) Do nothing and tell people to impl 2) split speech into 2 levels so speak is l1. 3) move speak property to display module so that it is easier to see and goes to CR with display 17:20:17 fantasai: What do you, the WG, think we should do? 17:20:20 (I kinda like option 3..._) 17:20:38 q+ 17:21:02 dbaron: I'm skeptical that speech module solves this. It seems to be a thing about a seperate aural rendering than AT. It's a seperate presentation not an assistive view of the presentation. 17:21:12 q+ Considering the speak property as a solution to hidden content is not a fully considered solution 17:21:15 dbaron: I'm inclinded toward something more related to display. 17:21:20 https://github.com/w3c/csswg-drafts/issues/560#issuecomment-270094051 17:21:26 dbaron: Maybe that's not other peoples understanding of speech, though. 17:21:28 q+ to say Considering the speak property as a solution to hidden content is not a fully considered solution 17:21:29 q- 17:21:35 it was for css ui 17:21:38 q+ 17:21:41 going to go out on a limb and note that the Speech module was never really incubated (or nothing passed the experimental emacs impl which was an earlier draft and does it even still work?). It's a perenial example of an aspirational spec that's been stuck in the CSSWG :( 17:21:44 q- 17:22:40 Rossen__: Speaking with my impl hat, I have to say we've made a number of decisions and have held display:none for a number of years and features. We've never had a reason to break the seal of a display:none subtree in the dom. This sounds like it will. 17:22:47 q+ to mention AT uses a lot of non-speech modalities... switch control, braille, etc not related to speech. 17:23:28 q+ 17:23:33 Rossen__: I'm sure impl have various optimization on how they computer those subtrees. I'm skeptical to see that this is something we should proceed with for impl and b/c this prop goes against much of what HTML AAM tries to define in terms of how name computation and text computation happens for purposes of AT text sentences. 17:23:43 q? 17:23:43 Rossen__: So I'm personally, as an impl, against that. 17:23:48 ack me 17:23:48 jcraig, you wanted to say Considering the speak property as a solution to hidden content is not a fully considered solution and to mention AT uses a lot of non-speech modalities... 17:23:51 ... switch control, braille, etc not related to speech. 17:24:50 jcraig: As an impl of UA and assistive tech, I think the speak property is insufficient here. A lot of people don't understand how AT works and the full explination is too long, but this is a secondary tree...similar to DOM but not 1:1. What we'd be asking the UA to do is expose these elements based ont he speak property. 17:25:36 jcraig: The switch interface user usus the same AT. Even a screen reader for those that are blind would want the same info. THis is something more along the lines of display or hidden properties. We've talked about doing this with an aria override 17:25:40 hidden aria-hidden="false" 17:26:02 s/screen reader/braille screen reader/ 17:26:08 jcraig: There's complexities there, but that would overrirde. That's as clean as possible, but only impl in webkit right now. 17:26:15 it is also implemented in Edge 17:26:20 we should just publish CSS Speech module as a Note and give up on the specifics in that module since there's been zero implementer interest for four years. 17:26:23 jcraig: having a CSS override you may want to consider, but I don't think speek is right. 17:26:49 jcraig: Also, most of CSS Speech is liniarized, not about something accesses by assistive technology users. 17:26:50 s/speek/speech 17:26:55 q? 17:27:03 s/speek/speak/g 17:27:21 ack fremy 17:27:27 fremy: I wanted to say I agree with the interp by dbaron that speech is for ebooks, not a11y. We should use aria prop for a11y. 17:27:31 I concur. 17:27:36 'aria-display: block' 17:27:40 fremy: I don't think we should do anything more in speech 17:28:11 Florian: To react to your earlier point, I was surprised b/c it sounded like that you weren't against moving the speak property, but was against how the speak prop worked. 17:28:13 yes that is what I heard also 17:28:20 jcraig: CSS Speech is clearly more targeted at linearized speech (e.g. audiobooks) than to navigated speech (e.g. screen readers) 17:28:29 Florian: Is that solved b/c you expect seperate UAs to impl that? Or did I miss something? 17:29:08 Florian: Is the fact that you seem to object to the feature resolved by that you expect the prop impl by UAs only doing linear? 17:29:15 bradk, please no aria-* props in CSS 17:29:36 jcraig, but how do we know it even does a good job at "linearized speech (e.g. audiobooks)" ? 17:29:46 I love interactive stuff and accessibility. But... we have ARIA for this. And it's more broadly supported. Why would I use this? Isn't this just one more thing for accessibility minded front end devs to remember to use? Overwhelming. 17:30:33 RachelNabors: It lets you control the show/hide of an element in CSS, and to do so differently for a11y than for visual 17:30:39 tantek, it was mostly written by the daisy org... ask the authors? I posted some comments during that time for AT, but they were rejected in favor of linearized audio. 17:30:41 Rossen__: I'll echo jcraig a bit. We did an aria impl in Edge a few months ago and the clean representation for a11y is what jcraig said. We build seperate trees that are added to what we have and those trees are based on style info among other things. Style trees themselevs are built on cascade. One of the strongholds in cascade is the display:none which obscured the entire subtree of that element. Now if we add additional burdon b/c a speak:normal could be... 17:30:53 Rossen__: in there there could be holes in the display:none. THat's a long stretch 17:31:08 Florian: Are you obj to this prop impl by desktop browsers or exist? 17:31:14 RachelNabors: We shouldn't be replacing ARIA in general, but this makes sense to me -- sometimes the visual presentation makes certain parts of the document redundant, and you want to hide them visually 17:31:35 s/RachelNabors:/RachelNabors,/ 17:31:45 jcraig, just thinking something-display that overrides display, for AT only. 17:32:07 Rossen__: I'm against how speak:normal is defined. Speak:none we could take in addition to things we do. We can add another thing to look at, but going to speak:normal that could be anywhere in any sub-tree incl display:none is something I think will be difficult to impl and go against the stronghold of display:none 17:32:08 q? 17:32:12 ack Florian 17:32:23 Florian: Okay, not that it seems like you obj to how speak:normal is already defined? 17:32:41 I've viewed the speech module as a thing that's not expected to have anything to do with browsers. 17:32:53 jcraig, does the daisy org have a representative in this WG? 17:32:53 Rossen__: Yes. Since this spec was before my time I haven't had the chance to give my opinion at the time. Also, this spec hasn't had update from impl and perhaps there's a reason. 17:33:09 Florian: fantasai asked about moving the property and I'm getting to you object to how it works, not moving it. 17:33:12 how long do we wait before we give up on CSS Speech and publish it as a Note? 17:33:17 Rossen__: Yes. 17:33:29 q? 17:33:43 q+ 17:33:53 Rossen__: So I see a bunch of talk on IRC. I want to bring the convo back tot he call. Lots of people are talking about this being a note and not a spec. If you folks want to discuss, please put yourself on the queue. 17:34:52 jcraig: To clarify the convo with tantek he asked how we know it's good for linear. THe authors were from the daisy coalition. I assume they know what they were doing for linear. I put comments about how it won't work for AT, but I believe they were not accepted. 17:35:00 perhaps with the IDPF merger we can encourage the Daisy org to join the CSS WG 17:35:03 jcraig: I posted some related comments in the css speak issue. 17:35:23 jcraig: I also object to the way it's impl currenlty, but not enough to object to the change of value name. THere's larger issues. 17:35:27 Rossen__: Let me try and summerie 17:35:50 Rossen__: It sounds like we're not done with speech module or speak properties. There's rising opinions about the behavior and tech decisions. 17:36:29 tm has joined #css 17:36:31 Rossen__: The original topic was if we should move speak or speak:auto to display module. GIven this chatter about the property, the display module is fairly far along CR track, it would be a pity to see the speak property holding this spec back. 17:36:40 agreed with that reasoning 17:36:45 antonp has joined #css 17:36:53 Rossen__: I would suggest to not move the speak property into display module. If we have it anywhere we can discuss seperately. 17:37:08 Rossen__: I would like to hear if there are obj to keeping speak property where it is now. 17:37:16 q+ 17:37:21 q- 17:37:28 present+ antonp 17:37:34 RESOLVED: Do not add speak property to display module 17:37:41 q- 17:37:46 https://github.com/w3c/csswg-drafts/issues/964 17:37:51 Rossen__: We have a second issue: rename flow-root 17:38:38 fantasai: There was a motion to rename flow-root value for display and the thread doesn't seem to have concluded on a better alternative. flow and flow-root are two values for inner display type, one of which creates a new formatting context and one doesn't. 17:39:02 fantasai: it's intended to indicate a corrispondnace. flow root indicates the new context. 17:39:33 fantasai: The word flow was choosen because you don't get a new formmating context, you participte in the old one. 17:40:01 fantasai: The other reason is there is a content type for elements in HTML that allows the mixture. It's called flow. That's the type of formatting this indicates. 17:40:19 fantasai: It's not just able block formatting context, but also inline level. 17:40:33 fantasai: Not having better suggestions I say leave as-is, but I'm open to other suggestions. 17:40:40 I think it is fine as is 17:40:41 Rossen__: This is a call for bikeshed. 17:40:49 Rossen__: Anyone have a different name to propose? 17:41:09 I'm fine with flow-root - was hoping for a better suggestion but haven't seen one 17:41:11 Rossen__: objections to leave flow-root as is 17:41:22 RESOLVED: leave flow-root name as-is 17:41:35 Rossen__: Taking display to CR. Are we ready to resolve? 17:41:47 fantasai: There are no open issues. All edits are made and pushed out. 17:42:00 how is the test suite? 17:42:05 fantasai: Only issue filed against the WD is this one on renaming. We have impl shipping. I think we should move forward. 17:42:11 no idea :( 17:42:14 Rossen__: Objections to publishing CR of CSS Display? 17:42:28 ChrisL_: Again, this is a transition request. 17:42:31 Rossen__: Correct. 17:42:37 ship it! 17:42:44 +1 17:42:48 RESOLVED: Transition request for CSS Display 17:42:55 https://github.com/w3c/csswg-drafts/issues/993 17:43:00 TOpic: ^ 17:43:06 rrsagent, here 17:43:06 See http://www.w3.org/2017/02/01-css-irc#T17-43-06 17:43:21 zcorpan: It's a new issue. 17:43:51 zcorpan: It's proposing to make these properties useful again. I changed them in 2015 to always return 24 to address the fingerprinting issue. 17:44:05 zcorpan: Some impl do have 24 hard coded. 17:44:07 antonp has joined #css 17:44:20 zcorpan: It's proposed to make them return other values b/c it's useful for deep color screens. 17:44:25 bert, remember to update https://github.com/w3c/csswg-drafts/blob/master/Transitions.md as the tansition proceeds 17:44:28 zcorpan: I wanted to check the thinking of the WG. 17:44:41 zcorpan: And we should make sure same features in MQ are aligned with the CSS OM 17:44:42 Bert, ChrisL, we have implementations of 'display: contents' and 'display: flow-root' I think that's it for things that aren't defined in other specs like CSS2.1 and Flexbox 17:44:49 q+ 17:44:53 q? 17:45:12 q+ to agree that actual bit depth should be returned, not hardcoded 24 17:45:12 Florian: Is this something we'd like to discuss with both or is it better with source-set and things like that? Which would limit fingerprinting a bit. 17:45:38 zcorpan: I don't think you can do it with a source set like thing b/c this is for spec colors in CSS or canvas. Not for images, really. 17:45:50 zcorpan: For images you can use deep color already 17:45:57 Rossen__: This is device specific correct? 17:45:58 q? 17:45:59 zcorpan: Right. 17:46:41 ack dbaron 17:46:45 dbaron: I think...I'm fine with this being useful as long as the spec is clear what the value means. Some impl were returning what the bit depth was semantically before the hard code and some were returning number of bits in the memory layout that the graphics card liked 17:46:48 bits per component vs bits per pixel. spec needs to be clear. 17:47:27 also for 5-6-5 red green blue = 16 17:47:33 dbaron: There are some context where when you have rgb data you back a bite of r, of g, of b. THere are some context where you want 32 bites aligned. Sometimes this differs per video driver. Some impl exposed this. 17:47:46 q+ 17:47:49 dbaron: Apperently some people wanted that, but most people didn't. 17:47:53 Florian: Why? 17:48:02 dbaron: I think they were messing with low-level canvas things. 17:48:12 dbaron: That was the only way they could get what they wanted at the time. 17:48:30 dbaron: I advocated this shouldn't expose differences beetween how video drivers do memorylayout. 17:48:36 dbaron: Spec should be clear one way or the other. 17:48:48 ack ChrisL_ 17:48:48 ChrisL_, you wanted to agree that actual bit depth should be returned, not hardcoded 24 17:48:57 ChrisL_: I completely agree with zcorpan this should return bit depth summed for number of components. 17:49:09 ChrisL_: If you have 5-6-5 it's easier to do the sumc 17:49:21 ChrisL_: I also agree this should return actual bit depth, not any other padding. 17:49:43 ChrisL_: I'm also happy to contribute or review text for this. I understand this well and I"m happy to work with the editors. 17:49:46 s/bites/bytes/ 17:49:50 ack smfr 17:50:06 smfr: I wanted to point out that bit or px depth isn't good to display if the display is wider than srgb 17:50:09 q+ 17:50:34 smfr: This nuumber would return 24 of the new mac displays. I don't think we want to encourage this. Color gamut MQ is better. 17:50:40 ChrisL_: Absolutely. 17:50:40 ack ChrisL_ 17:50:54 ChrisL_: There is some corrolation, but it's not necessarily true. 17:51:05 q+ 17:51:06 ChrisL_: people shouldn't make assumptions on that value 17:51:25 smfr: THere are also flaoting point px formats. You shouldn't assume this gives the integral number 17:51:44 ChrisL_: Right. I've only seen that in image editors. Could you send something explaining wha tyou mean on floating point px format 17:51:52 smfr: ON the mac you can create px buffers 17:51:56 ChrisL_: Okay. Yeah. 17:52:06 pull request from mounir: https://github.com/w3c/csswg-drafts/pull/994 17:52:12 so, that would be 48 bits? 17:52:20 thanks, will review PR 17:52:21 zcorpan: I also wanted to point out there's a pull request for the spec. Anyone that wants to review, please go ahead. 17:53:09 Rossen__: Where does this leave us on the issue. THere were some people in value of changing as long as they are true and useful. Als there was some feedback about how is it really going to be used and will people use it in place of color gamut MQ 17:53:31 Rossen__: Are we leaning toward not changing in favor of encouraging the color gamut or do we trya nd define as true as possible? 17:53:49 ChrisL_: I'd be in favor of defining correctly and giving ex in spec of how not to use it 17:54:01 q? 17:54:07 ack Florian 17:54:30 Florian: Given that this has potential for misuse, but I'm also wondering how reliable this will be because we don't want the number for the layout on graphics car...do we want hte bit dempth on the browser, the screen, the graphics card? 17:54:49 good point about dithered 6bit/component TN displays 17:55:05 Florian: Combining these things, I'd like tos ee specific use cases because if it might be impl wrong and has potential for misuse, I want to make sure we're doing it for a reason. 17:55:26 ChrisL_: You bring up a good point. We need to discuss what to give in [use case dael missed] 17:55:43 Florian: And what's the use case to let us decide and given that case what would the author want to see? 17:55:49 related issue for canvas: https://github.com/whatwg/html/issues/299 17:56:02 zcorpan: There has been discussion in HTML for adding both deep and wide colors for a canvas. 17:56:10 zcorpan: Some of your points are in that thread. 17:56:23 zcorpan: Whatever we come up with is already exposed there with info on wide colors. 17:56:59 Florian: The thread seems different between how to define and how to query. If you're painting through the canvas you won't make your page lighter by making a 12 bit and 8bit canvas. Or not? I'm confused on use cases. 17:57:21 zcorpan: If you use more bits than device can handle you use more memory. BUt sure. We should read this thread and think for a while. 17:57:36 Rossen__: Are you okay with deferring that resolution, zcorpan ? 17:57:38 zcorpan: Sure. 17:58:19 Rossen__: It would be great to summerize this or express that we had some points in favor as long as we have a good definition of the value. I peeked at the pull and I don't think that's near defining it. 17:58:38 Rossen__: Let's postpone. Please bring this back when the discussion matures and we'll call the resolution at that time. 17:58:52 Rossen__: That takes us to the end of our agenda. We're 1 minute from the end of the call. 17:59:07 Rossen__: I don't recall any topic ever taking 1 minute, so I'll end the call now. 17:59:29 smfr has left #css 17:59:58 you're welcome Bert - 1min is sometimes feels like a lifetime, so enjoy! 18:00:58 bert, you know how to edit https://github.com/w3c/csswg-drafts/blob/master/Transitions.md I guess? 18:02:04 I don't see an edit button, but I'm not sure I'm logged in either. 18:02:12 jamesn has joined #css 18:02:57 Ah, but I do see it in mercurial, so that's fine. 18:03:32 Hmm, except that it is not HTML :-( 18:03:39 there is an edit button, if you are logged in 18:03:42 Is there an HTML to MarkDown converter? 18:03:47 yes, it is markdown 18:04:26 it is a fairly simple format and we basically justneed buullet lists and links 18:04:56 I probably don't need more than paragraph and list item. I'll manage. 18:07:06 All these wiki sytaxes are simple... until you need something else than a para or a list. Luckily, they usually have an escape-into-HTML syntax. 18:36:05 Bert: the draft server does automatic markdown to html conversion via http://commonmark.org/ 18:36:40 though tath will change to gfm at some point soon: https://help.github.com/categories/writing-on-github/ 18:40:46 (and fwiw, most of the markdown for the headings appear to be broken: https://drafts.csswg.org/Transitions ) 18:44:49 (belated regrets) 19:07:57 Florian has joined #css 19:40:38 jensimmons has joined #css 19:53:45 jensimmons has joined #css 19:57:52 tm has joined #css 20:08:28 Florian has joined #css 20:23:18 Zakim has left #css 20:40:03 jcraig_ has joined #css 21:07:48 tantek has joined #css 21:09:26 Florian has joined #css 21:16:53 tantek has joined #css 21:29:21 https://github.com/w3c/csswg-drafts/issues/743 21:29:41 tantek: ^ 21:29:45 :) 21:37:57 jcraig has joined #css 21:49:29 jcraig has joined #css 22:01:04 jcraig has joined #css 22:07:42 tantek has joined #css 22:10:12 Florian has joined #css 22:28:53 tgraham has joined #css 23:02:55 ChrisL_ has joined #css 23:10:56 Florian has joined #css 23:11:08 myles has joined #css