| 00:21 | <AryehGregor> | sicking, why is a.innerHTML += "<b>what's up dog</b>"; terrible perf-wise? I thought innerHTML was much faster than, say, DOM methods. |
| 00:24 | <Dashiva> | AryehGregor: Because it forces the browser to serialize and then reparse the existing contents in addition to the new markup? |
| 00:25 | <AryehGregor> | So it's fast if the existing contents are short? What would be a better alternative if the contents are long? |
| 00:25 | <TabAtkins> | a.appendChild(b)? |
| 00:26 | <Dashiva> | Isn't this where insertAdjacentHtml is supposed to shine? |
| 00:26 | <Dashiva> | Generally I make sure there is a single element I can just replace the existing contents of |
| 00:28 | <othermaciej> | AryehGregor: it's O(N^2) if you do it N times to the same element |
| 00:28 | <othermaciej> | insertAdjacentHtml avoids the perf hazard, yes |
| 00:29 | <AryehGregor> | Makes sense. |
| 00:29 | <othermaciej> | besides the perf issue per se, by reparsing and replacing contents it could destroy state |
| 00:29 | <othermaciej> | imagine if a includes a playing video, or a currently checked checkbox |
| 00:30 | <AryehGregor> | Interesting point, I hadn't thought of that. |
| 00:30 | <AryehGregor> | So html.innerHTML += foo is very different from document.write(foo). I had thought they were similar. |
| 00:31 | <AryehGregor> | But if the former destroys everything and reparses, and the latter doesn't, that's a very big difference. |
| 00:31 | <othermaciej> | yes |
| 00:31 | <othermaciej> | think of it as html.innerHTML = html.innerHTML + foo |
| 00:32 | <AryehGregor> | Yeah, from that perspective it's clear. |
| 00:32 | <othermaciej> | it's not an in-place append, it a serialize-append-replace-reparse |
| 00:35 | <AryehGregor> | "Casting an array of integers to an array of bytes will give you different results on different hardware." Ugh, isn't JavaScript supposed to not expose endianness? |
| 00:36 | <Philip`> | Not any more |
| 03:46 | <m0> | Do you any of you believe that resizing a canvas should clear the canvas? |
| 03:47 | <m0> | Do any of you believe against that? |
| 06:01 | <heycam> | does innerHTML parse as xml in xml documents? |
| 06:20 | <toyoshim> | ls |
| 06:21 | <othermaciej> | heycam: yes, per the spec http://dev.w3.org/html5/spec/Overview.html |
| 06:21 | <othermaciej> | er |
| 06:21 | <othermaciej> | sorry for lack of fragment ID |
| 06:21 | <othermaciej> | http://dev.w3.org/html5/spec/Overview.html#dom-innerhtml |
| 06:22 | <othermaciej> | heycam: I believe that historically it doesn't work in xml documents |
| 06:25 | <heycam> | crazy :) |
| 06:26 | <heycam> | it is nice to have the facility in xml documents |
| 06:26 | <heycam> | it's just surprising with the name innerHTML -- i assumed the html parser would get at it |
| 06:29 | <hsivonen> | heycam: I think it's sad that innerHTML in XML uses the XML parser. probably Mozilla's fault. |
| 06:29 | <hsivonen> | water under the bridge now, though |
| 06:29 | <heycam> | gecko is indeed where i just discovered that it parsed as xml :) |
| 06:30 | <hsivonen> | the behavior comes from the era when people still believed in XML |
| 06:30 | <heycam> | pshaw |
| 06:31 | <heycam> | i still believe in xml! |
| 06:31 | <heycam> | actually, i just like xslt :) |
| 06:31 | <heycam> | xml infoset + some infoset-like abstraction of xslt would do me |
| 06:31 | <heycam> | regardless of the serialization |
| 06:32 | <hsivonen> | XSLTProcessor::transformToDocument works on text/html input DOMs |
| 06:32 | <hsivonen> | <?xml-stylesheet?> doesn't |
| 06:32 | <heycam> | sure. although i should clarify that nearly all my uses of xslt are off-web. |
| 06:32 | <hsivonen> | heycam: I have code for that! |
| 06:33 | <heycam> | hsivonen, huh? |
| 06:33 | <hsivonen> | heycam: http://about.validator.nu/htmlparser/ look for the XSLT4HTML5 sample app |
| 06:33 | <heycam> | oh! |
| 06:33 | <hsivonen> | heycam: though I recomment using the code from hg tip instead of the latest release |
| 06:33 | <hsivonen> | the release is *old* |
| 06:33 | heycam | does have a toolchain that uses html5parser to convert .html files to .xhtml before passing them through saxon |
| 06:33 | hsivonen | should make a new release |
| 06:33 | <heycam> | er, html5lib |
| 06:34 | <hsivonen> | heycam: on trunk, there's a class you can give to Saxon as the parser, so no boilerplate Java wrapper code is required |
| 06:35 | <heycam> | hsivonen, ah cool |
| 06:35 | <hsivonen> | nu.validator.htmlparser.sax.InfosetCoercingHtmlParser |
| 06:35 | <heycam> | for me this is just in a makefile btw |
| 06:35 | <hsivonen> | http://hg.mozilla.org/projects/htmlparser/rev/b0fe4ac38a02 |
| 06:35 | <heycam> | a small python script invoking html5lib to output xhtml, then calling saxon from the cmdline |
| 06:36 | <heycam> | might be quicker to just involve java and avoid python by using validator.nu |
| 06:36 | <heycam> | probably marginal tho |
| 06:46 | <hsivonen> | now I've seen the third type of script loading browser sniffing: sniffing for "MSIE" and "Safari" and giving them safe code and giving unsfae code to all other browsers :-( |
| 07:16 | <zcorpan> | <http://www.w3.org/mid/6E2EDBA33586754AB83E7D6B3C51CD0907478F⊙Twwnmc>; i guess we're going to see more of that |
| 07:17 | <zcorpan> | also a nice way to get the score down for ie... |
| 07:30 | <zcorpan> | would be nice if aminutewithbrendan.com used <audio> (also in the feed) |
| 07:35 | <paul_irish> | instead of using an enclosure? or in addition? |
| 07:36 | <zcorpan> | what do you mean with enclosure? |
| 07:36 | <paul_irish> | the feed has a podcast style <enclosure> referencing the mp3. the site uses <audio> already.. just wondering what you're suggesting. |
| 07:39 | <zcorpan> | ah. though opera doesn't support mp3, and only shows a link for <enclosure>... |
| 07:39 | <zcorpan> | i don't see <audio> in the source of the page |
| 07:40 | <zcorpan> | oh i see |
| 07:41 | <paul_irish> | https://amwb.s3.amazonaws.com/amwb.js he does it with jPlayer based on.. the something |
| 07:41 | <paul_irish> | anyway.. i'll tell Chris to use an audio element and enhance from there for great justice. |
| 07:43 | <zcorpan> | so i guess what i'd like is an <audio controls> in the body of the feed entries :) |
| 07:44 | <paul_irish> | yup. i think that makes sense. |
| 08:53 | <hsivonen> | hmm. looking at the html5lib tokenizer test changes, it seems that the U+0000 refactoring had interesting effects on the parse errors in the doctypes states |
| 08:55 | <jgraham> | abarth|nacl: Did you see my request to resync the webkit tests with html5lib? |
| 08:55 | <jgraham> | abarth|nacl: It seems like you have some tests for recent changes |
| 08:56 | <jgraham> | hsivonen: Yeah, I seem to recall cases that went from N -> N-1 parse errors since null was not handled specially where it would be dropped anyway |
| 08:56 | <jgraham> | Or something |
| 08:56 | <hsivonen> | jgraham: yeah |
| 09:28 | <hsivonen> | when did <option><span><option> change? |
| 09:28 | <hsivonen> | or has the V.nu parser been wrong all along when parsing that? |
| 09:33 | <zcorpan> | hsivonen: http://html5.org/tools/web-apps-tracker?from=5504&to=5505 |
| 09:33 | <MrWax> | Does anyone know a good overview of new functions (the new JS in HTML5) like getElementByClassName() - functions that were normally used through a lib like jq - but are now native? |
| 09:33 | <hsivonen> | zcorpan: no bug number :-( |
| 09:34 | <hsivonen> | unclear what problem this solves |
| 09:34 | <zcorpan> | hsivonen: there's a separate column for the bug number |
| 09:34 | <MrWax> | Well, I ment , stuff that was normally supposed to be handled with jq (like selecting element by class) |
| 09:34 | <hsivonen> | zcorpan: oh. nice |
| 09:38 | <annevk> | ooh, Microsoft discovered my quirks mode testcase |
| 09:39 | <annevk> | they're not gonna like the parser tests either I assume |
| 09:39 | <annevk> | or the spec for that matter when they realize the tests are right |
| 09:46 | <jgraham> | Yeah, that could be an… interesting discussion |
| 09:49 | <gsnedders> | TabAtkins: Happy birthday! |
| 09:50 | <jgraham> | Yo you |
| 09:50 | <jgraham> | To |
| 09:50 | <jgraham> | Oh god I suck |
| 10:34 | <annevk> | http://www.w3.org/2008/webapps/wiki/Testing_Requirements -- please fix jgraham / gsnedders / zcorpan / TabAtkins / anyone else with ideas about testing |
| 10:42 | <jgraham> | annevk: Note that pywebsocket itself is a known security risk |
| 10:43 | <annevk> | that's a bit too broad |
| 10:43 | <annevk> | risk in what way? |
| 10:44 | <jgraham> | I think it is open to remote code execution vunerabilities |
| 10:44 | <jgraham> | http://code.google.com/p/pywebsocket/issues/detail?id=65 |
| 10:46 | <annevk> | I think the problem Tantek is seeing is more about public-html-a11y⊙wo as they cc that email address to bug reports and get everything single email |
| 10:46 | <annevk> | and maybe he does not realize that |
| 10:47 | <annevk> | jgraham, oh, that sounds problematic |
| 10:47 | <annevk> | add to the wiki? |
| 11:16 | <jgraham> | annevk: AFAICT i don't have access to that page |
| 11:20 | <annevk> | ftfy |
| 11:20 | <annevk> | (well, not the access, but the wiki text) |
| 12:09 | hsivonen | wonders if there's some tutorial out there that tells people to avoid document.write() and run HTML5-incompatible code in browsers whose UA string doesn't say "MSIE" or "Safari" |
| 12:10 | <hsivonen> | there are use cases where document.write() is the right answer |
| 12:30 | <aho> | lies! :v |
| 13:10 | <Workshiva> | hsivonen: You could instead claim that those use cases are the wrong answer to whatever problem they're solving :) |
| 14:28 | <hsivonen> | Bug filed by Hixie in a different era: https://bugzilla.mozilla.org/show_bug.cgi?id=1996 |
| 14:29 | <Workshiva> | We have seen the enemy and he is us |
| 14:32 | <annevk> | it's the era when specifications were gold and critical thinking was so-so |
| 14:36 | <jgraham> | Also from several years before it became obvious that longdesc had failed |
| 14:38 | <hsivonen> | I just saw bugs where Hixie asked for http-equiv="Link" support and Link header support, too |
| 14:42 | <annevk> | surprised you never saw those before |
| 14:43 | <hsivonen> | annevk: I may have seen them before |
| 14:44 | <hsivonen> | I'm just amused by the percentage of Hixie-filed bugs in the still-open deps of the HTML 4.01 tracking bug |
| 15:38 | <annevk> | ooh hmm |
| 15:38 | <annevk> | my recollection skills failed |
| 15:38 | <annevk> | I wonder how we addressed that maxlength issue |
| 15:40 | <zcorpan> | wasn't the issue that pages use <input value="Foo" maxlength=2 name=x> and expect the form to be submittable? |
| 15:43 | <Rik`> | isn't it a reasonable expectation, given that HTML4 has no validation mechanism? |
| 15:43 | <zcorpan> | sure |
| 15:43 | <annevk> | well yeah, but I thought the .value case was included |
| 15:43 | <zcorpan> | submit() skips validation, maybe that solved some of the maxlength problems? |
| 15:45 | <annevk> | could be |
| 15:45 | <annevk> | making submit throw was a real problem |
| 16:40 | <TabAtkins> | gsnedders: Thanks! Woo! |
| 16:40 | TabAtkins | wonders exactly when Facebook informed gsnedders of his birthday. After midnight UK time, or after midnight California time? |
| 16:47 | <karlcow> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11326#c0 |
| 16:47 | <karlcow> | hmm Cable tv |
| 20:34 | <MrWax> | i am looking to retrieve some websql databases i have created in a web page.. how can I retrieve these in chrome?> |
| 20:34 | <MrWax> | i was expecting to see something called 'Developer Tools -> Storage' |
| 20:35 | <cardona507> | use the chrome developer tools (command + option + i) then click on the storage tab |
| 20:37 | <cardona507> | MrWax: ^ |
| 20:38 | <MrWax> | thanks |
| 20:38 | <cardona507> | no prob |
| 20:59 | <karlcow> | what is the state of implementation for CORS http://www.w3.org/TR/cors/ ? |
| 21:09 | <Rik`> | karlcow: I think all latest versions of browsers have support |
| 21:41 | <jgraham> | I think Opera doesn't |
| 21:41 | <jgraham> | karlcow: ^ |
| 21:41 | <jgraham> | Unless we implemented it whilst I wasn't looking |
| 21:43 | <Rik`> | really ? |
| 21:43 | <karlcow> | yes jgraham that was my impression too |
| 21:46 | <annevk> | someone from Opera is just editing it |
| 21:54 | <cardona507> | TabAtkins: this seems great. Is there going to be a video? |
| 21:56 | <Peter-> | Do you still need one? :P |
| 21:56 | <cardona507> | haha |
| 22:09 | <TabAtkins> | cardona507: Yeah, there'll be a video. I'll tweet it when it arrives. |
| 22:10 | <cardona507> | sweetness |
| 22:10 | <cardona507> | that talk seems like a trip |
| 22:10 | <TabAtkins> | It was fun. |
| 22:12 | <paul_irish> | lol @ "a trip". Sylvain's tweet was a good time. |
| 22:12 | <TabAtkins> | Heh, yeah. |
| 22:35 | <gsnedders> | TabAtkins: After midnight in Europe/London |
| 22:36 | <TabAtkins> | gsnedders: kk, interesting. |
| 22:41 | <eighty4> | hey gsnedders mind answering a question? |
| 22:42 | <eighty4> | gsnedders: why is name used for forms? Seems like a lot extra markup for things. Why not just use ids for it? |
| 22:42 | <gsnedders> | eighty4: Legacy, and doing otherwise would break content. |
| 22:43 | <gsnedders> | eighty4: And no point in asking my in particular :) |
| 22:43 | <TabAtkins> | Ask whoever invented <form>. |
| 22:44 | <eighty4> | gsnedders: the "channel" is scary :) |
| 22:44 | <eighty4> | gsnedders: yeah, I get that it cant just be removed. But seems stupid that it was ever implemented |
| 22:45 | <TabAtkins> | @id didn't exist at the time that <form> was created. |
| 22:45 | <eighty4> | but as always I guess it was due to some smart thing I don't understand right now |
| 22:45 | <gsnedders> | What TabAtkins said. |
| 22:45 | <TabAtkins> | In fact, @name carried a decent chunk of the functionality that @id now does. |
| 22:46 | <eighty4> | TabAtkins: in that case it would have been nice if id replaced names use in html5, if name doesn't exist or sometning like that |
| 22:47 | <TabAtkins> | You can't ever " |
| 22:47 | <TabAtkins> | You can't ever "replace" on the web. You can just make something better. |
| 22:47 | <eighty4> | yeah I know :/ |
| 22:47 | <eighty4> | but sometime you just have to say *** legacy. |
| 22:47 | <gsnedders> | eighty4: replacing would break existing content, unless you had different behaviour for HTML5 v. legacy, and the three modes we have already are too many IMO |
| 22:48 | <gsnedders> | eighty4: And XHTML2 was the fuck legacy route |
| 22:50 | <eighty4> | and look how that turned out :/ |
| 22:51 | <Aleoss> | TabAtkins: Wanna bet? There is lots of obsolete attribute in HTML elements. |
| 22:51 | <gsnedders> | eighty4: Indeed. Fuck legacy doesn't work on the web. |
| 22:51 | <gsnedders> | Aleoss: But how many have no affect on processing? |
| 22:51 | <eighty4> | gsnedders: fuck legacy never works :( |
| 22:51 | <eighty4> | but how nice wouldn't it be :) |
| 22:51 | <jgraham> | We replaced <spacer>! |
| 22:51 | <eighty4> | every 5 year ALL legacy is droped and everything is renewed |
| 22:51 | <gsnedders> | jgraham: Only NN (and its successor) ever supported it |
| 22:52 | <jgraham> | Yeah |
| 22:52 | <gsnedders> | So it's not like that was massively widely supported |
| 22:52 | <jgraham> | But that was Victory |
| 22:52 | <TabAtkins> | Aleoss: Yup, but they're rare compared to the language as a whole. It all depends on uptake, and <form>'s @name usage obviously has *far* too much uptake to ever drop. |
| 22:52 | <jgraham> | We don't get that very often |
| 22:52 | <Aleoss> | <b>, <i>, <u> are all obsoleted. They still work for compatibility today, but in ~10 years I bet they will be completely removed from browser rendering of HTML objects. |
| 22:53 | <TabAtkins> | Uh, what? You honestly think that browsers will stop rendering <b>, <i>, etc., thus harming the rendering of a substantial fraction of the trillion+ web pages existing today? |
| 22:53 | <gsnedders> | Aleoss: I bet they'll never be removed. |
| 22:53 | <TabAtkins> | (And <b> and <i> aren't obsoleted, anyway.) |
| 22:53 | <jgraham> | Hahaha |
| 22:53 | <jgraham> | In the nicest possible way |
| 22:54 | <Aleoss> | TabAtkins: Yes, CSS has superceded them. |
| 22:54 | <TabAtkins> | Aleoss: Your sentence doesn't make sense. |
| 22:55 | <Aleoss> | TabAtkins: It's like how Google stopped supporting IE6 a number of months back, as soon as that happened, lots of people got on that as well and said, "Ya, screw IE6." |
| 22:55 | <TabAtkins> | Yes, <b> is entirely described by a "b { font-weight: bold}" rule in the UA stylesheet. And? |
| 22:55 | <TabAtkins> | Why would a browser ever remove that rule from their stylesheet? |
| 22:56 | <jgraham> | Out of all the problems in the world, the <b> and <i> element's continued existence is notable only for the amount of attention it gets compared to its notability |
| 22:56 | <Aleoss> | TabAtkins: I'm saying that <b> is deprecated and obsolete in favour of CSS's font-weight: bold; |
| 22:57 | <TabAtkins> | Aleoss: But it's not. <b> is a perfectly valid and okay element today. And it has value besides the styling (insofar as it indicates in markup something that is bolded in traditional visual display, but which doesn't otherwise have a specific element). |
| 22:57 | <Aleoss> | TabAtkins: Give it about 10 years or so and I bet that the major browsers won't even have <b> or <u> or <i> |
| 22:57 | <jgraham> | In truth, most "semantic" markup is angels-on-the-head-of-a-pin stuff |
| 22:58 | <TabAtkins> | Again, "won't even have <b>" *doesn't make sense*. |
| 22:58 | <jgraham> | some of it is useful though |
| 22:58 | <jgraham> | Aleoss: I would take you up n that bet. For real money and all |
| 22:58 | <TabAtkins> | <b> isn't something that browser have to specially handle, except insofar as they create a particular type of DOM node for it. Outside of the DOM, <b> is just a <span> with a special rule in the UA stylesheet. |
| 22:58 | <TabAtkins> | I would also bet you real money. |
| 22:59 | <Aleoss> | jgraham: I don't care for betting, however, you'll see for yourself in ~10 years. |
| 23:00 | <jgraham> | Indeed I will. In particular I will see that browsers will render <b> as bold just like they did 10 years ago |
| 23:00 | <jgraham> | In order to support all the 25-yeay-old content |
| 23:00 | <jgraham> | *year |
| 23:00 | <jgraham> | That people will still expect to work in their 2020 web browser |
| 23:00 | <TabAtkins> | I just... I just don't understand why you even think it would be *worth* anything to stop rendering <b> as bold. There is literally *zero* benefit, and a ton of cost. |
| 23:01 | <Philip`> | Aleoss: Browsers haven't even got rid of <xmp> yet, and that was deprecated before 1993 |
| 23:01 | <jgraham> | (not to mention 10 year old content and 5 year old content or 1 year old content or entirely contemparary content) |
| 23:01 | <gsnedders> | Aleoss: <b> was deprecated by HTML 4.0 twelve years ago. A decade more is 22 years after deprecation. The web hasn't yet even been around for 22 years, and the longest things that have been deprecated have been for 17 years and are still supported. Why is this going to be so different? |
| 23:04 | <Aleoss> | TabAtkins: A better example is <menu> or <dir> or <center>. They aren't even valid in the HTML 4.0 spec nevermind the HTML 4.01 or later. |
| 23:04 | <jgraham> | Browsers even support <plaintext> and dropping support for that might not be world-endingly-awful |
| 23:04 | <gsnedders> | And plaintext was never in /any/ spec. |
| 23:04 | <gsnedders> | Oh, no, that's untrue. |
| 23:04 | <jgraham> | But this discussion is silly |
| 23:04 | <Aleoss> | https://secure.wikimedia.org/wikipedia/en/wiki/HTML_element#Document_body_elements |
| 23:06 | <Aleoss> | jgraham: According to that URL, <plaintext> was obsolete in HTML 2.0 and was never a HTML standard. |
| 23:06 | <gsnedders> | Aleoss: Yet browsers still support it. |
| 23:07 | <eighty4> | sorry for starting this debate :) |
| 23:07 | <TabAtkins> | Psh, not like we have anything better to do. |
| 23:08 | <gsnedders> | You mean talking about girls on IM isn't better? Oh shit — there goes all semblance of doing anything useful… |
| 23:10 | <Aleoss> | Why talk about girls? They're all the same, only difference is that some are more beautiful and use that to their own advantage. |
| 23:10 | <TabAtkins> | ... |
| 23:11 | <gsnedders> | Some are cute and cuddly ^-^ |
| 23:11 | TabAtkins | thinks that most are, personally, though of course he only actually cuddles with his wife. |
| 23:12 | <jgraham> | Aleoss: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/705 <-- try in your favourite browser. You will find that <plaintext> is quite functional wikipedia notwithstanding |
| 23:13 | jgraham | thinks TabAtkins appraoch to determining cuddliness cannot be very scientific |
| 23:14 | <TabAtkins> | It's very scientific. My instruments are just more accepting. |
| 23:14 | <gsnedders> | Hmm, maybe we should be talking about huggability than cuddliness |
| 23:14 | <jgraham> | For all you know most woment hide a variety of pointy weaponry about their person |
| 23:14 | <jgraham> | Which would make cuddling them lethal |
| 23:15 | <jgraham> | *women |
| 23:15 | <TabAtkins> | My experience does not back up that statement. |
| 23:15 | <jgraham> | Your experience is a sample of 1 |
| 23:15 | <jgraham> | Not very scientific :) |
| 23:16 | <jgraham> | Is it obvious that I should be asleep already? |
| 23:16 | <TabAtkins> | My sample size was much larger in the past before public opinion required me to cut it down to a single specimen. |
| 23:16 | <jgraham> | Public opinion or your wife's opinion? |
| 23:16 | <TabAtkins> | I'll leave that to the media to decide. |
| 23:17 | gsnedders | just runs around cuddling everyone |
| 23:17 | <gsnedders> | (as jgraham can attest, even though he never wanted to be cuddled) |
| 23:17 | <TabAtkins> | But jgraham is inherently cuddly! |
| 23:18 | <jgraham> | You appear to be confusing me with paddington bear |
| 23:18 | <jgraham> | an easy mistake to make |
| 23:18 | <jgraham> | But I am not from Peru |
| 23:18 | <Dashiva> | You both speak English, though |
| 23:19 | <TabAtkins> | Dashiva's got you there. |
| 23:19 | <TabAtkins> | On a random note, my little brother is conducting extensive genetic studies of ghost/human hybrids in Sims 3. His results are fascinating. |
| 23:21 | <eighty4> | gsnedders: ok, one more question :) |
| 23:22 | <gsnedders> | eighty4: Ask the channel! |
| 23:22 | <gsnedders> | They're not scary. |
| 23:22 | <eighty4> | why not at least take one step in the right direction and say that in html5 if name is "missing" it should use id instaed |
| 23:22 | <gsnedders> | They don't bite! |
| 23:22 | <eighty4> | *instead. |
| 23:22 | <gsnedders> | eighty4: Content relies upon that not happening. |
| 23:22 | <gsnedders> | (Yes, seriously.) |
| 23:22 | <TabAtkins> | eighty4: Still not compatible with legacy content, which has plenty of form elements lying around with an id but no name. |
| 23:22 | <eighty4> | Just deciding that would likely make some people use it and would force new browsers to implement it |
| 23:23 | <eighty4> | TabAtkins: what would break? |
| 23:24 | <TabAtkins> | Some forms would submit more inputs than expected. |
| 23:24 | <eighty4> | oh... |
| 23:25 | <eighty4> | yeah, just realized that |
| 23:25 | <eighty4> | it could cause validation problems on the server side, stupid >< |
| 23:25 | <TabAtkins> | form-processing scripts are just remarkably fragile all around, sadly. |
| 23:26 | <eighty4> | I still say, fuck legacy. It'st just stupid to strive for perfect legacy support. Imagine 100 years from now :P |
| 23:26 | <gsnedders> | Then you end up with IE6. |
| 23:26 | <eighty4> | and now it's time to sleep, 00.31 here. Way to late |
| 23:26 | <gsnedders> | The later versions break legacy content, so people keep using the old browser. |
| 23:27 | <eighty4> | gsnedders: ie7 is still broken just to support ie6 code |
| 23:27 | <gsnedders> | So even all browsers at once making the breaking change doesn't help |
| 23:27 | <eighty4> | the net would need a total reinstall every 5 year. I say wipe it all! |
| 23:27 | <eighty4> | except for actual data, that is |
| 23:27 | <eighty4> | and recode it all! |
| 23:28 | <TabAtkins> | There are a trillion pages in existence, most of which depend on stupid legacy behavior in some form or another. Are you really willing to say "Hey everybody, start using this new browser which won't correctly render any of those trillion pages!"? |
| 23:28 | <eighty4> | Would make our work a lot simpler :P end the demand for webdevs a lot bigger |
| 23:28 | <TabAtkins> | Breaking windows to make work for the glassmaker isn't a net plus for the village. ^_^ |
| 23:28 | <eighty4> | TabAtkins: no, I know :/ |
| 23:29 | <eighty4> | it's not a solution, but at least let me dream about it |
| 23:29 | <TabAtkins> | Legacy sucks, but that's how the world works. Shrug. Make the best of it. |
| 23:29 | <eighty4> | TabAtkins: well, it's not really how the rest of the world works. Is it? |
| 23:31 | <eighty4> | hardware doesn't really work that way, computers don't come with a 5.25'' just to not break legacy. No one have walkmans any more |
| 23:31 | <eighty4> | and so on |
| 23:31 | <TabAtkins> | Sure it is. The only difference is that the rest of the world has decay as a force that helps them obsolete stuff. |
| 23:31 | <TabAtkins> | Bitrot isn't quite the same thing as decay. ^_^ |
| 23:32 | <eighty4> | so you're saying we need more decay on the web? |
| 23:32 | <eighty4> | but NOW i need to sleep. Later! |
| 23:32 | <gsnedders> | And then they turn into zombies and — SHIT! THEY'RE COMING! |