| 03:39 | <mrbean> | Hi, I have two floated divs with border, when I unfloat one, the border dissapears. What's going on? I'm using 4.01 strict. |
| 03:45 | <erlehmann> | mrbean, which browser? |
| 03:45 | <erlehmann> | show source |
| 03:45 | <mrbean> | firefox 4.0.1 |
| 03:46 | <mrbean> | Source: http://pastebin.com/VjCUm4wz |
| 03:47 | <mrbean> | the second div has no border. |
| 03:48 | <mrbean> | Can't see it either in IE9. |
| 03:52 | <tomasf> | mrbean: the borders of those divs end up on top of eachother, so you only see one |
| 03:55 | <mrbean> | I see the second div under the first, they don't overlap. |
| 03:58 | <tomasf> | try changing the size of one of them, and you'll see what I mean |
| 04:00 | <mrbean> | ok |
| 04:00 | <mrbean> | wow, you're right. i can see both. |
| 04:01 | <mrbean> | so htey overlapped but the content appeared below the border. |
| 04:01 | <mrbean> | weird. |
| 04:03 | <mrbean> | thank you |
| 14:38 | <espadrine> | Hixie: the EcmaScript committee is currently discussing the possible addition of a new script-related tag to handle backward-compatible breaks in the language. |
| 14:40 | <espadrine> | Hixie: something like <script-if type="application/ecmascript;version=6"> |
| 14:40 | <espadrine> | // new.js inline-exanded here |
| 14:40 | <espadrine> | </script-if else> |
| 14:40 | <espadrine> | <script ...> |
| 14:40 | <espadrine> | </script> |
| 14:40 | <espadrine> | </script-if end> |
| 14:41 | <espadrine> | I believe it needs discussing with them. |
| 14:45 | <Philip`> | Is that a serious proposal? |
| 14:46 | <Dashiva> | I thought everyone was trying to move _away_ from inline script |
| 14:47 | <shichuan> | looks ugly |
| 14:47 | <erlehmann> | also, they already have stuff like use strict |
| 14:48 | <Dashiva> | Could simply add another "use if-less-than 6" to old.js |
| 14:49 | <Philip`> | If people have to write both new.js and old.js, why don't they just write old.js and always use that and be done with it? |
| 14:51 | <Dashiva> | Maybe new.js is faster |
| 14:53 | Philip` | wonders if the plan is to break compatibility in order to replicate the massive success of Python 3.0 |
| 14:54 | <espadrine> | https://mail.mozilla.org/pipermail/es-discuss/2011-May/014810.html |
| 14:56 | <Philip`> | I think I kind of prefer syntax that is possible to represent with the DOM |
| 14:57 | <Dashiva> | "We discussed generating script tags via document.write conditioned by object detection and the like" |
| 14:57 | <Dashiva> | In the follow-up email |
| 14:58 | <Philip`> | Oh, that'd surely be a much better solution |
| 14:58 | <erlehmann> | this is weird shit |
| 14:59 | <Ms2ger> | Presumably, you would need <script-if type="application/ecmascript;version=6"><!-- code -->... |
| 14:59 | <Ms2ger> | That's what I missed most from the nineties |
| 14:59 | <Dashiva> | Are we going to need CDATA guards as well then? |
| 15:00 | <Philip`> | I suggest putting it all inside a <style> element, because that'll hide the text content from obsolete browsers and it'll indicate that you're selecting different styles of scripting language |
| 15:01 | <Philip`> | Dashiva: No, we're just going to drop XHTML support entirely, either via document.write or non-DOM structures |
| 15:01 | <espadrine> | Mostly, ES.next includes new ways to monkey-patch with "proxies", and new keywords like "let" and "const" |
| 15:01 | <espadrine> | http://wiki.ecmascript.org/doku.php?id=harmony:proposals |
| 15:02 | <Dashiva> | Philip`: Nothing that can't be solved with sufficient nesting |
| 15:03 | <Dashiva> | <script-cond><script-if v6>...</script-if><script-elif v5>...</script-elif><script-else>...</script-else></script-cond> |
| 15:03 | <Dashiva> | (Quiz: What happens if script-elif is before script-if in DOM order) |
| 15:04 | <Ms2ger> | Dashiva, easy, implementation-defined |
| 15:05 | <Ms2ger> | I would suggest <!--[if es 6]><script></script><![endif]--> |
| 15:05 | AryehGregor | sees <http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null>;, yay for back-compat? |
| 15:06 | <Dashiva> | <IE> Vindication at last! |
| 15:06 | <Ms2ger> | AryehGregor, no, this is like XHTML2, we don't need back-compat anymore |
| 15:07 | <AryehGregor> | Ms2ger, ah, good to know. |
| 15:08 | <AryehGregor> | The person who wrote that page seems to be Brendan Eich, though. Wasn't XHTML2 the product of non-browser-affiliated people? |
| 15:09 | <Dashiva> | I was hoping the non-compat efforts could be redirected to Dash |
| 15:09 | <Dashiva> | AryehGregor: Brandan isn't necessarily what you would consider a "browser guy" |
| 15:09 | <Ms2ger> | Well, that's the bigger problem, this might actually get implemented |
| 15:10 | <AryehGregor> | With a mode switch? |
| 15:10 | <AryehGregor> | Sigh. |
| 15:10 | <espadrine> | Brendan Eich already did implement some of ES.next in Firefox |
| 18:12 | <mitnavn> | What's the consensus on wrapping a page's content in a section, separate from page header, nav and footer? |
| 18:17 | <Ms2ger> | A section very rarely makes sense if there's only one |
| 19:07 | <yuhong> | I'd just use the type attribute. |
| 19:07 | <yuhong> | As for else-if, how about adding a new attribute which old browsers will ignore? |
| 19:08 | <yuhong> | Most browsers already support the type attribute and will ignore scripts with unknown values. |
| 19:09 | <Ms2ger> | I believe you miss the point |
| 19:37 | <The_8472> | <espadrine> Mostly, ES.next includes new ways to monkey-patch with "proxies", and new keywords like "let" and "const" <- huh? replacing/intercepting methods at runtime is quite easy already |
| 19:38 | <The_8472> | or do you mean something being called when a property/method is not present? |
| 19:42 | <Philip`> | The_8472: You can intercept unknown ones, and also enumeration and 'in' and 'delete' and stuff, I think |
| 19:43 | <The_8472> | with which ecmascript version? |
| 19:46 | <Philip`> | In http://wiki.ecmascript.org/doku.php?id=harmony:proxies or wherever they're documenting the new stuff |
| 19:50 | <The_8472> | the proxy-api is a quite verbose. ruby's missing_method and handle_method or similar would seem to be easier to use in most cases |
| 19:51 | <The_8472> | ah |
| 19:51 | <The_8472> | most of them are optional |
| 19:51 | <The_8472> | nvm then |
| 20:14 | <AryehGregor> | This netbook is stunningly slow. |
| 20:14 | <AryehGregor> | Like it's taking a couple of minutes to log in a user. |
| 21:29 | <Hixie> | espadrine: version-driven conditionals are an antipattern on the web, because implementations don't implement versions atomically |
| 21:29 | <Hixie> | espadrine: better to design things to be backwards compatible with graceful fallback |
| 23:29 | <yuhong> | <Hixie> espadrine: version-driven conditionals are an antipattern on the web, because implementations don't implement versions atomically |
| 23:30 | <yuhong> | Yea, anyone remember IE6 vs IE7 vs IE8 vs IE9 "standards" mode and X-UA-Compatible? |
| 23:30 | <AryehGregor> | That's a separate issue. |
| 23:30 | <AryehGregor> | There you're talking about versions of the browser, not the standard. |
| 23:31 | <AryehGregor> | IE's X-UA-Compatible does make sense and can be useful, although whether it's ultimately a good idea is debatable. |
| 23:31 | <AryehGregor> | In contrast, asking whether a browser implements a particular version of a spec is almost always useless, because browsers don't implement specs completely all at once. |
| 23:32 | <AryehGregor> | They implement pieces over time, plus the spec changes over time. |
| 23:32 | <yuhong> | I wonder what if IE9 defaulted to IE8 standards mode for the HTML 4.01/XHTML 1.0 DOCTYPEs. |
| 23:32 | <_bga> | its like dll version |
| 23:32 | <AryehGregor> | So you want to know whether it supports the piece you're trying to use, not whether it supports the whole standard. |
| 23:33 | <AryehGregor> | yuhong, why would they want to do that? The whole point of IE9 standards mode is that pages written for other browsers should work in IE9 without much modification, ideally without any modification. |
| 23:33 | <AryehGregor> | IE8's JavaScript support is such that no nontrivial JS written for other browsers will work in IE8. |
| 23:34 | <AryehGregor> | Which is not the case for IE9. I don't know how compatible it is exactly, but I know I've had to make basically no IE9-specific changes to the large complicated JS tests and so on I've been writing lately. |
| 23:34 | <AryehGregor> | And where I have, it's mostly in cases where the feature wasn't specified to start with (i.e., execCommand() or Selection.extend()). |
| 23:35 | <AryehGregor> | Although there are some exceptions. Like nodes that have a null parent but non-null nextSibling . . . |
| 23:41 | <yuhong> | Good point, this reminds me that most of the differences between IE7 and IE8 standards mode has to do with CSS. |
| 23:42 | <yuhong> | Which also reminds me that IE7 standard mode was mostly hacks on top of IE6 standards mode, while IE8 standards mode seems like a rewrite. |
| 23:45 | <aho> | IE7 = IE6 + png, background-attachment:fixed, + and > combinators (buggy), attribute selectors (buggy), and uhm... that's about it |
| 23:45 | <aho> | they also fixed some bugs and added a few new ones |
| 23:46 | <aho> | IE8 on the other hand is almost usable (if you aren't asking for too much) |
| 23:48 | <aho> | IE6+7 are almost extinct in germany :) |
| 23:48 | <aho> | they got about 3% combined |
| 23:48 | <jcranmer> | my old workplace still uses IE 6 |
| 23:49 | <yuhong> | <aho> they also fixed some bugs and added a few new ones |
| 23:49 | <yuhong> | What really caught me was the similarities of the bugs. |
| 23:49 | <aho> | yea, IE6+/ are very similar |
| 23:50 | <aho> | *7 |
| 23:51 | <aho> | they really only patched some things and they did a pretty bad job at it |
| 23:52 | <yuhong> | While IE8 |
| 23:52 | <yuhong> | While IE8's CSS has a few bugs, most of them are not even close to similar to IE7's CSS bugs. |
| 23:54 | <aho> | CSS 1.0 does indeed work pretty well with IE8 |
| 23:54 | <aho> | about damn time, i'd say :> |
| 23:54 | <gsnedders> | AryehGregor: IE9 still has issues with browser-sniffing assuming IE is broken. |
| 23:54 | <yuhong> | But that is the website |
| 23:54 | <yuhong> | But that is the website's fault, of course. |
| 23:54 | <zewt> | i'm not sure that's IE9 having issues :P |
| 23:55 | <gsnedders> | No, but people blame the browser if a site doesn't work. Same issue with Opera going down IE codepath which happens on a number of sites… |
| 23:56 | <zewt> | still doesn't mean it's the browser having issues |
| 23:56 | <yuhong> | Fortunately IE8 and later has compatiblity mode. |
| 23:56 | <yuhong> | Which emulates IE7. |
| 23:57 | <gsnedders> | zewt: Ultimately in some cases if it is a major site then you have a hard choice as a browser vendor, whether to monkey-patch it in the browser. |
| 23:57 | <zewt> | and ... risk breaking things when they fix their site, heh |
| 23:59 | <gsnedders> | zewt: Indeed. But when jQuery/Dojo/etc. all have browser sniffing in them, you often have a hard choice to make when fixing spec bugs that break those libraries. Breaking one of those library will break thousands of sites and the amount of evangelism work needed is massive… |