| 08:16 | <annevk> | Hixie: so I'm still not quite sure how to modify http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#new-stacking-layer |
| 08:16 | <annevk> | it already has |
| 08:17 | <annevk> | * It generates a new stacking context. |
| 08:17 | <annevk> | * Its containing block is the initial containing block. |
| 08:17 | <annevk> | * It is rendered as an atomic unit as if it were a sibling of the root element. |
| 08:20 | <annevk> | I'll make a suggestion |
| 08:26 | <annevk> | lol |
| 08:26 | <annevk> | someone is suggesting a separate mailing list for fullscreen |
| 08:28 | <annevk> | joint WG publications, token editor to please the CSS WG, W3C backflips the shark |
| 08:51 | <annevk> | <!DOCTYPE html>.<script> document.documentElement.replaceChild(document.head, document.body) </script> |
| 08:51 | <annevk> | results in <html><head/></html> |
| 08:52 | <annevk> | so I try to replace <head> with <body> and end up with <head> |
| 08:54 | <annevk> | and <body> is returned |
| 08:56 | <annevk> | oops nm |
| 12:51 | <Ms2ger> | annevk, yt? |
| 12:52 | <Ms2ger> | Or AryehGregor |
| 12:54 | <Ms2ger> | Looking at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-replace |
| 12:55 | <Ms2ger> | It seems the 3rd step is redundant, because we already established that /parent/ has a child, so it must be a Document, DocumentFragment, or Element |
| 13:06 | <fflorent> | Hi, |
| 13:06 | <fflorent> | what is the reason why this proposal has been gave up? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023702.html |
| 13:18 | <AryehGregor> | Ms2ger, yes, you're right. Looks redundant to me. |
| 13:34 | <AryehGregor> | fflorent, IIRC, because it's too hard and fragile and will never give you the flexibility of AJAX, so it's not clear anyone much would use it.. |
| 13:34 | <AryehGregor> | s/\.$// |
| 13:39 | <fflorent> | AryehGregor: hmm, why hard and fragile ? |
| 13:52 | <AryehGregor> | fflorent, I don't remember the details. It was two and a half years ago. Basically, it wasn't clear that it was useful enough (relative to emulating it with AJAX) to warrant a new declarative attribute. |
| 13:52 | <AryehGregor> | I still think it was a cool idea, though. :) |
| 13:53 | <fflorent> | AryehGregor: thank you for your answer :) |
| 13:54 | <fflorent> | AryehGregor: I ask this question because I have a similar proposition ... And I want to know what was the matter with that proposition before. |
| 13:56 | <AryehGregor> | fflorent, did you review the whole original thread? |
| 13:57 | <fflorent> | I read it, but perhaps there are things I have not read |
| 13:58 | <AryehGregor> | fflorent, everything starting with this? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023661.html |
| 13:58 | <fflorent> | I see that there are previous messages in the thread from here : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023702.html . |
| 13:58 | <fflorent> | But I do not know how to access |
| 13:58 | <AryehGregor> | There are a few dozen posts, many quite long. |
| 13:59 | <AryehGregor> | Try looking at what I just posted, and all the followups. |
| 13:59 | <AryehGregor> | A lot of possible variants and pitfalls are pointed out. |
| 13:59 | <fflorent> | thank you :) |
| 13:59 | <AryehGregor> | All the variants wind up failing in unpleasant ways if misued. |
| 13:59 | <AryehGregor> | misused. |
| 14:00 | <fflorent> | hmm, ok |
| 14:00 | <AryehGregor> | And it's not straightforward for authors to make sure they use them right. |
| 14:00 | <AryehGregor> | It would be pretty easy to update one page and forget to update another and suddenly things don't work right. |
| 14:01 | <AryehGregor> | So at a certain point it looks like it's not worth the resources. New markup like that is only worthwhile if it would be really useful. |
| 14:04 | <fflorent> | what do you mean by "update one page and forget to update another" ? |
| 14:27 | <fflorent> | AryehGregor: I read that using query parameters break bookmarking. However, I just bookmarked a result page from google (on Firefox) and it worked great. I do not understand why does it breaks bookmarking ? (sorry for my noob questions ^^ ) |
| 14:27 | <fflorent> | AryehGregor: source : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023686.html |
| 16:20 | <tantek> | sorry to be "token" for too long annevk |
| 16:20 | <tantek> | now that I've got hg and Anolis setup - hope to make more contributions soon |
| 17:28 | <annevk> | tantek: no worries |
| 17:29 | <annevk> | although maybe I should start keeping a wiki page on W3C fuckups |
| 17:38 | <veosotano> | annevk: what would you say is the W3C's biggest problem as an organization? |
| 17:41 | <veosotano> | I wonder if the slowness is something about how it is structured |
| 17:44 | <annevk> | too much rules |
| 17:44 | <veosotano> | but without those rules, wouldn't quality of standards suffer? |
| 17:44 | <veosotano> | (just curious) |
| 17:45 | <annevk> | not in my experience |
| 17:45 | <veosotano> | is there no proposal to improve the efficiency of the w3c or something? |
| 17:45 | <annevk> | standards can be of extremely high and low quality; both with and without those rules |
| 17:45 | <annevk> | (and have been) |
| 17:46 | <veosotano> | I guess it would be difficult to put on paper (sort of like rules), something that ensures the quality |
| 17:46 | <annevk> | veosotano: sure sure, but it's slow as is to be expected of an organization with 400+ stakeholders |
| 17:46 | <annevk> | http://wiki.whatwg.org/wiki/Howto_spec has a start as far as writing goes |
| 17:47 | <veosotano> | oh, cool |
| 17:48 | <veosotano> | I'll bookmark his |
| 17:48 | <veosotano> | *this |
| 17:49 | <veosotano> | thanks! |
| 17:50 | <veosotano> | annevk: have you ever heard of the AXR Project? |
| 17:50 | <annevk> | nope |
| 17:50 | <veosotano> | if so, what is your opinion? |
| 17:50 | <veosotano> | ok |
| 17:50 | <veosotano> | I'm the founder of that project |
| 17:51 | <veosotano> | I could give you a link to the video of the presentation |
| 17:51 | <veosotano> | it's 50 mins long if you have spare time |
| 17:51 | <thisgeek> | veosotano: it may be instructive, as it was for me today, to read through a summary of how the w3c HTML working group comes to a decision. Here's an example: http://lists.w3.org/Archives/Public/public-html/2011Mar/0574.html |
| 17:51 | <veosotano> | if not, I could give you an introduction |
| 17:52 | <veosotano> | thisgeek: thank you very much :) |
| 17:52 | <veosotano> | looks very bureaucratic, btw |
| 17:52 | <Ms2ger> | You may want to read http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0338.html too |
| 17:55 | <annevk> | Ms2ger: hadn't seen that before |
| 17:56 | <veosotano> | I think he's right |
| 17:56 | <annevk> | yeah, the HTML WG is a joke |
| 17:57 | <annevk> | it's one of the fuckups |
| 17:57 | <veosotano> | so how does it work effectively? |
| 17:57 | <veosotano> | does webkit follow what the whatwg specs? |
| 17:57 | <thisgeek> | veosotano: As I read it, the process not only invites comment and objections, but takes care to address and assess the quality of those objections. I wonder if that's connected to the peer review process that submissions for academic journals are put through. |
| 17:57 | <Ms2ger> | MikeSmith mentioned it in here once, but without a URL |
| 17:59 | <veosotano> | thisgeek: do you think that those objects are effective to remove the bureaucracy that is slowing it down so much? |
| 17:59 | <annevk> | veosotano: yeah they do |
| 17:59 | <veosotano> | what does the HTMLWG do, then? |
| 17:59 | <thisgeek> | But I think there is a good arguement in "there's just too many stakeholders". I think Kris Kowal has some experience deal with this in regard to the growing interest in CommonJS. |
| 18:00 | <thisgeek> | veosotano: Are the objections effective? I honestly don't know yet. |
| 18:01 | <veosotano> | there have been many objections over the years, we're still at the same pace :S |
| 18:03 | <veosotano> | annevk: the axr project is about creating an alternative to current web standards, I'd like to tell you more about it if you want, but I completely understand if you are too busy |
| 18:04 | <gsnedders> | veosotano: Yet you don't know how current web standards come about? |
| 18:05 | <veosotano> | well I do from a designer/developer perspective |
| 18:05 | <veosotano> | I didn't know the exact process used internally |
| 18:06 | <gsnedders> | veosotano: If you're trying to come up with anything new, remember that for all practical purposes, impls have a veto. You can put what you like in the spec if you get consensus on it, but if impls don't impl it, it's meaningless. |
| 18:06 | <annevk> | veosotano: I read the site a bit |
| 18:07 | <Ms2ger> | It sounds like XHTML2 to me |
| 18:07 | <veosotano> | it's not |
| 18:07 | <veosotano> | I wonder why so many jump to that conclusion so fast |
| 18:07 | <annevk> | veosotano: looks like a cool project, but I don't think that's gonna work (otherwise I'd be working on something similar :) ) |
| 18:08 | <veosotano> | gsnedders: it's not about a spec, but about an actual implementation |
| 18:08 | <veosotano> | the prototype already does most of the new features in the HSS language |
| 18:08 | <veosotano> | annevk: well I invite you to do so :) |
| 18:08 | <veosotano> | please watch the video |
| 18:08 | <Ms2ger> | When I read "replacing the current web technology with something done better, based on XML", I'm afraid "XHTML2" is the first thing to pop into my mind |
| 18:09 | <veosotano> | and think about if I'm saying completely absurd things (which I don't think they are) I sincerely apologize :) |
| 18:09 | <annevk> | veosotano: also, http://en.wikipedia.org/wiki/Monoculture_(computer_science) |
| 18:09 | <veosotano> | Ms2ger: we want to use XML only as a thin data layer |
| 18:09 | <thisgeek> | veosotano: I suspect your biggest hurtle will be working with browser vendors to get it implemented. Do you think that's correct? |
| 18:09 | <annevk> | veosotano: it's a positive thing we have multiple engines today |
| 18:10 | <veosotano> | thisgeek: the plan is not to have browsers implement it |
| 18:10 | <veosotano> | annevk: but it's a hell for a developer |
| 18:10 | <veosotano> | fragmentation is a big problem |
| 18:10 | <annevk> | hell is IE6 |
| 18:10 | <annevk> | or WebKit mobile |
| 18:10 | <gsnedders> | veosotano: IE6 was a monoculture, was that good for developers? |
| 18:10 | <gsnedders> | veosotano: Is WebKit on iOS and Android being so outdated good for developers? |
| 18:10 | <veosotano> | the problem is actually that there is no part of the language that allows for control over how implementations advance |
| 18:11 | <veosotano> | there can be no infinite forwards and backwards compatibility |
| 18:11 | <veosotano> | with zillions of implementations |
| 18:11 | <gsnedders> | In what sense? |
| 18:11 | <veosotano> | the rendering engines have no knowledge about what the developer meant when he wrote the code |
| 18:12 | <veosotano> | it's just whatever its put out there |
| 18:12 | Ms2ger | goes back to writing tests |
| 18:12 | <veosotano> | since browsers just implement whatever the heck they want |
| 18:12 | <gsnedders> | How do you get rid of dependence on browsers without impacting performance? |
| 18:13 | <veosotano> | Ms2ger: I don't believe xHTML2 died because of XML |
| 18:13 | <Ms2ger> | Oh, I don't either |
| 18:13 | <veosotano> | gsnedders: wait, do you mean in rendering performance? |
| 18:14 | <annevk> | veosotano: don't let us tell you too much about how your ideas are improbable; that's not the way to success :) |
| 18:14 | <gsnedders> | veosotano: General performance |
| 18:14 | <gsnedders> | veosotano: Including but not limited to rendering perf |
| 18:14 | <veosotano> | gsnedders: you need native speed |
| 18:14 | <veosotano> | if possible with HW acceleration |
| 18:15 | <gsnedders> | veosotano: How do you get that in a secure manner, while having all browsers improving at a constant rate? |
| 18:15 | <veosotano> | the project proposes to create a new rendering engine… which is native code |
| 18:15 | <veosotano> | because it's an open source project |
| 18:15 | <gsnedders> | veosotano: And what makes you think Apple will ship that on iOS, for example? |
| 18:15 | <veosotano> | security problems can be analyzed and fixed in the community |
| 18:16 | <veosotano> | iOS is actually the hardest nut to crack |
| 18:16 | <veosotano> | but we'll try to create an application |
| 18:16 | <gsnedders> | You won't get it on the App Store if you want JS execution at all. |
| 18:16 | <veosotano> | so there is no way of getting it to work in safari, but it could redirect through the use of custom protocols, like instapaper does |
| 18:17 | <veosotano> | gnsedders: can JavascriptCore not be used? |
| 18:17 | <veosotano> | that would be a problem indeed |
| 18:17 | <gsnedders> | veosotano: But then you'll have differences between engines. |
| 18:17 | <veosotano> | point taken :( |
| 18:17 | <veosotano> | damn rules |
| 18:18 | <gsnedders> | veosotano: Also, how can something be a true standard if there's only one implmenetation of it? |
| 18:18 | <veosotano> | correct me if I'm wrong, but I think interoperability between JS engines (in modern browsers) is way superior to css support, for example |
| 18:18 | <veosotano> | gsnedders: well that depends on how you define the term standard |
| 18:19 | <Ms2ger> | Well |
| 18:19 | <veosotano> | webkit is a de facto standard today |
| 18:19 | <gsnedders> | veosotano: If it's a standard then others will want to try and make a better implementation, in all probability |
| 18:19 | <Ms2ger> | The ECMAScript spec has historically been better than the CSS specifications |
| 18:19 | <veosotano> | why not improving the existing one? |
| 18:19 | <veosotano> | I mean the existing implementation |
| 18:19 | <gsnedders> | veosotano: Why are there multiple impls of HTML/CSS/etc.? |
| 18:20 | <veosotano> | it should benefit the whole platform |
| 18:20 | <veosotano> | because of business interests |
| 18:20 | <gsnedders> | If you think it's just business interests, you're wrong. |
| 18:20 | <veosotano> | then please set me right :) |
| 18:21 | <gsnedders> | It would be a massive financial saving for people not to be developing four browser engines. |
| 18:21 | <veosotano> | I think the only good thing of Flash was that it worked the same everywhere (everything else was horrible) |
| 18:23 | <thisgeek> | Ms2ger: I couldn't resist asking, since I am working on a presentation about this right now, but why do you think XHTML2 failed, if not because of XML. |
| 18:23 | <thisgeek> | ? |
| 18:23 | <gsnedders> | Different browsers have different technical pros and cons, like different trade-offs between performance and memory usage, and differences in whether they handle OOM in all places. |
| 18:23 | <veosotano> | gsnedders: that's precisely what makes webdevelopment so hard |
| 18:24 | <gsnedders> | veosotano: Because performance varies? |
| 18:24 | <veosotano> | for example |
| 18:24 | <veosotano> | there are many presentations out there talking about how to improve performance |
| 18:24 | <gsnedders> | veosotano: Performance on a smartphone will never *ever* be the same as on a desktop computer. |
| 18:24 | <veosotano> | I know that, of course |
| 18:25 | <gsnedders> | And if you're running on a TV with 128MB RAM, you need to be concervative of memory, even if that means being slower. |
| 18:25 | <veosotano> | what is the benefit of having all the differences in those trade offs? |
| 18:25 | <gsnedders> | Being able to run on lower-end devices v. higher performance on more powerful devices. |
| 18:25 | <veosotano> | ok, I get that there are differences in the platforms |
| 18:26 | <veosotano> | and maybe saying the exact same implementation is a bit of an oversimplification |
| 18:26 | <gsnedders> | As soon as you have variation in the impls, you have the same problems as we have now. |
| 18:26 | <veosotano> | of course different tradeoffs will be necessary to make to make it run well everywhere |
| 18:26 | <veosotano> | no |
| 18:26 | <veosotano> | because todays differences are not about that |
| 18:26 | <veosotano> | they are about differences in syntax |
| 18:26 | <veosotano> | differences in decisions that were not specd |
| 18:26 | <veosotano> | legacy compatibility |
| 18:27 | <gsnedders> | HTML5, the quirks mode spec are all about unifying that for legacy compatibility. |
| 18:27 | <veosotano> | there needs to be a concensus about what are the pixels that show up on the screen for a given code |
| 18:27 | <gsnedders> | And this was pretty HTML5's original primary goal. |
| 18:27 | <veosotano> | gsnedders: in no way I'm arguing the whatwg is doing a poor job |
| 18:27 | <veosotano> | what I'm arguing is that HTML is not good for the future |
| 18:28 | <veosotano> | I'd love it if you would watch the presentation and then gave me your opinion again |
| 18:29 | <gsnedders> | veosotano: Why? I'm still not clear. Differences in rendering? But the whole point of most of spec work atm is to have identical rendering. |
| 18:29 | <veosotano> | well it's not translating into reality |
| 18:30 | <veosotano> | for example on a desktop, what is the benefit of having multiple ways of doing the same thing? |
| 18:30 | <Ms2ger> | Oh look, a [Hixie-P4] bug from 1998 just got WONTFIXed |
| 18:30 | <veosotano> | why not all together figure out what is the *best* way of doing something? |
| 18:30 | <gsnedders> | veosotano: Give me one example where that has happened? |
| 18:31 | <veosotano> | that experts have joined together and decided the best solution to a problem? |
| 18:31 | <veosotano> | ECMAScript has worked pretty well |
| 18:31 | <veosotano> | I mean ECMA |
| 18:31 | <gsnedders> | Without having one implementation. |
| 18:32 | <veosotano> | I don't follow... |
| 18:32 | <veosotano> | we have an implementation |
| 18:32 | <gsnedders> | There are multiple ECMAScript impls. |
| 18:32 | <Ms2ger> | thisgeek, because browser implementors had no interest in supporting XHTML2 |
| 18:34 | <veosotano> | gsnedders: I think it hasn't happened, but that doesn't mean it couldn't |
| 18:34 | <veosotano> | and btw, we have no other thing that is equal to the internet |
| 18:34 | <veosotano> | I think it is for the benefit of the whole internet |
| 18:34 | <veosotano> | I don't want to make money off of it |
| 18:34 | <veosotano> | well maybe not internet… |
| 18:34 | <veosotano> | I mean for the web |
| 18:35 | <veosotano> | the application delivery system we have |
| 18:36 | <veosotano> | I agree about the dangers of monoculture |
| 18:36 | <veosotano> | but historically those monocultures were in the hands of private businesses |
| 18:36 | <veosotano> | not in something that is open sourced and meant for the greater good |
| 18:36 | <gsnedders> | veosotano: WebKit is open source and the monoculture on mobile is very much a problem. |
| 18:37 | <veosotano> | what are those problems exactly? |
| 18:37 | <veosotano> | I'm honestly interseted |
| 18:37 | <veosotano> | *interested |
| 18:38 | <gsnedders> | veosotano: Mobile sites relying upon WebKit bugs, mobile sites relying upon -webkit-. |
| 18:38 | <veosotano> | would those be problems if webkit was the only implementation? |
| 18:38 | <gsnedders> | Yes, because the sites would still be relying upon something that differs to the standard. |
| 18:39 | <gsnedders> | Unless the WebKit code base was the standard and hence, by definition, had no bugs. |
| 18:39 | <veosotano> | if the ones that create the standard and the implementations are the same organization |
| 18:39 | <veosotano> | nono |
| 18:39 | <veosotano> | there is no way of having no bugs |
| 18:39 | <veosotano> | bugs will always happen |
| 18:39 | <veosotano> | you need to find a way to manage them |
| 18:39 | <gsnedders> | veosotano: Then there is no way to stop websites from relying upon bugs in the implementation |
| 18:39 | <annevk> | and you need competition to avoid having sites rely on bugs |
| 18:40 | <veosotano> | that's because people don't code to specification |
| 18:40 | <veosotano> | they code to implementation |
| 18:40 | <benvie> | it means when you try to make something with different ideas you have to not only get over the normal hurdle of producing something that is good enough quality, but you also have to get over the hurdle of entrenched adherence to proprietary bugs. Proprietary in the sense that it's a specific implementation, even if open source |
| 18:40 | <veosotano> | they don't differ between bug and feature |
| 18:40 | <gsnedders> | veosotano: How do you get people to code to specs? People tend to hack stuff together till it work, specs be damned. |
| 18:40 | <veosotano> | annevk: I don't think that's the only way |
| 18:40 | <gsnedders> | veosotano: Once you have sites relying upon bugs, you have to change the spec to the impl, so the spec may as well be the impl. |
| 18:41 | <benvie> | the webkit on mobile thing is helping to prove beyond a bout that it is in fact true, if we didn't know it already |
| 18:41 | <gsnedders> | veosotano: Equally, if you have a single impl, what do you gain by having a separate spec? |
| 18:41 | <veosotano> | gsnedders: that's only if there is no way of managing that |
| 18:41 | <gsnedders> | veosotano: People management won't work. |
| 18:41 | <veosotano> | what I mean is that the current web is versionless |
| 18:42 | <veosotano> | and then yes, you have no way to manage bugs |
| 18:42 | <veosotano> | and less so in such an hostile environment as todays browsers |
| 18:42 | <benvie> | competition still sparks ongoing impetus for improvement between the players in the field |
| 18:42 | <veosotano> | I don't think the community stalls like a business does |
| 18:43 | <veosotano> | think about it |
| 18:43 | <veosotano> | business don't care |
| 18:43 | <veosotano> | if they won with their monoculture |
| 18:43 | <veosotano> | they'll stop spending resources |
| 18:43 | <gsnedders> | You still need buisnesses to ship it, ultimately. |
| 18:43 | <veosotano> | why? |
| 18:43 | <gsnedders> | veosotano: How do you get on iOS? |
| 18:43 | <veosotano> | damn apple rules again |
| 18:43 | <gsnedders> | veosotano: How do you market it to end users |
| 18:44 | <gsnedders> | *? |
| 18:44 | <veosotano> | that's a better question |
| 18:44 | <veosotano> | for the end users it will have many benefits |
| 18:44 | <veosotano> | such as faster and better pages (in average) |
| 18:44 | <veosotano> | because of the productivity increase |
| 18:44 | <veosotano> | more budget can be allocated on polishing the fine details |
| 18:44 | <gsnedders> | What budget? |
| 18:45 | <veosotano> | what clients of a web design firm pay them to create a website |
| 18:45 | <veosotano> | or a web application |
| 18:45 | <gsnedders> | Oh, right. |
| 18:45 | <gsnedders> | You mean for that, not for developing the browser. |
| 18:45 | <gsnedders> | veosotano: In reality, clients will pay less. |
| 18:45 | <Funcod> | oh gsnedders |
| 18:46 | <Funcod> | remember me from habari? |
| 18:46 | <gsnedders> | Funcod: Oh you. |
| 18:46 | <Funcod> | :) |
| 18:46 | <veosotano> | I beg to disagree |
| 18:46 | <gsnedders> | Funcod: Vaguely. |
| 18:46 | <gsnedders> | Funcod: It's been too long since I've been around there much. :P |
| 18:46 | <Funcod> | np mike told me you were involved with the w3 |
| 18:49 | <veosotano> | gsnedders: do you think current tools are really great? |
| 18:50 | <veosotano> | I mean I can understand if you believe that we will not succeed… but are you saying that there is no problem? |
| 18:50 | <gsnedders> | veosotano: No. Do I think we're slowly moving towards somewhere better with the WHATWG and others? Yes. |
| 18:50 | <gsnedders> | Do I think a monoculture is a solution? No. |
| 18:51 | <gsnedders> | I'd say a monoculture is actively far worse than what we have today. |
| 18:51 | <veosotano> | even if it is a non-proprietary one? |
| 18:51 | <gsnedders> | Yes. |
| 18:51 | <veosotano> | where the presence of bugs is managed? |
| 18:51 | <veosotano> | I'd agree that a monoculture of one of today's engines is bad |
| 18:52 | <gsnedders> | I don't think such a think *can* viably be managed. |
| 18:52 | <veosotano> | but I believe that there would be value in starting something new, something better, collaborating instead of fighting |
| 18:52 | <veosotano> | gsnedders: I think it can' as long as it's a monoculture :P |
| 18:53 | <veosotano> | (remove that ' ) |
| 18:53 | <veosotano> | I think it can |
| 18:53 | <gsnedders> | In reality, your biggest challenge will be getting it anywhere, and getting anything in way of users. |
| 18:53 | <veosotano> | I agree |
| 18:53 | <veosotano> | but I'm going to sell it to devs first |
| 18:53 | <veosotano> | and all of the people I've spoken to have agreed on that it would be a way better language |
| 18:54 | <gsnedders> | I'd say Linux practically has a monoculture on *nix-like operating systems. |
| 18:54 | <gsnedders> | I wouldn't say people follow the POSIX spec as a result. |
| 18:54 | <veosotano> | they follow the implementation |
| 18:54 | <veosotano> | that's what I argue |
| 18:54 | <veosotano> | there is no way to make people to follow a spec |
| 18:54 | <veosotano> | they will hack for the implementation |
| 18:54 | <veosotano> | it's just a fact |
| 18:54 | <gsnedders> | Agreed. |
| 18:55 | <veosotano> | that's why if there is *the* implementation |
| 18:55 | <veosotano> | it can be managed |
| 18:55 | <veosotano> | otherwise we would need to rely on spec |
| 18:55 | <gsnedders> | By making backwards incompatible changes to match the spec? |
| 18:55 | <veosotano> | with versioning it's possible |
| 18:55 | <gsnedders> | Even if major sites rely upon it? |
| 18:55 | <veosotano> | your new Photoshop can open older files just fine |
| 18:55 | <veosotano> | because it knows its version |
| 18:56 | <gsnedders> | Will you update the spec for the previous version to match the impl of the older version? |
| 18:56 | <veosotano> | update both things |
| 18:56 | <gsnedders> | Because the way *really* bad things start happening is when the two diverge. |
| 18:56 | <veosotano> | and provide backwards compatibility modules |
| 18:56 | <veosotano> | so that older documents are rendered as they were meant to |
| 18:56 | <veosotano> | by the older engine |
| 18:56 | <gsnedders> | And how do you stop that from becoming unmanagable with the number of bug-modes? |
| 18:57 | <veosotano> | well because I don't believe in infinite backwards compatibility |
| 18:57 | <veosotano> | I don't expect 1.0 versions to work with engine 25.0 |
| 18:57 | <Funcod> | gsnedders : you should our @support |
| 18:57 | <veosotano> | at some point support needs to be dropped |
| 18:57 | <Funcod> | it permits us to be futur proof whatever happens |
| 18:57 | <gsnedders> | Modern browsers *still* support stuff marked as obsolete in the very very first draft HTML specification. |
| 18:58 | <veosotano> | and I *still* don't know why |
| 18:58 | <gsnedders> | Because websites break, and users complain. |
| 18:58 | <Funcod> | because they are millions of legacy pages |
| 18:58 | <gsnedders> | Users want websites to work. |
| 18:58 | <veosotano> | people also want the web to move forward |
| 18:58 | <veosotano> | those two goals are exclusive |
| 18:59 | <Funcod> | yes but angry ppl pester loudly |
| 18:59 | <veosotano> | btw, as I said, we would render the older versions as they rendered when it came out |
| 18:59 | <gsnedders> | veosotano: Are they? I'd argue they aren't. Is HTML5 failing that horrifically at moving the web forward? Is CSS3 failing? |
| 18:59 | <veosotano> | only very very very old stuff would break |
| 18:59 | <veosotano> | I'd say it is |
| 18:59 | <veosotano> | why are native apps so much better? |
| 18:59 | <Funcod> | gsnedders : did you check the recent prefix mess? |
| 19:00 | <Funcod> | opera wanna use -webkit etc |
| 19:00 | <matzipan> | gsnedders: yeah, opera's use of -webkit is the latest and greatest fail of css3 |
| 19:00 | <gsnedders> | Funcod: That's one specific failing of the CSS WG. People were saying this would happen years ago. MS implemented WebKit prefixes years ago, and are talking about doing so again; likewise is Mozilla. |
| 19:01 | <Funcod> | (which was introduced by microsoft first) |
| 19:01 | <matzipan> | So not only there is a standard, but there is also something like a unwritten standard of -webkit |
| 19:01 | <Funcod> | ppl checking these properties with JS to detect vertain version of a browser |
| 19:01 | <Funcod> | will be really surprised |
| 19:02 | <Funcod> | *certain |
| 19:02 | <matzipan> | But CSS3 is still a fail. Seriously. What else is there apart for some rgba and transforms eyecandy? |
| 19:02 | <matzipan> | Is it really fixing the problems in CSS2? |
| 19:03 | <matzipan> | You can do your job just fine, agreed. But it isn't really what it should be like |
| 19:03 | <gsnedders> | matzipan: What do you see as the problems? |
| 19:03 | <Funcod> | I like CSS3 columns BUT they didn't implement break |
| 19:03 | <Funcod> | so it's partially good |
| 19:03 | <matzipan> | gsnedders: do you really want me to start this discussion?:D |
| 19:03 | <veosotano> | this could take a while :) |
| 19:04 | <gsnedders> | matzipan: No, I just want a short list to see in what ways CSS3 fails to address them. :) |
| 19:04 | <veosotano> | I'll give you 7 |
| 19:04 | <Funcod> | gsnedders : take wrapping |
| 19:04 | <gsnedders> | (I mean, I can think of plenty of issues with CSS 2.1, but that doesn't mean they're the same of what you think of. :)) |
| 19:04 | <Funcod> | you are going back and forth |
| 19:04 | <Funcod> | trying to hack your way to be backward compatible |
| 19:05 | <Funcod> | (text wrapping) |
| 19:05 | <veosotano> | the html is a mixture of structure, presentation and behavior |
| 19:05 | <matzipan> | veosotano: well, let's leave this for a while, and just talk about CSS3 |
| 19:05 | <veosotano> | I'd argue that's css's fault |
| 19:05 | <veosotano> | in HSS we will have structure tools |
| 19:06 | <veosotano> | and the behavior is called from the presentation layer |
| 19:06 | <gsnedders> | It's not really CSS's fault when CSS didn't exist when most presentational markup was added to HTML :) |
| 19:06 | <veosotano> | that doesn't make it good |
| 19:06 | <gsnedders> | No, it doesn't make it good. |
| 19:07 | <veosotano> | I know that most of the problems are legacy stuff |
| 19:07 | <matzipan> | gsnedders:so CSS fixes some problems.. but the base problem is still there. How are you supposed to do pure presentation stuff with CSS? |
| 19:07 | <veosotano> | that's exactly why we're proposing to start fresh |
| 19:08 | <Ms2ger> | document.replaceChild(document.createTextNode("text"), document.documentElement); |
| 19:08 | <Ms2ger> | Enjoy |
| 19:08 | <gsnedders> | Ms2ger: Go away. |
| 19:08 | <gsnedders> | Ms2ger: HierarchyError, no? |
| 19:08 | <Ms2ger> | In WebKit, yes |
| 19:09 | <matzipan> | that seems so nasty I'm not even going to run it |
| 19:09 | <Ms2ger> | In Gecko, document.childNodes == [doctype, text node] |
| 19:09 | <Funcod> | nothing nasty he's using a textNode |
| 19:09 | <Funcod> | that's unusual |
| 19:09 | <gsnedders> | Ms2ger: Can we please standardize WebKit's behaviour, then? |
| 19:09 | <Ms2ger> | In Opera? I dunno, DragonFly hates me |
| 19:09 | <Ms2ger> | gsnedders, lucky you, we already did :) |
| 19:10 | <gsnedders> | Who does Dragonfly not hate? |
| 19:10 | <Funcod> | Ms2ger : you are working on webkit? |
| 19:10 | <Funcod> | *are you |
| 19:10 | <Ms2ger> | I work on Gecko |
| 19:10 | <matzipan> | gsnedders: who uses it/ |
| 19:10 | <Funcod> | oh nvm then I had a bug for them |
| 19:11 | <gsnedders> | matzipan: The base problem being HTML has presentational stuff? Is that still an issue if you don't use it, and when it does exist, it's behaviour can entirely be described using CSS? |
| 19:11 | <veosotano> | with behavior you mean what it does or how it looks? |
| 19:11 | Philip` | finds it odd that http://axr.vg/about/features claims to be "Starting completely from scratch" but seems to end up as basically HTML+XML+CSS plus syntactic sugar |
| 19:12 | <Funcod> | there are lot of example of attempts of behaviour in CSS |
| 19:12 | <Funcod> | most failed |
| 19:12 | <matzipan> | Philip`: where did you see any html in axr? |
| 19:12 | <Ms2ger> | IE10 seems to match WebKit |
| 19:12 | <Ms2ger> | Phew |
| 19:12 | <Philip`> | If you're going to go through the pain of migrating the web to an incompatible new platform, surely you should make much more fundamental improvements to it |
| 19:12 | <veosotano> | Philip`: doesn't say trying to take good ideas from current standards? |
| 19:12 | <gsnedders> | veosotano: I mean its behavioural sffects on layout. |
| 19:12 | <gsnedders> | *affects |
| 19:12 | <Ms2ger> | effects? |
| 19:13 | <veosotano> | gsnedders: the problem is that they're not independent layers |
| 19:13 | <veosotano> | the document is deeply linked one to the other |
| 19:13 | <veosotano> | many techniques require adding html tags |
| 19:13 | <gsnedders> | Ms2ger: I will hate you so much soon. |
| 19:13 | <veosotano> | which is completely wrong in my view |
| 19:13 | <Ms2ger> | Soon? |
| 19:13 | <gsnedders> | Ms2ger: By "soon" I mean a year ago. |
| 19:14 | <Ms2ger> | Better :) |
| 19:14 | <Ms2ger> | Huh |
| 19:14 | <Ms2ger> | DragonFly is getting rather confused... |
| 19:14 | <veosotano> | Philip`: what would be those improvements? |
| 19:14 | <gsnedders> | veosotano: Without going for a full templating language, it's hard to avoid that issue. |
| 19:14 | <fflorent> | I have a naive question about CSS, that may be irrelevant, but why isn't there a prefix named "-experimental" for CSS 3 experimental feature, that every vendor would support? And the vendor prefixes are kept, for the case when the user (webmaster) finds differences between browser implementations. |
| 19:15 | <matzipan> | Philip`: well, it's not impossible, and if you start by saying "it's not going to work", where would we be now? |
| 19:15 | <fflorent> | so the problem with "-webkit" would disappear with time |
| 19:15 | <veosotano> | gsnedders: I think the tools in HSS do solve that issue |
| 19:15 | <veosotano> | it's not just like a preprocessor like SASS |
| 19:16 | <matzipan> | fflorent: every rule is made to be broken, we would end up with -webkit-experimental :P |
| 19:16 | <Philip`> | matzipan: The syntax in the examples looks different, but it still seems to use the same basic concepts of semantic documents and stylesheets etc, which don't seem like a natural fit for the web apps that everyone wants to do nowadays |
| 19:16 | <matzipan> | fflorent: there would still need stanradizing |
| 19:16 | <gsnedders> | Yeah, what matzipan said. |
| 19:17 | <Philip`> | (It seems hugely closer to HTML than to e.g. Flash) |
| 19:17 | <gsnedders> | X-* elsewhere in the web platform has the same problem. |
| 19:17 | <veosotano> | Philip`: isn't that a good thing? |
| 19:17 | <Philip`> | (Not saying that Flash is better, just that HTML surely can't be the only or best approach) |
| 19:17 | <fflorent> | matzipan: that is sad and dirty :( |
| 19:17 | <gsnedders> | Something that treated web apps, as, well, apps would likely be better. |
| 19:18 | <matzipan> | Philip`: the only similarity is see is that it uses a text file... that's the end of it |
| 19:18 | <Philip`> | I have no idea what would be better in practice - if I did then I'd try to build it :-) |
| 19:18 | <veosotano> | Philip`: our approach is to shift many things from the content to the presentational layer |
| 19:18 | <veosotano> | XML is just a thin data layer |
| 19:18 | <veosotano> | that provides semantics |
| 19:18 | <gsnedders> | XML provides no semantics. |
| 19:18 | <veosotano> | namespaces |
| 19:18 | <veosotano> | but not prefixes |
| 19:18 | <veosotano> | those are ugly |
| 19:18 | <veosotano> | default namespaces |
| 19:20 | <Ms2ger> | gsnedders, http://img857.imageshack.us/img857/4276/dragonfly2.png |
| 19:20 | <fflorent> | matzipan: why not setting such a solution now, so users migrate step by step to that convenient solution, and vendors avoid to implement "-webkit" prefix |
| 19:20 | <matzipan> | maybe axr is not going to get anywhere, but at least it's something to be noted... you should definetely be aware of it |
| 19:21 | <veosotano> | haha that sounds menacing :P |
| 19:21 | <veosotano> | what I want is better tools |
| 19:21 | <veosotano> | we are proposing an alternative |
| 19:21 | <veosotano> | not to replace the web |
| 19:21 | <veosotano> | but to augment it |
| 19:21 | <matzipan> | _proposing_ |
| 19:22 | <matzipan> | fflorent: i remember there being some different syntaxes on radial gradients and stuff |
| 19:22 | <gsnedders> | Ms2ger: Yes. So? |
| 19:22 | <veosotano> | I think it will benefit everyone, even if html/css get better as a result |
| 19:24 | <Ms2ger> | gsnedders, something you may care more about, Number.isNaN should be in the next Nightly |
| 19:24 | <Ms2ger> | Along with default arguments |
| 19:24 | <gsnedders> | Ms2ger: I don't much. |
| 19:24 | <gsnedders> | :P |
| 19:25 | <Ms2ger> | Do you care for ANYTHING? ;) |
| 19:25 | <gsnedders> | Not really. |
| 19:25 | <fflorent> | matzipan: yes, so we can have : #myid { -experimental-border-radius: /* most common syntax */; -aVendorPrefix-border-radius: /* specific syntax that override the previous property */; ... } |
| 19:26 | <Ms2ger> | -wd-2012-06-01-border-radius |
| 19:26 | <matzipan> | fflorent: oooooooook, so that would get even messier. |
| 19:27 | Ms2ger | goes and plays with DocumentFragments |
| 19:27 | <matzipan> | But, on the other side, axr proposes a nice way around that :P j/k |
| 19:28 | <Philip`> | Ms2ger: That's great until someone writes a blog post saying "To guarantee forward compatibility for your content for at least the next two years, write { -wd-2012-06-01-border-radius: ...; -wd-2012-06-02-border-radius: ...; [snip]; -wd-2014-01-01-border-radius: ... }" |
| 19:28 | <Ms2ger> | Philip`, pff, let's just make SASS to generate that |
| 19:28 | <Ms2ger> | s/to// |
| 19:29 | <matzipan> | writing bytecode by hand seems a lot nicer at the moment |
| 19:30 | Philip` | often sees people suggesting to use Opera-prefixed versions of features that Opera hasn't attempted to implement yet, like windows.oRequestAnimationFrame |
| 19:30 | <Ms2ger> | 'tis true |
| 19:30 | <Philip`> | s/s// |
| 19:30 | <fflorent> | matzipan: what is the axr proposition ? |
| 19:33 | <matzipan> | fflorent: it's a thing called a support object, we have it in mind, but i see it has not yet been written down : http://spec.axr.vg/specification.html#1.7.1 |
| 19:34 | <matzipan> | fflorent: if you want some further info maybe veosotano will take a moment and explain it on pm |
| 19:34 | <matzipan> | oh, there's a github discussion on that |
| 19:35 | <matzipan> | fflorent: pm'd you |
| 19:40 | <matzipan> | glad to talk to you guys, i hope this project will inspire you. if you don't mind i'm going to lurk around from now on |
| 19:40 | <fflorent> | matzipan: OK, I see. Thank you |
| 19:42 | <veosotano> | fflorent: what do you think about the @support solution? |
| 19:43 | <fflorent> | veosotano: as said in the github page : complex. But that is clean |
| 19:43 | <veosotano> | oh, you commented? :) |
| 19:45 | <fflorent> | veosotano: oh, not yet. Do you want me to comment ? |
| 19:45 | <veosotano> | no, I misunderstood you |
| 19:45 | <matzipan> | fflorent: we definetely need a lot of input on the project, tho |
| 19:45 | <veosotano> | which one is clean and which one not? |
| 19:48 | <veosotano> | fflorent: I hope you didn't get me wrong there, I more than welcome your feedback |
| 19:49 | <fflorent> | veosotano: well, I spoke generally. That is cleaner than having a server-side PHP script that generate each vendor prefix :) |
| 19:49 | <veosotano> | I agree :) |
| 19:52 | <fflorent> | veosotano: so, how would it work ? th |
| 19:52 | <veosotano> | what exactly? |
| 19:53 | <fflorent> | the browser execute the condition, and then the content inside the block is interpreted, anywhere the @support is put ? |
| 19:53 | <fflorent> | (I have not finished my sentence, sorry :s) |
| 19:53 | <fflorent> | s/have/did |
| 19:54 | <veosotano> | @support is a special object, which means it can be used inside a selector chain |
| 19:54 | <veosotano> | and in HSS something called property filters are written with ( ) after the simple selector |
| 19:54 | <veosotano> | so you do |
| 19:55 | <veosotano> | @support( <property> <operator> <valuetocheckagainst>) { } |
| 19:55 | <matzipan> | veosotano: i think he was asking if you can use it anywhere else outside a selector chain |
| 19:55 | <veosotano> | anything inside the block would be executed, yes |
| 19:56 | <fflorent> | matzipan: yes :) |
| 19:56 | <fflorent> | veosotano: ok |
| 19:56 | <veosotano> | I think it can't …. |
| 19:56 | <matzipan> | would this work? stuff { isA: button; @support(gradient) { do gradient background here} } |
| 19:56 | <veosotano> | it's sor of like a media query |
| 19:57 | <fflorent> | ah |
| 19:57 | <veosotano> | matzipan: not exactly like that, but yes |
| 19:57 | <veosotano> | in the general sense |
| 19:57 | <matzipan> | but how does it work? |
| 19:57 | <veosotano> | the support object maintains a list of values, which can be accessed by index just like an array |
| 19:58 | <veosotano> | that's for example with checks for object types |
| 19:58 | <matzipan> | @support.gradient = true then? |
| 19:58 | <veosotano> | oh |
| 19:58 | <veosotano> | the point to understand here |
| 19:58 | <veosotano> | is that the support object inherits the scope where it is in |
| 19:59 | <veosotano> | so what you select inside the block will select the same thing as outside, just conditionally |
| 19:59 | <matzipan> | that's intuitive, that's what i wrote earlier... but how would you rewrite my snippet to work? |
| 20:00 | <veosotano> | oh, that's the concrete syntax of the property filter |
| 20:00 | <veosotano> | so between the () you write the property name, and then you can use [ ] to access as an array |
| 20:00 | <veosotano> | so it would be |
| 20:01 | <veosotano> | @support(object["gradient"]) { @this{ background: myGradient } |
| 20:01 | <veosotano> | } |
| 20:01 | <veosotano> | because gradient is an index in the property "object" of the support object |
| 20:01 | <veosotano> | and if it returns true the property filter matches |
| 20:02 | <veosotano> | therefore executes what's inside |
| 20:02 | <matzipan> | that's ugly |
| 20:02 | <matzipan> | _and_ unintuitive |
| 20:02 | <veosotano> | we could also maybe make it apply the properties you define inside to the parent |
| 20:02 | <veosotano> | so you'd do |
| 20:02 | <veosotano> | @support(object["gradient"]) { background: myGradient } |
| 20:03 | <matzipan> | but i don't get it, why the objec[] thing |
| 20:04 | <veosotano> | oh because it follows regular property filter syntax |
| 20:04 | <matzipan> | i mean, surely you need some kind of namespacing |
| 20:04 | <matzipan> | but who is "object"? ... that is the question |
| 20:04 | <veosotano> | actually I think the example code in the github issue is not optimal |
| 20:04 | <veosotano> | I'd call it "objects" |
| 20:05 | <veosotano> | @support(objects[ etc |
| 20:05 | <matzipan> | i'd call it features |
| 20:05 | <veosotano> | but you can check for more things |
| 20:05 | <veosotano> | combinators |
| 20:05 | <veosotano> | filters |
| 20:06 | <veosotano> | instead of objects |
| 20:06 | <matzipan> | oh, now i get it |
| 20:06 | <veosotano> | well anyway, I don't want to flood the channel ;) |
| 20:06 | <matzipan> | i'd call it properties then |
| 20:06 | <fflorent> | +1 |
| 20:06 | <matzipan> | oh right, we should switch back |
| 20:06 | <veosotano> | :) |
| 20:06 | <matzipan> | sorry whatwg guys for spamming |
| 20:06 | <veosotano> | sorry guys |
| 20:08 | <veosotano> | but fflorent, did you get the idea? |
| 20:08 | <fflorent> | veosotano: yes, I think |
| 20:08 | <matzipan> | maybe this will make it in css4 :D |
| 20:08 | <veosotano> | would you agree it is better than the prefixes? |
| 20:09 | <matzipan> | veosotano: well, that's because hss is fundamentally different. you can't just mix @support in CSS. it doesn't make sense |
| 20:09 | <matzipan> | oh wait. media queries.. |
| 20:09 | <veosotano> | right |
| 20:10 | <veosotano> | I think there even is something like that in css |
| 20:10 | <veosotano> | or was it in JS? |
| 20:10 | <fflorent> | veosotano: there are people that use CSS3, and are not technically brilliant. I think it would be interesting to have their opinion. |
| 20:10 | <fflorent> | what do you think ? :p |
| 20:10 | <matzipan> | veosotano: isn't that modernizr? :P |
| 20:10 | <veosotano> | but browsers didn't report accurately what they supported |
| 20:10 | <veosotano> | so people never ended up using it |
| 20:12 | <veosotano> | but I can't remember how it was called :( |
| 23:41 | <padenot> | 2 |
