| 06:29 | <galant> | any idea why iceweasel makes br elements when I insert new line feed and chgromium don't? but they both make new lines |
| 07:49 | <jgraham> | galant: Because content editable is a non-interoperable mess that for a long time didn't have any spec, now has a partial spec with no editor, and which it is almost impossible to bribe, bully or otherwise coerce browser devs to work on? |
| 07:53 | <crocket> | Is http://learn.shayhowe.com/html-css a good guide to HTML and CSS? |
| 08:23 | <annevk> | crocket: seems fine |
| 08:30 | <galant> | jgraham, fair enough :S |
| 08:30 | <galant> | omg I am sorry it is like that |
| 08:30 | <galant> | I see there is big big lag in html development |
| 08:30 | <galant> | any idea why is that? |
| 08:30 | <annevk> | lag? |
| 08:31 | <annevk> | The dire state of contenteditable="" doesn't directly translate to all of HTML, although I guess getting people to work on fixing bugs is much harder than getting them to work on adding new features. |
| 08:34 | <galant> | well lag in development |
| 08:34 | <galant> | I think people are working on other things |
| 08:34 | <galant> | I hope they will work on contenteditable |
| 08:38 | <annevk> | Don't know of any plans :/ |
| 08:42 | <MikeSmith> | anybody know of any vendor plans to implement any of the following from the W3C canvas 2dcontext spec? Path object, addHitRegion, draw*FocusRing, scrollPathIntoView |
| 08:42 | <darobin> | part of the problem with contenteditable is that browsers don't want to fix their bugs because they almost always introduce regressions |
| 08:42 | <darobin> | there's a case for starting from scratch on this one |
| 08:44 | <MikeSmith> | yeah contenteditable seems beyond fixable practically |
| 08:48 | <annevk> | You guys sound like the people that started XHTML 2.0 |
| 08:48 | <MikeSmith> | no, more like the guys that started the IRIbis WG |
| 08:50 | <annevk> | My plan btw is to import all of WebKit's tests into https://github.com/annevk/url and then see about integrating them with the testharness.js goodness |
| 08:50 | <annevk> | After I fixed bugs in the specification and my own implementation |
| 08:50 | <annevk> | Then file a bunch of bugs on browsers and see what people say |
| 08:50 | <MikeSmith> | what about Chris Weber's tests? |
| 08:51 | <annevk> | Already started a thread on dev-platform about cleaning up Mozilla's mess |
| 08:52 | <annevk> | MikeSmith: they're kinda of a mess. Some of them don't have passing criteria, a bunch of them are the WebKit tests. And it's all in one big massive file... |
| 08:53 | <MikeSmith> | ok |
| 08:53 | <annevk> | I was hoping he was going to do the legwork on making them work, but no activity in the past four months |
| 09:15 | <galant> | why the character 𐂫 is showing on linux but not in windows? on windows I get empty square and on linux I get the character |
| 09:19 | <SimonSapin> | galant: missing fonts? |
| 09:30 | <Ms2ger> | MikeSmith, I don't know of any interest in implementing those in Gecko |
| 09:31 | <MikeSmith> | Ms2ger: OK, thanks |
| 09:34 | <MikeSmith> | hmm so all of those are in the HTML spec too already |
| 09:34 | <MikeSmith> | whatwg |
| 09:34 | <Ms2ger> | Yeah |
| 09:35 | <Ms2ger> | They're Hixie's... v5? |
| 09:35 | <MikeSmith> | I'm also trying to remember if there are any accessibility-related canvas features that are in the W3C 2d spec but not in WHATWG HTML |
| 09:36 | <Ms2ger> | Dunno |
| 09:36 | <Ms2ger> | But then again, I haven't got a track record of caring about them |
| 09:37 | <galant> | SimonSapin, I need fonts for displaying Unicode character |
| 09:39 | <SimonSapin> | Each font only supports some set of character. Getting an square instead of a proper glyph typically means that this system has no available font that support this character |
| 09:41 | <SimonSapin> | galant: using a webfont can help |
| 09:53 | <gallant> | SimonSapin, but just curious I need fonts to display some unicode character |
| 09:55 | <jgraham> | Umm, you need fonts to display nay character |
| 09:55 | <jgraham> | *any |
| 09:56 | <jgraham> | Not all fonts have all characters |
| 09:56 | <jgraham> | Because there is more demand for, say, ascii than Linear B |
| 09:57 | <annevk> | Also 💩 |
| 10:05 | <gallant> | ok thanks |
| 10:14 | smaug____ | is always surprised to see someone linking to W3C HTML5 spec |
| 10:14 | <annevk> | Ow... Apparently the URL standard is wacked with relative file URLs. |
| 10:15 | <darobin_> | aren't we all |
| 10:33 | <annevk> | Relative file URLs :-( |
| 10:36 | <gallant> | so fonts are basically graphical glyphs for representing unicode characters |
| 10:38 | <gallant> | I have one big problem |
| 10:39 | <gallant> | two actually |
| 10:39 | <chee> | only two |
| 10:39 | <chee> | what a dream |
| 10:39 | <gallant> | hehe |
| 10:40 | <gallant> | first smalelr problem when I insert backspace character with javascript on my html web page in contenteditable element previous character before caret position for writing is not deleted |
| 10:40 | <gallant> | any idea why this is happening? |
| 10:41 | <gallant> | instead of deleting previous character, the caret/cursor position for writing goes in the start of the line |
| 10:43 | <annevk> | https://github.com/inikulin/parse5 "Fast full-featured HTML parser for Node" |
| 10:45 | <sangwhan_> | Coming soon: a full-featured browser for Node |
| 10:50 | <Ms2ger> | Opera for Compute^WNode? |
| 10:51 | <jgraham> | heh |
| 10:51 | <Ms2ger> | Surely Opera will have done it first |
| 10:55 | <jgraham> | http://code.google.com/p/es-operating-system/ <- I think this guy did, sort of. Dunno if Node is involved really though |
| 10:55 | <gallant> | second big problem is when I insert line feed character in linux in chromium I get new line but cursor is in previous line, then after typng one letter it goes in correct line |
| 10:56 | <gallant> | in iceweasel it is fine and iceweasel(firefix) is making br tags for line feed character |
| 10:58 | <sangwhan_> | jgraham: It's not Node, more of C++11 although a lot of things are generate from IDL afaik |
| 10:59 | <sangwhan_> | *generated |
| 10:59 | <annevk> | jgraham: https://twitter.com/annevk/status/345406701438119936 |
| 11:00 | <jgraham> | Oh, I see |
| 11:00 | <jgraham> | How confusing |
| 11:01 | <annevk> | Given that NES predates JavaScript by a number of years, lets blame ECMA :-) |
| 11:05 | <Ms2ger> | And brendan |
| 11:13 | <gallant> | what are the squeares which I get when I copy paste few lines from irc chat <gallant> at the start of each new line I get square icon and there are 4 small characters inside it what are those? omg this is exactly what I need what are this squares? |
| 11:36 | <schalkneethling> | hey there everyone |
| 11:36 | <schalkneethling> | so I have a quick question regarding the main element and it's use in a document |
| 11:36 | <schalkneethling> | so, reading the spec here: http://www.w3.org/TR/html51/grouping-content.html#the-main-element |
| 11:37 | <Ms2ger> | I don't think you'll find a lot of people here with an interest in that fork. |
| 11:37 | <schalkneethling> | well it is more of a use question, I just happened to be looking there first, let me look on the whatwg page first |
| 11:41 | <schalkneethling> | I do not see specific mention of the following in http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-main-element but here goes. So in the W3C docs it states "the main element as a descendant of an article, aside, footer, header or nav element" but does not mention the div element however, if I run a page through Validator S.A.C it errors in that a main element cannot be a decendant of |
| 11:41 | <schalkneethling> | a div |
| 11:41 | <schalkneethling> | is this correct or is it a bug in the validator? |
| 11:44 | <MikeSmith> | what's Validator SAC? |
| 11:45 | <schalkneethling> | it's a build of the W3C validator that runs on your local machine |
| 11:45 | <schalkneethling> | http://habilis.net/validator-sac/ |
| 11:47 | <MikeSmith> | schalkneethling: try using http://html5.validator.nu/ directly |
| 11:47 | <MikeSmith> | or http://validator.w3.org/nu/ |
| 11:47 | <schalkneethling> | it is for a page running on my local machine via localhost |
| 11:47 | <schalkneethling> | suggestion on pushing the rendered content there? |
| 11:47 | <schalkneethling> | it is django based |
| 11:48 | <schalkneethling> | so running a validator in my editor is not an option for this instance |
| 11:49 | <MikeSmith> | whatever the markup of the source is that you're feeding to that local validator, make a static copy of it |
| 11:49 | <schalkneethling> | perhaps there is an extension for chrome that submits this, I know the web developer toolbar used to do this in Firefox but last I checked it is not compatible with the latest FF anymore |
| 11:49 | <schalkneethling> | MikeSmith: let me give it a go again |
| 11:53 | <schalkneethling> | MikeSmith: hot sauce, that actually worked this time. On previous runs I ran into some issues but all seems good now |
| 11:53 | <schalkneethling> | thanks |
| 11:53 | <MikeSmith> | ok |
| 11:54 | <MikeSmith> | anyway was far as what the validator checks currently, the main element can be descendant of a div, as long as that div is not a descendant of an article, aside, footer, header or nav |
| 11:57 | <schalkneethling> | MikeSmith: yes, agreed |
| 11:57 | <schalkneethling> | yeah, so the SAC validator has a bug there clearly as the same source passes on validator.w3.org |
| 11:57 | <MikeSmith> | schalkneethling: you can install and run the validator locally without using that thing |
| 11:58 | <schalkneethling> | MikeSmith: I reckon I am going to do that |
| 11:58 | <GPHemsley> | Hixie_: navigator.mimeTypes is the list of MIME types the browser supports, right? I hadn't planned on speccing that. (I thought someone else already did?) |
| 11:58 | <GPHemsley> | Hixie_: I was thinking about window.mimeType/contentType |
| 11:58 | <schalkneethling> | last time I was pressed for time and that seemed like a quick and easy way, but seems like it is going to be better to spend a little time and get it set-up properly |
| 11:59 | <MikeSmith> | schalkneethling: see the instructions at https://bitbucket.org/validator/build/src and feel free to ping me here if you have problems with it |
| 11:59 | <schalkneethling> | thanks MikeSmith will do. |
| 12:02 | <MikeSmith> | jgraham: fyi http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0016.html |
| 12:02 | <MikeSmith> | about using testharness.js with for Web Audio tests |
| 12:02 | <MikeSmith> | "You might want to look at http://mxr.mozilla.org/mozilla-central/source/content/media/webaudio/test/webaudio.jsto see how Ehsan created a little framework for simplifying Web Audio tests, and see if we can build something like that on top of testharness.js." |
| 12:07 | <jgraham> | Hmm, at least some of that file looks like it is already in testharness.js and some of the rest looks like it could be |
| 12:09 | <MikeSmith> | it looks pretty straightforward. I guess I should be it didn't require something more complicated, given the baroqueness of that spec |
| 12:09 | <MikeSmith> | *should be surprised |
| 12:14 | <Ms2ger> | jgraham, yeah, I poked ehsan about that |
| 12:17 | <jgraham> | Replied to that mail |
| 12:17 | <Ms2ger> | Oh, and I got complaints about the lack of window.onerror in th.js |
| 12:23 | MikeSmith | reads jgraham reply |
| 12:23 | <MikeSmith> | "fuzzyCompare is spelled assert_approx_equals" |
| 12:24 | <MikeSmith> | in other news, bravo Jirka http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0027.html |
| 12:24 | <gallant> | can I do iframe in iframe? |
| 12:26 | <SimonSapin> | gallant: Try it? But I think yes |
| 12:29 | <gallant> | ok thanks |
| 12:57 | <jgraham> | Speaking of web audio tests https://critic.hoppipolla.co.uk/r/200 |
| 12:58 | <Ms2ger> | 200! |
| 13:08 | <jgraham> | Ms2ger: "The lack of window.onerror" isn't really a complaint. What actual feature were they missing? |
| 13:09 | <Ms2ger> | Catching errors outside tests |
| 13:09 | <jgraham> | And doing what? |
| 13:09 | <Ms2ger> | Failing somehow, I guess |
| 13:09 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=885107 |
| 13:10 | <jgraham> | So I guess one possibility would be to add an extra result to every test file "tests completed successfully" |
| 13:10 | <jgraham> | And anything that reached onerror would fail that "test" |
| 13:18 | <jgraham> | Or, actually, the harness already has an overall status |
| 13:18 | <jgraham> | So it could be set to error when the test errors |
| 13:19 | <jgraham> | OK, I think I see how to fix this |
| 13:20 | <Ms2ger> | I'm happy to hear that :) |
| 13:30 | <steven__> | Ms2ger: strictly speaking the WHATWG definition of main is a fork of the W3C definition :-) |
| 13:46 | <Hixie_> | technically the two <main> definitions are unrelated |
| 13:46 | <Hixie_> | neither was a copy of the other |
| 13:48 | <hsivonen> | huh. is whatwg mailman not sending out monthly reminders? |
| 13:49 | <steven__> | Hixie_:fine by me |
| 13:55 | <jgraham> | So wait. You mean there is no fork? |
| 14:00 | <steven__> | jgraham: no, just 2 definitions HTML elements that happen to share the same name |
| 14:43 | <Hixie_> | wasn't there a bug on the 'const DOMString product = "Gecko"' thing? |
| 14:43 | <Hixie_> | i can't find it anywhere... |
| 14:45 | <Hixie_> | ah, bug 21591 |
| 14:46 | <Hixie_> | heycam|away: if you could give me a yay/nay on bug 21591 that'd be great |
| 15:12 | <smaug____> | I wonder if EventTarget could have a method removeCurrentListener(); |
| 15:13 | <smaug____> | it would remove the currently called listener |
| 15:14 | <smaug____> | or perhaps addEventlistenerForOneEvent()... tiny bit long name |
| 15:16 | <jgraham> | People keep trying and failing to improve the event api |
| 15:44 | <jgraham> | So does (unprefixed) flexbox support suck in non-presto, or am I doing it wrong? |
| 15:48 | <jgraham> | Ah, the problem in Firefox was my fault / a presto bug |
| 15:49 | <jgraham> | Chrome 29.0.1521.3 dev claims that display:flex is an invalid property value |
| 16:02 | <hasather> | jgraham: it's prefixed |
| 16:02 | <Domenic_> | Is <command> dead in favor of <menuitem>? |
| 16:03 | <dglazkov> | good morning, Whatwg! |
| 16:03 | <jgraham> | hasather: So much for caniuse.com |
| 16:03 | <jgraham> | Also, why? |
| 16:05 | <Hixie_> | Domenic_: yes |
| 16:05 | <gsnedders> | jgraham: So they can change property names at LC again, duh. |
| 16:05 | <hasather> | jgraham: https://code.google.com/p/chromium/issues/detail?id=249111 |
| 16:08 | <Domenic_> | Hixie_: thanks. |
| 16:08 | <Domenic_> | Next question: do void elements like <menuitem /> work in oldIEs or am I screwed if I want to try and polyfill these? (Assuming `document.createElement('menuitem')`) |
| 16:12 | <Domenic_> | Hmm seems to work |
| 16:13 | <Hixie_> | depends on what you mean by "work" and what you mean by "old" |
| 16:13 | <Domenic_> | IE8 really |
| 16:14 | <Domenic_> | the DOM tree according to the dev tools seems sane, which was my main concern |
| 16:15 | <Domenic_> | Of course because they put their text in an attribute instead of the content I'm not going to have a good time (:after { content: attr(label); } doesn't seem to work in IE8). Ah well, I think I'll go back to <li>s. |
| 16:17 | <Hixie_> | oh well you shouldn't use <menuitem> if you're not triggering the native context menu stuff |
| 16:18 | <Domenic_> | Hmm I thought that long thread was saying that <menu> was mainly styled through CSS now. |
| 16:18 | <Domenic_> | Oh I see but the example uses <li>s interesting... |
| 16:19 | <Hixie_> | long thread? |
| 16:19 | <Domenic_> | the one where you outlined the overhaul of <menu> |
| 16:19 | <Domenic_> | i guess the thread wasn't long, just the OP |
| 16:20 | <Hixie_> | oh the old one? |
| 16:20 | <Hixie_> | thought you meant a recent thread :-) |
| 16:20 | <Domenic_> | yeah old :) |
| 16:20 | <Domenic_> | hmm so visually and semantically i am trying to build a popup menu, but only toolbars allow <li>s... |
| 16:22 | <Domenic_> | i do have the escape hatch of saying that i'm inside a custom element (<my-dropdown><button>I trigger the popup menu</button><menu><li>Option 1</li><li>Option 2</li></menu></my-dropdown>) and thus the usual rules don't apply, I think |
| 16:23 | <Hixie_> | "usual rules"? |
| 16:23 | <Hixie_> | why would they not apply? |
| 16:24 | <Domenic_> | Well we were discussing this in the polymer-dev google group and kind of came to the conclusion that inside a custom element, you can give custom semantics to existing elements. |
| 16:24 | <Hixie_> | uh no |
| 16:25 | <Hixie_> | that would screw up the accessibility layer |
| 16:25 | <Domenic_> | hmm |
| 16:26 | <Domenic_> | maybe I should just do <my-menu> then... kind of a shame. |
| 16:29 | <Hixie_> | i don't really understand what you're trying to do |
| 16:29 | <Hixie_> | if you want a <button> with a drop-down menu, then <button menu=""> is meant to do just that |
| 16:37 | <Domenic_> | Yeah fair I haven't exactly been clear |
| 16:38 | <Domenic_> | I am trying for basically exactly <button menu=""> except with custom styles for the menu (so I guess it can't be a <menu type="popup">), and I am using an AngularJS custom element wrapping both to (a) avoid having to introduce id's; (b) work in older browsers. |
| 16:38 | <Domenic_> | That's kind of off topic though so I was hoping to just pop in with a few relevant questions about <menu>. It seems to have snowballed :P |
| 16:39 | <Hixie_> | oh there's no topic here |
| 16:40 | <Hixie_> | there's nothing in theory about <menu> that makes it unstyleable, as far as i recall |
| 16:41 | <Hixie_> | of course, someone would have to implement it first :-) |
| 16:41 | <Ms2ger> | Surely it not being implemented makes it stylable :) |
| 16:41 | <Domenic_> | Well <menu type="popup"> only allows <menu>/<menuitem> children, and I guess the intent is that those are always browser-native widgets |
| 16:41 | <Hixie_> | that's not the intent, no |
| 16:42 | <Domenic_> | oh! |
| 16:42 | <Hixie_> | or rather, the intent is that they be browser-implemented widgets, but there's no reason they shouldn't be styled |
| 16:42 | <Hixie_> | at least in theory |
| 16:42 | <Hixie_> | MikeSmith: yt? |
| 16:42 | <Domenic_> | right, so they would be more like <button> than <select> is what you're saying. |
| 16:42 | <Hixie_> | no reason <select> shouldn't be styleable either |
| 16:42 | <Domenic_> | heh fair |
| 16:43 | <Ms2ger> | And it is styleable, but only in ugly ways :) |
| 16:44 | <Hixie_> | i'm hoping once we have web components we'll be able to define how all the native elements work |
| 16:44 | <Hixie_> | which should make them all styleable |
| 16:44 | <Hixie_> | (dglazkov: ^) |
| 16:44 | <Domenic_> | Hixie_: +1 that will be awesome |
| 16:44 | <Ms2ger> | Clearly we should implement form elements in XBL |
| 16:45 | <Domenic_> | ok so sounds like <menu type="popup"> + <button menu=""> would be perfect, except for the non-polyfillableness in IE8 which doesn't support `menuitem:after { content: attr(label); }`. And of course forward-compatibility concerns. Ah well, good to know the future is at least bright! |
| 16:46 | <Hixie_> | Ms2ger: well that was my original plan, but web components is basically an alternative reality version of xbl |
| 16:46 | <Hixie_> | Domenic_: you can shim it in different ways. e.g. have a script replace them with <div>s. |
| 16:48 | <Ms2ger> | Hixie_, you remember when Gecko actually did that? ;) |
| 16:48 | <Domenic_> | Hixie_: true. might be worth experimenting with. But then my CSS and my markup don't correspond anymore, unlike the solution I'm leaning toward of <my-menu><li>Option1</li><li>Option2</li></my-menu> |
| 16:48 | Ms2ger | can't recall if that was Hixie's or bz's internship |
| 16:48 | <Hixie_> | Ms2ger: not successfully right? |
| 16:49 | <Hixie_> | i mean, xul widgets were xbl, not i don't think html widgets have ever been xbl in mozilla |
| 16:49 | <Ms2ger> | I've removed some of that code at some point |
| 16:49 | <Hixie_> | Domenic_: <li> is only allowed in <ul> or <ol> or <menu> :-P |
| 16:49 | <Ms2ger> | Not sure if it was ever turned on |
| 16:49 | <Hixie_> | i don't think it was |
| 17:26 | <jgraham> | Yeah, seriously, I remember in like 2002 or something when XBL widgets would be turned on Real Soon Now and solve all form styling problems. Now it is 2013 and XBL^WWeb Components widgets will be turned on Real Soon Now and solve all form control styling problems |
| 17:27 | <Hixie_> | yup |
| 17:27 | <TabAtkins> | I'm still not sure how we're going to solve the form control styling problems. I think a lot of people are very naive about the problems with form controls. |
| 17:28 | <Hixie_> | why? |
| 17:29 | <TabAtkins> | Because I've seen at least three distinct version of a time input on Android across OS versions, which would share only the most minimal of styling concerns, and all of which are different from how it looks on desktop Chrome. |
| 17:29 | <Hixie_> | jgraham: i'm getting timeouts from your anolis instance |
| 17:29 | <TabAtkins> | There was the one where each segment of the time was a vertical spinny wheel, one where it was a direct number input with specialized formatting, and one where it's an analog clock display. |
| 17:30 | <Hixie_> | TabAtkins: yeah, you'd probably have to bind to a new component if you wanted more than just colour changes. |
| 17:31 | <Hixie_> | TabAtkins: but in general back with xbl2 the idea is you'd expose pseudo-elements for the parts that you have |
| 17:31 | <Hixie_> | TabAtkins: and let people style those |
| 17:31 | <Hixie_> | and they would map straight to real elements in the shadow |
| 17:31 | <jgraham> | https://bugzilla.mozilla.org/show_bug.cgi?id=57209 for anyone that likes old bugs |
| 17:32 | <jgraham> | Hixie_: Oh. I will look and see if there is anything in the logs |
| 17:32 | <Hixie_> | anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=22531 ? |
| 17:32 | <jgraham> | Just as soon as I remember where the log are |
| 17:32 | <Hixie_> | jgraham: thanks |
| 17:33 | <TabAtkins> | Hixie: The bug just wants you to wrap the spec's contents in a <center>. |
| 17:33 | <Hixie_> | that's all i cound get out of it too |
| 17:33 | <Hixie_> | i think i disagree with the premise of the request... |
| 17:35 | <TabAtkins> | Also possibly it's asking you to do narrower text, centered? Like what CSS specs do. |
| 17:35 | <TabAtkins> | In our EDs, at least. |
| 17:35 | <TabAtkins> | Limiting the line length is important for readability. |
| 17:35 | gsnedders | would dearly love the spec to have a limited line length |
| 17:36 | <jgraham> | Centered? |
| 17:36 | <jgraham> | That's crazt-talk |
| 17:36 | <TabAtkins> | Not like text-align:center. Just put the extra margin space on both sides. |
| 17:36 | <jgraham> | Oh, right |
| 17:37 | <jgraham> | That's not crazy |
| 17:37 | <jgraham> | Although actually with the HTML spec I'm not sure it would make me happy |
| 17:37 | <jgraham> | Hixie_: Well I see timeouts too |
| 17:38 | <jgraham> | My best guess so far is that things are just taking too long |
| 17:38 | <Hixie_> | that would make sense |
| 17:39 | <jgraham> | (this host has some reverse-proxy setup which means that cgi-type scripts that take too long to run never return anything) |
| 17:39 | <jgraham> | (because the frontend server has a fixed timeout) |
| 17:40 | <Hixie_> | d'oh |
| 18:02 | <Hixie_> | jgraham: any suggestions? other than "make the spec smaller"? :-) |
| 18:02 | <Ms2ger> | Make the spec vaguer |
| 18:06 | <jgraham> | Hixie_: Modularization? :p |
| 18:08 | <Hixie_> | i guess one option is for me to just reimplement anolis in a more efficient language |
| 18:08 | <Hixie_> | ("just") |
| 18:09 | <Ms2ger> | Profile it? :) |
| 18:09 | <jgraham> | Well a simpler option would be to run it on your own machine without the fixed timeouts |
| 18:10 | <Hixie_> | the reason i use yours is that my machine can't handle it at all :-) |
| 18:10 | <Hixie_> | the kernel kills html5lib trying to parse it |
| 18:10 | <jgraham> | Anyway, I am trying upgrading the libraries in case they got faster |
| 18:10 | <Hixie_> | ah, cool |
| 18:10 | <jgraham> | Huh, doesn't it use lxml for parsing? |
| 18:10 | <Hixie_> | i thought we used lxml for serialising, or something |
| 18:10 | <Hixie_> | maybe? |
| 18:10 | <Ms2ger> | I'm not sure lxml would deal |
| 18:10 | <jgraham> | And also, why does your kernel do that? |
| 18:10 | <Hixie_> | either way, it wasn't successful. |
| 18:11 | <Hixie_> | so that the site doesn't stop responding |
| 18:11 | <Hixie_> | with an app taking all the cpu and memory |
| 18:12 | <jgraham> | Oh |
| 18:12 | <jgraham> | You mean your dreamhost machine or something? |
| 18:12 | <Hixie_> | yeah |
| 18:13 | <Hixie_> | (that's where i edit the spec) |
| 18:17 | <jgraham> | So, I just updated some stuff |
| 18:17 | <jgraham> | Probably broke the world |
| 18:17 | <SimonSapin> | this side of the world doesn’t look too broken yet |
| 18:24 | Hixie_ | checks |
| 18:24 | <Hixie_> | uh |
| 18:24 | <Hixie_> | something broke, but something long before your code gets involved... |
| 18:24 | <Hixie_> | what the heck was that |
| 18:25 | <Hixie_> | weird |
| 18:25 | <Hixie_> | maybe the cldr updater or the entity updater |
| 18:25 | <Hixie_> | something stalled for a bit |
| 18:25 | <Hixie_> | anyway... |
| 18:27 | <Hixie_> | woot, it didn't time out |
| 18:27 | <Hixie_> | it did change a lot though |
| 18:27 | <Hixie_> | let's see |
| 18:27 | <Hixie_> | some reordered attributes, ok... |
| 18:27 | <Hixie_> | <i> isn't cross-referenced any more? |
| 18:28 | <Hixie_> | <var> either |
| 18:28 | <Hixie_> | oh, probably because of title="" being renamed... |
| 18:28 | <Hixie_> | is there some flag i need to pass to keep on using old-style title="" cross-references? |
| 18:28 | <jgraham> | Ask Ms2ger |
| 18:28 | <Ms2ger> | You're running anolis manually now? |
| 18:28 | <Hixie_> | i'd love to update to, like, data-x="", but i have zillions of lines to update |
| 18:28 | <Hixie_> | no, running jgraham's |
| 18:29 | <Ms2ger> | --w3c-compat-xref-elements I guess |
| 18:30 | <Hixie_> | uh weird, \2019 has turned rsquo into rsquor |
| 18:30 | <Hixie_> | wonder if that's a bug |
| 18:31 | <jgraham> | It is possible that there is a new option in the last N years since anolis was updated that isn't exposed in the UI |
| 18:31 | <Hixie_> | oh interesting, those are identical! |
| 18:31 | <Hixie_> | weird |
| 18:31 | <Ms2ger> | rsquor is probably mathmlish? |
| 18:31 | <Hixie_> | jgraham: well i'm not really using the visual UI |
| 18:31 | <Hixie_> | jgraham: i'm just doing a wget :-) |
| 18:32 | <Hixie_> | jgraham: can you try adding --w3c-compat-xref-elements? |
| 18:32 | <jgraham> | Hixie_: Well you're not using the visual UI but you are using the same form processing code |
| 18:32 | <Hixie_> | yeah |
| 18:35 | <jgraham> | Hixie_: Looks like you can add w3c_compat_xref_elements to the query string |
| 18:35 | <Hixie_> | =on? |
| 18:35 | <jgraham> | (maybe =1 or something although I'm not sure it matters) |
| 18:36 | <Hixie_> | i have w3c_compat_xref_a_placement=on, whatever that is |
| 18:36 | <Hixie_> | fwiw |
| 18:36 | <jgraham> | =on is probably fine |
| 18:36 | <jgraham> | The stuff after the = sign gets ignored for boolean parameters |
| 18:36 | <joshuaAdarme> | hello? |
| 18:37 | <Hixie_> | trying... |
| 18:38 | <Ms2ger> | TabAtkins, yeah, you always sound like that |
| 18:39 | <Hixie_> | validator.nu is one of my main bottlenecks now, it seems |
| 18:39 | <Hixie_> | jgraham: looks like that fixed it! thanks! |
| 18:39 | <Hixie_> | ok, bbiab. thanks again! |
| 18:40 | <Ms2ger> | Your wish is our command, sir :) |
| 19:11 | <kerp> | I can't find any reference to a proposed solution to text-overflow: ellipsis with wrapping text (which I thought someone here had mentioned). ring any bells? |
| 19:15 | <TabAtkins> | Ms2ger: ...when have you heard me? |
| 19:17 | <TabAtkins> | Oh man, my s/the cloud/my butt/ extension doesn't trigger as often as I'd like, but when it does, it's SO WORTH IT. |
| 19:18 | <TabAtkins> | From Henri's twitter: "Anyone with a credit card can get a Linux VM in my butt, but configuring iptables and ip6tables is harder. :-(" |
| 19:19 | <gsnedders> | … |
| 19:19 | <gsnedders> | No, really, …. |
| 19:30 | <jgraham> | gsnedders: Don't worry, if we ever need to get TabAtkins locked up, I think that will be quite enough evidence |
| 19:31 | <TabAtkins> | Hahahahaha |
| 19:44 | <Ms2ger> | TabAtkins, you speak a lot :) |
| 19:52 | <TabAtkins> | Ms2ger: Point. |
| 19:56 | <Hixie_> | jgraham: it timed out again :-( |
| 20:00 | <TabAtkins> | Hixie_: Your dream of collecting the entire web platform into one spec is dashed by technology. |
| 20:02 | <Hixie_> | i guess it's time i wrote my own anolis |
| 20:02 | <Ms2ger> | Maybe you should try weird Glenn's tool |
| 20:02 | <Ms2ger> | Or ReSpec |
| 20:03 | <Hixie_> | glenn's tool? |
| 20:03 | <Hixie_> | respec is a non-starter. |
| 20:03 | <Ms2ger> | The one where you define everything inline in IDL blocks |
| 20:04 | <Hixie_> | are you just trolling me :-P |
| 20:04 | <Ms2ger> | Just listing the current alternatives :) |
| 20:04 | <Ms2ger> | Maybe Bert's tool is faster? |
| 20:04 | <Ms2ger> | On the one hand, it's a lot of C |
| 20:05 | <Hixie_> | bert's tool couldn't handle the html spec like 5 years ago |
| 20:05 | <Ms2ger> | On the other, the rest is shell |
| 20:05 | <Hixie_> | that's why anolis was made |
| 20:05 | <Hixie_> | :-) |
| 20:07 | <TabAtkins> | Try mine? It's like a simpler anolis, but only specialized for the CSSWG so far. |
| 20:08 | <TabAtkins> | However, it depends on what's failing in anolis. |
| 20:08 | <Ms2ger> | Speed |
| 20:08 | <TabAtkins> | Just run it locally, then. |
| 20:08 | <Ms2ger> | Basically, someone decided to write an enormous spec |
| 20:09 | <Ms2ger> | And he edits it on the same box that serves whatwg.org |
| 20:09 | <Ms2ger> | And that box times anolis out when running there |
| 20:10 | <jgraham> | Right, and now *I* run it on a shared host |
| 20:10 | <jgraham> | Which also times it out |
| 20:11 | <jgraham> | So the problem is either a) the size of the spec b) Ms2ger/gsnedders' code c) Python or d) Shared hosting |
| 20:11 | <jgraham> | Depending on your point of view |
| 20:11 | <Ms2ger> | Or all of them |
| 20:11 | <Ms2ger> | Also, you're not running any code of mine, afaik |
| 20:11 | <Ms2ger> | Just gsnedders's |
| 20:11 | <jgraham> | I'm not? |
| 20:11 | <jgraham> | I just pulled the code from your bitbucket at least |
| 20:12 | <Ms2ger> | Not http://hg.hoppipolla.co.uk/hgwebdir.cgi/anolis/? |
| 20:12 | <jgraham> | No |
| 20:12 | <Hixie_> | i think the problem is all of the above, but i mainly blame python :-) |
| 20:12 | <jgraham> | Not sure that's fair |
| 20:13 | <jgraham> | Most of the performance critical parts are really C |
| 20:13 | <Hixie_> | well then e) the C code |
| 20:13 | <jgraham> | (lxml/libxml2) |
| 20:14 | <jgraham> | Of course the overall struture of the program probably isn't optimal |
| 20:14 | <Ms2ger> | I'm pretty sure it isn't |
| 20:14 | <kerp> | anybody know of a proposal to get something like text-overflow: ellipsis for wrapped text? tell me I didn't dream this |
| 20:15 | <Ms2ger> | I still blame gsnedders, though :) |
| 20:16 | <jgraham> | So I'm sure that rewriting in go/haskell/rust could improve performance |
| 20:16 | <jgraham> | But so could optimising the exiting code |
| 20:17 | <jgraham> | And that wouldn't mean implementing a new HTML parser |
| 20:17 | <Ms2ger> | Hmm, maybe I could use hsivonen's translation-to-rust |
| 20:17 | <Ms2ger> | But then again, rust is dog slow |
| 20:17 | <jgraham> | Faster than python |
| 20:18 | <Ms2ger> | Right now? |
| 20:18 | <jgraham> | (can't say anything about hsivonen's autogenerated rust ofc) |
| 20:19 | <SimonSapin> | Ms2ger: rust is slow, you mean runtime or just compilation? |
| 20:19 | <Ms2ger> | Runtime is the issue at hand |
| 20:19 | <TabAtkins> | kerp: What do you mean? ellipsis already works for wrapped text, though it's per-line. |
| 20:19 | <jgraham> | http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/ is the only page I can see with both rust and python numbers |
| 20:20 | <jgraham> | And that's PyPy |
| 20:20 | <jgraham> | And Rust is still fast |
| 20:20 | <jgraham> | er |
| 20:20 | <kerp> | TabAtkins: what do you mean 'per-line'? I mean that text is truncated with ellipsis after some number of lines |
| 20:20 | <jgraham> | Also http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ doesn't look too bad |
| 20:21 | <TabAtkins> | kerp: Okay, that's definitely been discussed, but hasn't made it into a spec yet. |
| 20:21 | <jgraham> | So [citation needed] on rust being very slow |
| 20:21 | <Ms2ger> | The conversation in #rust just now :) |
| 20:21 | <kerp> | TabAtkins: that's what I thought. I guess the list archive just isn't indexed |
| 20:21 | <Ms2ger> | But to be fair, they were talking about C++ |
| 20:21 | <TabAtkins> | kerp: No, it is. But it's also kinda terrible to search for. |
| 20:22 | <kerp> | TabAtkins: but what did you mean by 'wrapped ... per-line'? |
| 20:22 | <TabAtkins> | Look for "block-overflow" |
| 20:22 | <kerp> | thank you! |
| 20:22 | <TabAtkins> | kerp: text-overflow right now applies per-line. If any line overflows the box, it gets ellipsized. |
| 20:22 | <TabAtkins> | Given normal text wrapping that won't normally occur, but it can if one word is extra long and it's a narrow element, for example. |
| 20:23 | <kerp> | I see |
| 20:23 | <TabAtkins> | kerp: Check out the examples at http://dev.w3.org/csswg/css-ui/#text-overflow |
| 20:24 | <Ms2ger> | jgraham, have I asked earlier if you guys had tests for box-sizing? |
| 20:24 | <jgraham> | Ms2ger: Maybe? |
| 20:24 | <jgraham> | I am trying to remember if that's the thing that zcorpan wrote a program to generate tests for |
| 20:24 | <jgraham> | And it made too many tests |
| 20:25 | <jgraham> | Maybe that was object-fit |
| 20:26 | <Ms2ger> | Sounds like something that zcorpan would do |
| 20:27 | Ms2ger | looks at the time, wanders off |
| 20:27 | <jgraham> | (that was object-fit) |
| 20:27 | <jgraham> | grep isn't returning anything promising yet |
| 20:28 | <Ms2ger> | Will try to find another victim then, I guess |
| 20:28 | <Ms2ger> | Thanks for looking |
| 20:33 | <kerp> | TabAtkins: no joy in mudville :/ |
| 20:33 | <TabAtkins> | kerp: Dunno, man. I get results when searching my email for that. |
| 20:33 | <kerp> | subject? |
| 20:35 | <kerp> | since I've already put you to that much trouble :) |
| 20:44 | <gsnedders> | jgraham: Bah, the parser is much quicker than it used to be! |
| 20:45 | <jgraham> | gsnedders: If Hixie is using the parser then no wonder it is timing out |
| 20:45 | <gsnedders> | I thought Hixie_ was using the libxml2 parser? |
| 20:45 | <gsnedders> | The slowness of the rest of Anolis is really just Python being slow. |
| 20:46 | <jgraham> | He is |
| 20:46 | <gsnedders> | Should try running Anolis under PyPy with lxml-cffi |
| 20:46 | <jgraham> | Not really? Isn't it based on multiple passes over the tree for different options? |
| 20:48 | <jgraham> | Would be interesting if it is actually stable |
| 20:49 | <gsnedders> | IIRC the actual time spent iterating is almost nothing; I did experiment with doing global passes of the tree but it gained almost nothing. |
| 20:50 | <gsnedders> | jgraham: Only problem is lxml-cffi currently requires PyPy tip |
| 20:51 | <TabAtkins> | kerp: "block-overflow" ^_^ |
| 20:53 | <kerp> | TabAtkins: list archive search condenses that to "blockoverflow" and can't find either that or "block overflow" :/ |
| 20:53 | <TabAtkins> | kerp: Never ever use the list archive. |
| 20:53 | <TabAtkins> | do a google search with "site:http://lists.w3.org block-overflow" |
| 20:53 | <TabAtkins> | Yeah, first results on that are useful. |
| 20:54 | <kerp> | ah. not lists.whatwg.org |
| 20:54 | <TabAtkins> | kerp: That would certainly explain the lack of results, yes. ^_^ |
| 20:54 | <kerp> | :D |
| 20:54 | <TabAtkins> | This is CSS stuff, it's done by the W3C. |
| 20:54 | kerp | derp |
| 20:57 | <kerp> | thanks for taking the time. was driving me crazy. I really hope this gets through |
| 20:57 | <TabAtkins> | Yeah, me too. |
| 22:04 | <heycam> | Hixie_, I'm OK with adding string constants, so please continue to use it |
| 22:05 | <Hixie_> | oh hey, heycam! |
| 22:05 | <heycam> | hi Hixie_ |
| 22:05 | <Hixie_> | i just asked you a question on bug 21946 |
| 22:05 | heycam | looks |
| 22:06 | <Hixie_> | re the constants, will they be distinguishable from "readonly attribute DOMString foo; // returns 'foo'" ? (and if so, is that ok?) |
| 22:09 | <heycam> | Hixie_, they would be distinguishable, since constants are reflected as data properties, and attributes as accessor properties |
| 22:09 | <heycam> | whether that is OK for this particular case I have no idea |
| 22:10 | <Hixie_> | k |
| 22:10 | <Hixie_> | we'll see who complains |
| 22:11 | <heycam> | will reply on bug 21946 |
| 22:15 | <Hixie_> | thanks |
| 22:26 | <Hixie_> | heycam: while you're at it, also looking for thoughts from you on https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 |
| 22:39 | <heycam> | Hixie_, seems like it might make sense to move the definition of incumbent script into Web IDL |
| 22:40 | <Hixie_> | i would support that emphatically, if you were up for it |
| 22:40 | <heycam> | Hixie_, I wonder if we can use that in place of the "current global environment" stuff too |
| 22:40 | <heycam> | would be nice if they were the same |
| 22:40 | <heycam> | I'll give it a shot today |
| 22:40 | <Hixie_> | fwiw, what i have learnt from working in this area is that the world doesn't care what i think would be nice. |
| 22:41 | <Hixie_> | but i wish you luck! |
| 22:41 | <heycam> | ha |
| 23:01 | <Hixie_> | anyone know who filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22452? "<?xml-stylesheet?> should probably also block scripts. Maybe Link: too if we don't decide to kill it." |
| 23:11 | <Hixie_> | damnit |
| 23:12 | <Hixie_> | now i have to spec PluginArray |
| 23:12 | <Hixie_> | i hate specifying these fake array objects |
| 23:28 | <Hixie_> | can someone with an IE that supports flash paste me the log for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2393 ? |
| 23:36 | <MikeSmith> | Hixie_: here now |
| 23:37 | <Hixie_> | see /msg |
| 23:37 | <Hixie_> | from a few hours ago |
| 23:37 | <MikeSmith> | k |
| 23:42 | <MikeSmith> | Hixie_: that "<?xml-stylesheet?> should probably also block scripts." bug is from Simon I think |
| 23:42 | <Hixie_> | zcorpan? |
| 23:42 | <Hixie_> | k |
| 23:51 | <Hixie_> | apologies. earlier i said the validator was a bottleneck. it's not. |
| 23:51 | <Hixie_> | it's actually the webidl checker. |
| 23:52 | <MikeSmith> | boo for the webidl checker |
| 23:52 | <MikeSmith> | and yay for the validator |