| 00:16 | <bga_> | heh |
| 00:16 | <bga_> | setImmediate |
| 00:17 | <heycam> | I am not a fan of the name |
| 00:17 | <bga_> | its just setTimeout with 0 |
| 00:17 | <bga_> | but with new name! |
| 00:23 | <gsnedders> | Also a lot of the reasons for it being proposed aren't true in Opera (like scripts entirely blocking the UI). |
| 00:28 | <bga_> | hehe in Opera even iframes are multithreaded |
| 00:28 | <gsnedders> | bga_: They're not real threads, though. |
| 00:29 | <bga_> | i know |
| 00:30 | <bga_> | but scripts in 10 iframes works parrallel and shared access to parent dom is ok |
| 05:58 | <zcorpan> | will somebody resurrect logs? |
| 08:17 | <zcorpan> | othermaciej: <http://www.w3.org/mid/E1Qc8p0-0003pB-5h⊙jwo>; seems PriorityRequest isn't working as intended |
| 08:18 | <othermaciej> | zcorpan: I can remind him of the right thing to do, but probably in the morning |
| 08:23 | <annevk> | whoa still connected |
| 08:44 | <annevk> | Ms2ger, https://bitbucket.org/ms2ger/anolis/src/720bb976fe83/setup.py says 1.1 |
| 08:45 | <annevk> | Ms2ger, ... |
| 08:45 | <annevk> | oh wait |
| 08:45 | <annevk> | you will never read that |
| 08:45 | <annevk> | fricking logs |
| 08:45 | <annevk> | but the fuck |
| 08:45 | <annevk> | it does say 1.2pre |
| 08:46 | <annevk> | holy shit it works |
| 08:55 | <krijn> | :( |
| 09:08 | <zcorpan> | krijn: so wassup with the logs? |
| 09:10 | <annevk> | zcorpan, network cable |
| 09:10 | <annevk> | zcorpan, will be looked at Saturday hopefully |
| 09:10 | <zcorpan> | k |
| 09:10 | <zcorpan> | well i'll be on vacation so as long as it's fixed in august! |
| 09:11 | <annevk> | have fun |
| 09:11 | <zcorpan> | will do |
| 09:11 | <annevk> | gonna go for a month? |
| 09:12 | <zcorpan> | yeah |
| 09:13 | <zcorpan> | i expect html5 to be finished when i get back |
| 09:19 | <annevk> | sounds reasonable |
| 09:29 | <bga_> | annoying bug in chromium. Need press enter twice everywhere :/ |
| 11:37 | <annevk> | shouldn't exceptions be solved before going to Last Call? |
| 11:37 | <annevk> | heycam|away, ^^ |
| 11:55 | <annevk> | how do I make hg commit ignore a certain file? |
| 11:56 | <Ms2ger> | hg commit -X? |
| 11:57 | <Philip`> | "hg commit f1 f2 f4 f5" where f3 is the file you want to ignore? |
| 11:57 | <Ms2ger> | Or add it to .hgignore if you always want to ignore it |
| 11:57 | <Philip`> | I thought .hgignore only makes it ignored from the perspective of 'hg add', not 'hg commit' |
| 11:58 | <annevk> | check this out: https://bitbucket.org/ms2ger/dom-core/changeset/816f0c664329 |
| 11:59 | <Ms2ger> | ! |
| 12:00 | <Ms2ger> | I guess I'd better fix that dom-core |
| 12:00 | Philip` | would like it if Bitbucket didn't have to load a hundred .css and .js files before rendering the page |
| 12:03 | <Ms2ger> | Fixed |
| 13:40 | <annevk> | ooh |
| 13:40 | <annevk> | roc has a post about permissions |
| 13:41 | <roc> | I hope you agree with it |
| 13:41 | <roc> | if you don't, I'll probably want to change it so you do :-) |
| 13:42 | <annevk> | http://www.w3.org/TR/css3-ruby/#display XHTMLMOD o_O |
| 13:42 | <annevk> | gonna read it now roc :) |
| 13:47 | <annevk> | roc, looks great; really glad you sometimes post these higher-level architectural views on the platform besides what goes on with respect to details of layout and video and whatnot :) |
| 13:50 | <roc> | thanks |
| 14:04 | <annevk> | Ms2ger, so anolis currently is at /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/anolis; is there a way I can make an alias for that so that the Makefile just works? |
| 14:04 | <Ms2ger> | Maybe a symlink from /usr/bin/anolis or some such? |
| 14:10 | <annevk> | good idea |
| 14:17 | <annevk> | oh, roc, this is you: http://twitter.com/#!/rocallahan ? |
| 14:17 | <roc> | yes |
| 14:17 | <roc> | but I have never tweeted |
| 14:18 | <Ms2ger> | Oh, I'm in good company :) |
| 14:20 | <annevk> | haha |
| 14:29 | <karlcow> | http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html |
| 14:29 | <annevk> | @WHATWG has almost five thousand people following |
| 14:30 | <annevk> | five thousand people following SVN changes to the HTML spec |
| 14:31 | <hsivonen> | annevk: and occasional blog post announcements |
| 14:32 | <Philip`> | Does "following" imply more than letting the updates drift past their eyeballs without reading? |
| 14:32 | <Ms2ger> | No |
| 14:33 | <hsivonen> | sigh. the following is now marked as an a11y and a11y_canvas bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13096 |
| 14:33 | <hsivonen> | really? |
| 14:33 | <karlcow> | I follow @whatwg but I'm not reading it. |
| 14:33 | <karlcow> | followers number is meaningless |
| 14:33 | <hsivonen> | isn't that just asking for some API sugar for a special case? |
| 14:33 | <hsivonen> | karlcow: like version numbers |
| 14:33 | <karlcow> | mwahaha |
| 14:33 | <Ms2ger> | a11y is a meaningless keyword, aaik |
| 14:33 | <karlcow> | troll |
| 14:33 | <Ms2ger> | +f |
| 14:34 | karlcow | says hsivonen has spent too much time here. He was a lot less trollish 4 years ago :) Just plain direct. |
| 14:35 | <Philip`> | hsivonen: Sounds like the aim is to be an optimisation for a special case, more than API sugar |
| 14:35 | <hsivonen> | karlcow: you have an interesting view of what's trollish |
| 14:35 | <karlcow> | hsivonen: not only for trollish ;) |
| 14:36 | <Philip`> | (A likely very minor optimisation for a likely very rare special case, with no attempt at measuring whether the current performance is a problem or how much the optimisation could help) |
| 14:36 | <annevk> | perchance it's karlcow that changed? |
| 14:36 | <annevk> | calling me an idiot, hsivonen a troll |
| 14:36 | <annevk> | you never did that before |
| 14:36 | <karlcow> | still the same not understandable dreamer |
| 14:36 | <karlcow> | tss tss |
| 14:37 | <karlcow> | annevk: I said what you said was stupid. not that you were an idiot. |
| 14:38 | <karlcow> | I still think it was stupid, and I still think you are not an idiot, specifically because I tend to ignore completely idiot people |
| 14:39 | <hsivonen> | roc++ for speaking against the Android permission model on a planet.mozilla.org-syndicated post |
| 14:43 | zcorpan | is becoming increasingly disinterested in reading emails involving "canvas" and "accessibility" |
| 14:43 | <hsivonen> | roc: another thing that bothers me about both the Chrome and the Mozilla app manifests is the ability to have a path prefix for an app instead of requiring sites to mint a hostname per app |
| 14:44 | <roc> | say so |
| 14:44 | <hsivonen> | roc: trying to add path-based security to complex runtimes that are built with origin-based security in mind won't end well |
| 14:44 | <roc> | I haven't really followed it |
| 14:44 | <roc> | I agree |
| 14:44 | <hsivonen> | roc: what would be the right place to say so? I still have no clue where app manifest discussion is supposed to happen |
| 14:45 | <roc> | email the people and ask them |
| 14:45 | <hsivonen> | roc: ok |
| 14:45 | <Ms2ger> | zcorpan, are you suggesting you were interested before? |
| 14:46 | <zcorpan> | Ms2ger: no |
| 14:46 | <karlcow> | >Someone should do a study where they promote a simple game app which requests absurdly overbroad permissions, and see how many users download the game but reject it at the permissions screen. |
| 14:46 | <karlcow> | from http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html |
| 14:46 | <zcorpan> | Ms2ger: at first i was neutral to the subject and it went downhill from there |
| 14:46 | <Ms2ger> | I see |
| 14:46 | <Ms2ger> | I'm afraid I've never really been neutral |
| 14:47 | <karlcow> | hmm in fact I have the feeling that most people do not care. :( That is the sad part for having seen it people giving all their private information for a stupid contest marketing game with the likehood of winning the game sponsor baseball cap… I think it was a car brand. |
| 14:51 | <annevk> | hsivonen, you could start by a blog post |
| 14:52 | <annevk> | hsivonen, your last one reached a lot of people |
| 14:52 | <annevk> | this post from roc does too |
| 14:52 | <annevk> | blogging works reasonable well I think for arguing larger points |
| 14:53 | <karlcow> | roc: in the "Permissions In Context", do you include the case of the one-time permission. For example location, for this precise time I accept to share my location, but not the next time. |
| 14:53 | <karlcow> | or permission for a while, for the next hour you can access my location but not after |
| 14:53 | <karlcow> | or the opposite silencing a feature for a little bit. |
| 14:53 | <roc> | that's sort of orthogonal |
| 14:54 | <roc> | obviously if you require up-front permissions, you can't support that at all |
| 14:54 | <karlcow> | For example apps which cut the sound automagically when a video chat is coming |
| 14:54 | <karlcow> | ah ok, just talking about upfront |
| 14:54 | <roc> | if you support permission-on-demand, as I'm advocating, then user-agents can support that |
| 14:55 | <roc> | however |
| 14:55 | <roc> | *revoking* permissions is a bit hard; if you want to support revoking permissions while the app is running, that's a lot harder to handle robustly |
| 14:56 | <hsivonen> | hmm. maybe my path-based security concern has been resolved already |
| 14:56 | <roc> | cutting sound isn't really a permissions issue |
| 14:56 | <hsivonen> | the Chrome and Mozilla manifest drafts are really similar |
| 14:56 | <hsivonen> | it's a shame if Web authors end up having to write two isomorphic manifests with trivial name substitutions for fields |
| 14:57 | <hsivonen> | (of more than 2) |
| 14:58 | <Ms2ger> | Better than two non-isomorphic manifests, I guess |
| 15:02 | <karlcow> | "you don't want a site you sometimes use for teleconferencing to always be able to listen to you." :) I remember an experiment from a phone/device? vendor (not sure which one anymore) where people had volunteered for leaving the mic opened and the phone was adjusting its behavior depending on the sound environment |
| 15:05 | <karlcow> | not the same thing, but similar experiment of contextual settings based on monitoring your environment http://wi.hexagram.ca/?p=68 |
| 15:08 | <hsivonen> | roc: fwiw, I sent email about paths to a couple of people working on Web apps, though it seems to me it's a solved problem already |
| 15:08 | <roc> | good |
| 15:13 | <annevk> | sweet |
| 15:13 | <annevk> | WebKit implemented mutation events in a different way from Gecko |
| 15:13 | <hsivonen> | annevk: intentionally or unintentionally? |
| 15:13 | <annevk> | that means we can at least make some simplifications |
| 15:14 | <hsivonen> | annevk: what about Opera and IE9? |
| 15:14 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1381.html |
| 15:14 | <annevk> | hsivonen, no idea, have not played with them yet |
| 15:14 | <annevk> | I am still hoping they can be removed as smaug wants |
| 15:15 | <hsivonen> | mutation events are unhappiness |
| 15:15 | <richardschwerdtf> | q+ |
| 15:15 | <hsivonen> | richardschwerdtf: wrong window? |
| 15:15 | <richardschwerdtf> | thanks henri |
| 16:03 | <karlcow> | mutation events sound like manic depressive |
| 16:06 | <karlcow> | http://www.bonkersworld.net/2011/06/27/organizational-charts/ |
| 16:13 | <annevk> | haha nice |
| 16:17 | <annevk> | sweet |
| 16:17 | <annevk> | it seems I don't have to pay to visit the states as I renewed just in time |
| 16:18 | <annevk> | I'm good until March 2012 |
| 16:18 | <annevk> | (still a silly system though) |
| 16:18 | <_bga> | lol i can finally post binary data w/o utf-8 convert :P |
| 16:18 | <_bga> | <form accept-charset="cp866" target='myframe'> |
| 16:19 | <_bga> | and convert binary data to cp866 |
| 16:19 | <_bga> | but still can not send \x00 |
| 16:22 | <Philip`> | That sounds mildly insane |
| 16:22 | <Philip`> | Is cp866 supported everywhere? |
| 16:23 | <Philip`> | Can't you just use application/x-www-form-urlencoded? |
| 16:23 | <_bga> | i dont want send triple size data |
| 16:24 | <_bga> | i dont know about how widely cp866 is supported |
| 16:25 | <_bga> | i hope - everywhere, else i will choose anotheк charset w/ 0-255 |
| 16:52 | <annevk> | http://lists.w3.org/Archives/Public/public-web-notification/2011Jun/0000.html |
| 16:53 | <annevk> | http://www.w3.org/TR/notifications/ still has the "problem" of depending on http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html but I am not sure how to avoid that |
| 17:01 | <Hixie> | annevk: why would you create a notification but not show it? |
| 17:02 | <Hixie> | annevk: also, an example suggests that notifications timing out should be done from script. That's bad for accessibility, where you don't want things timing out automatically since people with slower ability to consume content (e.g. because the screen reader hasn't gotten to it yet) will miss notifications. |
| 17:03 | <Hixie> | annevk: better imho to have a way to say whether a notification is ephemeral or should be kept until acknowledged, then let the OS decide what the former's timeout is |
| 17:03 | <Hixie> | annevk: (of course you still need .cancel(), but it would be only for when the notification is no longer useful, not for a timeout) |
| 17:04 | <Hixie> | annevk: as currently specced, it seems a notification can only be used once ("must be invoked after the "show" event" e.g. implies there's only ever one show event), which doesn't make sense if you do keep show() rather than changing it to autoshow the notification when it is created |
| 17:05 | <Hixie> | annevk: the API is defined in terms of event listeners being called, not in terms of events firing |
| 17:06 | <Hixie> | annevk: 'show' is defined to fire "at the point when the notification actually becomes visible to the user" which seems to contradict the next statement "the notification will never become visible before this event is dispatched" |
| 17:07 | <Hixie> | annevk: the spec should be rephrased in terms of a processing model, right now it's ambiguous in various ways: e.g. what happens if you change replaceId after calling show() to something that conflicts with an existing notification? |
| 17:07 | <Hixie> | annevk: not clear what "The dir attribute of the Notification interface has has all the properties of the dir attribute as defined in [HTML5]" means... does it mean it's a content attribute, e.g.? |
| 17:08 | <Hixie> | annevk: i recommend making that just self-defined instead of referring to the HTML spec |
| 17:08 | <Hixie> | annevk: "may ignore any markup in this string" doesn't make any sense. If I have a notification whose body is "Go to meeting about the <video> element", what should the notification say? |
| 17:09 | <Hixie> | annevk: oh, hm, there are processing models. They seem to conflict with other parts of the spec. |
| 17:10 | <Hixie> | annevk: is there somewhere to file bugs? there's no feedback form on the spec. I can send e-mail if you like. |
| 17:23 | <othermaciej> | Hixie: have you been in the loop on this components thing that dglazkov et al are working on? |
| 17:23 | <Hixie> | only vaguely |
| 17:23 | <TabAtkins> | othermaciej: I'm in the loop if you have questions. |
| 17:24 | <othermaciej> | it's not clear to me why they decided to throw out XBL2 entirely and start with something only tangentially related and which is obviously deficient in many ways |
| 17:24 | <Hixie> | is there a page documenting the use cases yet? that's the main feedback i've been giving |
| 17:24 | <TabAtkins> | I think Alex and Dimitri's last posts answered that. |
| 17:24 | <TabAtkins> | Hixie: Yes, there's been one for months. |
| 17:24 | <Hixie> | url? |
| 17:24 | <othermaciej> | there is a page that lists use cases, but nothing that relates their proposal to the use cases |
| 17:25 | <TabAtkins> | Hixie: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases |
| 17:25 | <othermaciej> | (nor anything that explains why XBL2 would fail to meet them for that matter) |
| 17:25 | <Hixie> | TabAtkins: i meant, the use cases that are intended to be addressed by the proposal |
| 17:25 | <othermaciej> | in fact the proposal rather obviously fails to meet some of the listed use cases |
| 17:25 | <Hixie> | TabAtkins: also, those are not use cases |
| 17:26 | <Hixie> | TabAtkins: they are mostly design constraints |
| 17:26 | <Hixie> | TabAtkins: (aka requirements) |
| 17:26 | <TabAtkins> | Hixie: You're mostly right. The major use-case is represented by the widgets that every major UI library provides. |
| 17:26 | <slightlyoff> | I'm really warry of trying to cram an XBL2-shaped thing through an arbitrary use-case hole |
| 17:26 | <othermaciej> | in fact, since the proposed API can't bind controls, it fails to meet almost all of those use cases |
| 17:26 | <slightlyoff> | since most of the problems aren't "binding" related |
| 17:26 | <slightlyoff> | they're "is-a" relationship related |
| 17:27 | <slightlyoff> | and binding in the XBL sense only tangentially meets that, with really high conceptual overhead to boot |
| 17:27 | <Hixie> | TabAtkins: if the main use case is just widgets, xbl2, or something in the recent xbl2-adapted-for-html direction, seems sufficient |
| 17:27 | <slightlyoff> | but I'll address that in the public-webapps thread |
| 17:28 | <Hixie> | TabAtkins: (and has the advantage of being directly based on xbl used in mozilla for exactly that purpose for over a decade now) |
| 17:28 | <TabAtkins> | I defer to slightlyoff. |
| 17:28 | <TabAtkins> | And his emails. |
| 17:28 | <othermaciej> | from reading the use case page, it seems like almost none of them are met by the proposal |
| 17:28 | <Hixie> | slightlyoff: clearly nothing should be based on arbitrary use cases, but it's critical to good language design to know what problem one is solving before solving it |
| 17:29 | <Hixie> | slightlyoff: after all, how else can one evaluate one's proposal? |
| 17:29 | <TabAtkins> | slightlyoff: The post you made to webkit-dev is very good and should be sent to public-webapps. |
| 17:29 | <othermaciej> | I feel like what's happened is a list of use cases was presented, then a proposal was made that bears no obvious relationship to the list |
| 17:29 | Hixie | is still looking for use cases, rather than requirements |
| 17:29 | <dglazkov> | Hello folks! |
| 17:29 | <slightlyoff> | hey dglazkov |
| 17:29 | <Hixie> | hey dglazkov! |
| 17:30 | <slightlyoff> | othermaciej and Hixie are looking for use-cases |
| 17:30 | <othermaciej> | that's assuming we even accept those as use cases |
| 17:30 | <othermaciej> | I'm willing to provisionally accept them, whether you call them use cases or requirements |
| 17:30 | <slightlyoff> | so let me step back |
| 17:30 | <slightlyoff> | and present things like this: |
| 17:30 | <othermaciej> | what I'd like to see is an explanation of which ones the propose is intended to satisfy, and how it does so |
| 17:30 | <slightlyoff> | there is a series of problems that we *might* hve |
| 17:30 | <slightlyoff> | have |
| 17:30 | <othermaciej> | because it seems to meet almost none of these requirements |
| 17:30 | <slightlyoff> | and a set of problems that real web developers *do* have |
| 17:30 | <slightlyoff> | and they're paying dearly to get them solved |
| 17:31 | <slightlyoff> | mostly in the form of latency and complexity |
| 17:31 | <slightlyoff> | so clearly, they're valuable |
| 17:31 | <slightlyoff> | I have no interest in solving problems we might have |
| 17:31 | <slightlyoff> | only the ones we demonstrably do |
| 17:31 | <slightlyoff> | disagree? Ok, but those are my biases |
| 17:31 | <Hixie> | we should most definitely first address real problems, yes |
| 17:32 | <slightlyoff> | I also submit that we should be paying attention to the layering properties of the system |
| 17:32 | <slightlyoff> | as othermaciej is clearly pointing out |
| 17:32 | <othermaciej> | I think it would be more fruitful to discuss the specific list of those problems, ideally in the form of concrete use cases |
| 17:32 | <Hixie> | yeah |
| 17:32 | <slightlyoff> | so let me try to list them here quickly, and I can expand on-list in a bit |
| 17:32 | <othermaciej> | I see a lot of people saying that they care about the set of problems faced by "real web developers" but no clear statement of what those are, or what other kinds of problems are out of scope |
| 17:33 | <othermaciej> | put it in a wiki page ideally |
| 17:33 | <othermaciej> | it needs to be recorded persistently |
| 17:33 | <slightlyoff> | I can do that |
| 17:33 | <othermaciej> | apparently the page at http://wiki.whatwg.org/wiki/Component_Model_Use_Cases is not it |
| 17:34 | <slightlyoff> | 1.) custom UI control development |
| 17:34 | <othermaciej> | dglazkov: I sent you a reply about encapsulation but I can see I'll have to post more about this on public-webapps |
| 17:34 | <slightlyoff> | preferably with a view, constructed in HTML, CSS, and DOM that doesn't bleed through into the "visible" DOM |
| 17:35 | <slightlyoff> | 2.) declarative composition of custom controls with HTML markup |
| 17:35 | <slightlyoff> | 3.) secure "view" construction for built-in or security-sensitive controls |
| 17:36 | <slightlyoff> | #1 is the primary use-case, though |
| 17:36 | <othermaciej> | 2 and 3 are clearly failed by the current proposal |
| 17:36 | <othermaciej> | 1, it's hard to tell without more detail |
| 17:36 | <slightlyoff> | #3 can be accomidated with minor tweaks |
| 17:36 | <slightlyoff> | as for #2, what we've presented so far isn't complete |
| 17:37 | <othermaciej> | ah, We'll Add Security Later(tm) |
| 17:37 | <slightlyoff> | there's a "document.registerTag()" we haven't proposed yet |
| 17:37 | <slightlyoff> | no |
| 17:37 | <slightlyoff> | it's just part of the Element lifecycle |
| 17:37 | <slightlyoff> | and that isn't explained in the IDL |
| 17:37 | <dglazkov> | slightlyoff: he left |
| 17:37 | <slightlyoff> | (another reason that IDL blows for all of this) |
| 17:38 | <dglazkov> | I think there's a disconnect about iterative approach |
| 17:38 | <dglazkov> | including doubts on whether it's possible |
| 17:44 | <dglazkov> | hey othermaciej! welcome back |
| 17:45 | <slightlyoff> | othermaciej: as I was saying, we hope to explain the properties you're looking for based on describing the lifecycle of Elements and their subclasses |
| 17:45 | <Hixie> | if the problem we're solving is just making custom widgets, then why isn't xbl2 sufficient? |
| 17:45 | <slightlyoff> | such that you get a chance in the context of "new MyElementType" to either tack the shadow onto the public side of the object, or not, holding it inside closures and squirreling it away for private use |
| 17:46 | <othermaciej> | all I'm really looking for is: |
| 17:46 | <othermaciej> | - list of use cases, ideally backed up with very concrete examples, not just vague high-level statements |
| 17:46 | <othermaciej> | - explanation of which use cases the proposal even intends to address, and which will possibly be addressed later |
| 17:46 | <slightlyoff> | happy to produce that |
| 17:46 | <othermaciej> | - explanation of how the proposal satisfies the use cases it is intended to address |
| 17:46 | <othermaciej> | it's hard to even have a conversation without these things |
| 17:47 | <slightlyoff> | OK |
| 17:47 | <othermaciej> | I mean, I can't even really argue with the current use case list on the whatwg wiki, but I don't know how to use it to discuss the proposal |
| 17:47 | <slightlyoff> | I would like to ask for some forebearance in NOT describing possible solutions in IDL, though |
| 17:48 | <slightlyoff> | it's jaundices the conversation |
| 17:49 | <othermaciej> | dglazkov started it |
| 17:49 | <slightlyoff> | heh |
| 17:49 | <slightlyoff> | OK |
| 17:49 | <othermaciej> | and when I objected to his proposal-in-the-form-of-IDL, he asked me to propose a concrete alternative |
| 17:50 | <othermaciej> | I will note that I am in no way wedded to what I proposed, I think it still fails to provide many important things, such as defining components declaratively, binding components declaratively, and multiple bindings |
| 17:50 | <othermaciej> | but it at least shows (I hope) that the encapsulation problem is easy to solve without adding significant complexity |
| 17:51 | <slightlyoff> | yes, I think encapsulation is both important and tractable, but I don't agree that the strong form of it is going to be the common case |
| 17:51 | <dglazkov> | othermaciej: sent a respoonse. |
| 17:51 | <slightlyoff> | anyhow, something to debate once we have a shorter, more concrete use-case doc |
| 17:52 | <dglazkov> | slightlyoff: let's use the current use cases page. We shouldn't have more than one |
| 17:52 | <slightlyoff> | alrighty |
| 17:52 | <slightlyoff> | will slash/burn |
| 17:52 | <dglazkov> | slightlyoff: sure thing :) |
| 17:53 | <Hixie> | the widl checker is now telling me "Interface HTMLAllCollection is defined as a caller operation, but caller should be reserved to specify legacy APIs" |
| 17:53 | <Hixie> | man if HTMLAllCollection doesn't count as a legacy API, I dunno what would |
| 17:54 | <othermaciej> | dglazkov: I'm disappointed that you did not address the benefits I listed for my proposal |
| 17:55 | <othermaciej> | and dismissed it with handwaving about "we need to compose from smaller parts" when it's actually only trivially more complex than your proposal, and arguably no more complex than your "add a boolean flag" proposal |
| 17:55 | <dglazkov> | othermaciej: I didn't dismiss your proposal! I don't hate it. It's pretty much (aside from multiple bindings) the same thing I came up with |
| 17:56 | <slightlyoff> | ok, have to run to another thing. Will post use-cases and a response to othermaciej's post soon-ish |
| 17:57 | <othermaciej> | dglazkov: did you read my list of stated benefits relative to your proposal? do you think it is false? |
| 17:57 | <othermaciej> | I don't feel like "we considered something like this before and rejected it" really addresses those points |
| 17:58 | <dglazkov> | othermaciej: yep, I did. Let me expand in a response. |
| 17:59 | <othermaciej> | I feel like those benefits are a lot more specific than "compose from small pieces", in fact I think my proposal splits into smaller pieces by separating the act of creating a component from the act of binding |
| 18:00 | <dglazkov> | othermaciej: right -- and mine goes for an even smaller chunk -- there's no notion of component yet |
| 18:01 | <dglazkov> | othermaciej: I guess what I am saying is that your proposal (aside from multiple bindings) is simply a superset of mine. |
| 18:01 | <dglazkov> | othermaciej: and we're only arguing on whether to land it incrementally or altogether |
| 18:01 | <othermaciej> | it's actually not a superset |
| 18:02 | <dglazkov> | oh? |
| 18:02 | <othermaciej> | it includes some common elements (deliberately because I tried to make it as similar as possible) |
| 18:02 | <othermaciej> | but it separates the act of creating a component from the act of binding an instance of it to an element |
| 18:02 | <othermaciej> | in yours, these are both served by "just poke directly at the shadow DOM" |
| 18:02 | <dglazkov> | othermaciej: that's because it's the underlying machinery |
| 18:02 | <othermaciej> | my proposal is deliberately higher level and omits the ability to poke directly at the shadow DOM |
| 18:03 | <othermaciej> | yes, my proposal is to not expose that underlying machinery directly |
| 18:04 | <dglazkov> | othermaciej: you still expose it, just not allow access to it once a component is bound |
| 18:04 | <othermaciej> | I am in a meeting now so can't talk further |
| 18:04 | <dglazkov> | no worries. I'll respond in an email |
| 18:04 | <othermaciej> | but I also feel like we are talking past each other and this conversation is quite possibly fruitless |
| 18:09 | <dglazkov> | othermaciej: I hope not! I am grateful that we have this discussion and have all intentions of reaching consensus. |
| 18:11 | smaug____ | hasn't yet understood quite understood the reason for shadow DOM (if XBL2 is supported) |
| 18:11 | <smaug____> | -understood |
| 18:37 | <jamesr> | smaug____: in a world where XBL2 is supported, perhaps. we aren't in such a world |
| 18:38 | <Hixie> | right now nothing's supported :-)\ |
| 18:42 | <dglazkov> | smaug____: shadow DOM is part of XBL2 |
| 18:45 | <smaug____> | dglazkov: yeah |
| 18:46 | <smaug____> | but IIRC, XBL2 doesn't expose it in the same way to outside |
| 19:17 | <matjas> | annevk: what’s the expected behavior when the user triple-clicks “lolwut” in this example? <p>foo<i contenteditable>lolwut</i> |
| 19:17 | <matjas> | WebKit and IE seem to select only the editable text (which is what I would expect), but Opera and Fx select the entire paragraph |
| 19:18 | <matjas> | (Asking because of https://bugzilla.mozilla.org/show_bug.cgi?id=389348#c3) |
| 19:18 | <jcranmer> | Time for today's funnies: |
| 19:19 | <jcranmer> | "The problem is that not all browsers support HTML5. Why? Because it is not finalized yet." |
| 19:19 | <AryehGregor> | matjas, IIRC, some browsers don't allow a single user-created selection to be partially within contenteditable and partially outside. |
| 19:19 | <AryehGregor> | Just like you can't have a selection partly in a textarea and partly outside. |
| 19:19 | <AryehGregor> | It's something I've thought about maybe speccing. |
| 19:20 | <matjas> | AryehGregor: so currently the spec doesn’t say anything about this? |
| 19:20 | <AryehGregor> | It would actually simplify things if I could assume that a selection must be either wholly editable or not. But it doesn't have huge interop implications, so maybe it doesn't need to happen. |
| 19:20 | <AryehGregor> | No. |
| 19:20 | <AryehGregor> | UAs can make whatever selections they want. |
| 19:20 | <matjas> | The WebKit/IE behavior definitely feels the most natural to me |
| 19:29 | <AryehGregor> | It's also not obvious to the user what happens if they have some editable text selected and some non-editable text, and they hit delete or such. |
| 19:29 | <AryehGregor> | IIRC, I've specced that the non-editable part of the selection is ignored, so it's the same as if you just didn't select that part, but some browsers will refuse to do the delete. |
| 19:33 | <zewt> | sure is neat that gmail is now going WARNING WARNING PHISHING for random legit emails |
| 19:33 | <zewt> | nothing like false positives to train users to ignore warnings |
| 19:34 | <zewt> | This message may not have been sent by: timeless⊙gc |
| 19:38 | <zewt> | heh, i wonder if gmail deliberately opens mails on mousedown instead of click to make it seem more responsive |
| 19:38 | <zewt> | that's a little dumb, but it'd make sense to start prefetching on mousedown |
| 19:43 | <TabAtkins> | Some product starts prefetching entire websites on mouseover, because most people hover over links between .2s and .5s, minimum, which is a significant chunk of most site's loading times. |
| 19:43 | <zewt> | that's pretty ugly; I tend to hover over things when skimming, not just when I'm going to click |
| 19:43 | <TabAtkins> | That just means you'll burn a little extra processor power, is all. |
| 19:43 | <TabAtkins> | And since you're *not* navigating at the time, just reading, that's mostly wasted power anyway. |
| 19:44 | <zewt> | the animated/glowy "+1" nonsense on google search is driving me insane, since it causes constant glowing in my peripheral vision every time I read search results |
| 19:44 | <The_8472> | then... apply a userstyle! |
| 19:44 | <zewt> | and have to change it every time the css obfuscation changes? lots of fun |
| 19:45 | <The_8472> | use blunt tools |
| 19:45 | <zewt> | can't even block the image itself, since it's part of a big sprite table |
| 19:45 | <_bga> | zewt just enable "Hight Contrast B/W" in opera :P |
| 19:46 | <zewt> | i used opera ... once upon a time :P |
| 19:46 | <The_8472> | btw, what +1 thing are you talking about? |
| 19:46 | <AryehGregor> | TabAtkins, you're wasting network usage here, not just CPU power. Wasting network usage is a problem because it hurts other people. |
| 19:47 | <The_8472> | because i don't have it my google results |
| 19:47 | <TabAtkins> | AryehGregor: Slightly, yes. |
| 19:47 | <zewt> | the: http://i.imgur.com/1nfZR.png |
| 19:48 | <_bga> | zewt btw * { transition: none } in userstyle will solve problem |
| 19:48 | <The_8472> | <The_8472> use blunt tools <- |
| 19:48 | <_bga> | or blocking one js script |
| 19:48 | <zewt> | google scripts aren't exactly easy to block, heh |
| 19:49 | <zewt> | short of blocking everything, of course |
| 19:51 | <zewt> | fyi, it's a plain javascript animation, not a CSS transition |
| 19:55 | <_bga> | zewt js is disabled in my opera by default. I dont see "nice" animations and effects :) |
| 19:55 | <zewt> | i'd prefer not to break 90% of websites |
| 19:55 | <zewt> | heh |
| 19:55 | <zewt> | i disabled JS for as long as I could, but it's not feasible in 2011 |
| 19:57 | <dglazkov> | othermaciej: I writed a letter! |
| 19:59 | <zewt> | i dream of the day firefox stops copying alt texts into the clipboard |
| 19:59 | <zewt> | there must be some obscure setting to fix that... |
| 20:00 | <The_8472> | isn't that correct behavior? if images cannot be displayed their alt text should be |
| 20:00 | <zewt> | it's incorrect for real world use, so no |
| 20:00 | <The_8472> | if you consider copying into a text-only medium as a form of "displaying" it... |
| 20:00 | <zewt> | all it ever does is result in copying stuff the user doesn't want and then has to edit out |
| 20:01 | <zewt> | copying alt text to the clipboard is putting theory above practice; in practice, it just doesn't work at all |
| 20:01 | AryehGregor | manually inserts RLMs into his e-mail so the rendering isn't wrecked up by the UBA |
| 20:01 | <AryehGregor> | zewt, depends on what the alt text is. |
| 20:02 | <AryehGregor> | If it's a smilie on a forum, and the alt text is the code used to create the smilie, copying the alt text is perfect. |
| 20:02 | <zewt> | AryehGregor: sure, copying the text is getting it right for 1% at the expense of getting it wrong for 99% |
| 20:02 | <AryehGregor> | The problem is really that most alt text is braindead. |
| 20:03 | <The_8472> | you could use a userscript that strips out alt text on selection events and reinserts them on deselection! |
| 20:03 | <zewt> | what could possibly go wrong :P |
| 20:05 | <zewt> | at least ff4 fixed hidden text being copied--that was much worse |
| 20:22 | <annevk> | Hixie, please email public-web-notification⊙wo; that'd be awesome |
| 20:23 | <annevk> | Hixie, the "may ignore markup" issue is known |
| 20:24 | <Hixie> | k |
| 20:27 | <annevk> | matjas, that is UI |
| 20:28 | <jamesr> | new way to win your argument about canvas AX: call other people "dumb as concrete" |
| 20:28 | <Hixie> | annevk: why is http://dev.w3.org/2006/webapi/WebNotifications/#idl-if-Notification empty? |
| 20:30 | <The_8472> | concrete isn't that dumb. it just supports everything, regardless of merit. |
| 20:30 | <Hixie> | jamesr: i really don't understand why anyone is taking part in that discussion |
| 20:31 | <annevk> | Hixie, the editor's draft is kind of buggy I believe |
| 20:31 | <annevk> | Hixie, the TR/ draft is actually the last copy here |
| 20:32 | <Hixie> | which editor's draft? the w3c one or the whatwg one? the w3c one is self-contradictory and bogus |
| 20:32 | <jamesr> | Hixie: well at one point it seemed like he was intending to file a formal objection (presumably on IBM's behalf) on canvas being included in the w3c html spec |
| 20:32 | <Hixie> | jamesr: sounds good to me! |
| 20:32 | <Hixie> | (the whatwg one has accessibility APIs that multiple browser vendors have suggested is implementable, unlike the w3c one) |
| 20:32 | <jamesr> | yeah i had a feeling you wouldn't mind that too much :P |
| 20:33 | <Hixie> | not like formal objections do anything |
| 20:33 | <jamesr> | it spawned a near centi-thread on www-style |
| 20:33 | <Philip`> | If people don't take part, I imagine some oddly-designed feature could be created and then find its way into the W3C spec via the decision process, and then everyone would waste their time either implementing or arguing about or learning to ignore it, and any problems the feature was attempting to solve still wouldn't be solved |
| 20:34 | <Philip`> | so it'd be possibly beneficial to influence things in a positive direction earlier on |
| 20:34 | <jamesr> | i think that's already happened |
| 20:34 | <jamesr> | at least once |
| 20:34 | <jamesr> | hence the focus ring fork |
| 20:34 | <jamesr> | it's a problem worth solving, though |
| 20:34 | <Hixie> | Philip`: the w3c spec is unimplementable. it literally contradicts itself. so anyone following that is doomed anyway. |
| 20:34 | <jamesr> | apparently not in that venue, however |
| 20:35 | <Philip`> | The sun will explode eventually so we're all doomed anyway, but we should try to make people slightly less doomed when possible |
| 20:36 | <annevk> | Hixie, there's a WHATWG draft for web notifications? |
| 20:36 | <The_8472> | <Philip`> The sun will explode eventually so we're all doomed anyway <- plenty of time to build a space elevator&co |
| 20:36 | <Hixie> | Philip`: the sun exploding will happen far in the future. Someone following the W3C copy is doomed today. |
| 20:36 | <annevk> | Hixie, I'm saying you want to review http://www.w3.org/TR/notifications/ if anything |
| 20:36 | <Hixie> | annevk: oh you meant the notifications editors draft is buggy. I thought you meant the canvas one. |
| 20:37 | <Hixie> | annevk: ok new bug with the notifications thing: please can there be a permanent URL with the latest stuff. |
| 20:37 | <annevk> | Hixie, also email |
| 20:37 | <Hixie> | k |
| 20:37 | <annevk> | Hixie, you need to do some editor's class at Google |
| 20:37 | <annevk> | Hixie, editors* |
| 20:37 | <Hixie> | would that i have the time |
| 20:37 | <annevk> | Hixie, because this guy is from Google, but MikeSmith had a bunch of trouble getting it ready for publication |
| 20:38 | <annevk> | Hixie, he's using some ancient version of ReSpec |
| 20:38 | <Hixie> | i tell everyone to use html |
| 20:38 | <Hixie> | not much i can do if they don't :-) |
| 22:01 | <dglazkov> | damn running out of steam debating this component model stuff |
| 22:01 | <dglazkov> | I really am not a spec wonk |
| 22:02 | <dglazkov> | I'd rather write code |
| 22:02 | dglazkov | whines |
| 22:02 | <jamesr> | but what code do you plan to write? |
| 22:02 | <jamesr> | that's the question |
| 22:03 | <dglazkov> | pretty code, of course |
| 22:03 | <jamesr> | but what will it _do_ |
| 22:03 | <dglazkov> | awesome stuff, naturally |
| 22:03 | <dglazkov> | oh noes |
| 22:03 | <dglazkov> | he's gonna ask for use cases next |
| 22:03 | <dglazkov> | jamesr, don't you dare |
| 22:04 | <TabAtkins> | Hehe. |
| 22:04 | <jamesr> | i want a juice case |
| 22:04 | <jamesr> | and some pretzels |
| 22:04 | <dglazkov> | you sound like othermaciej :P |
| 22:05 | <TabAtkins> | othermaciej just wants intimate relationships. ^_^ |
| 22:05 | <dglazkov> | hey, those are pretty nice. |
| 22:08 | <bga_> | hm |
| 22:08 | <karlcow> | until they become promiscuous or platonic |
| 22:09 | <bga_> | domevents isnt fired during dom load |
| 22:09 | <bga_> | :( |
| 22:09 | <TabAtkins> | jamesr: I'm sorry I'm dumb as concrete. I try. ;_; |
| 22:10 | <richardschwerdtf> | you can't help it |
| 22:11 | <jamesr> | TabAtkins: at least you normally aren't a complete dick on public mailing lists |
| 22:11 | <TabAtkins> | I do have that, at least. (I save that for private emails that are then shared publicly.) |
| 22:11 | <bga_> | is there other way to catch dom node after load but before draw except put <script> after node or poll dom? |
| 22:12 | <bga_> | task: avoid double draw |
| 22:12 | <jamesr> | double draw? what do you mean exactly? |
| 22:12 | <richardschwerdtf> | TabAtkins: No you publicly waste people's time. |
| 22:12 | <bga_> | pure and with applied widget |
| 22:13 | <jamesr> | bga_: so you want to do something to a DOM node after it's loaded but before it draws? |
| 22:13 | <bga_> | extractly |
| 22:13 | <bga_> | jamesr, change dom |
| 22:13 | <bga_> | but before draw |
| 22:13 | <jamesr> | are you trying to use mutation events? |
| 22:14 | <bga_> | yeah |
| 22:14 | <jamesr> | this seems very relevant to that mutation events thread on webapps |
| 22:14 | <bga_> | but its not fired |
| 22:15 | <bga_> | nor in webkit nor in gecko |
| 22:16 | <jamesr> | yeah that's an issue |
| 22:17 | <jamesr> | bga_: but you should chime in to that thread with your use case |
| 22:17 | <jamesr> | one problem is that the currently specified dom mutation events are way too heavyweight to fire during main resource parsing |
| 22:18 | <The_8472> | can't they be scoped with selectors or something? |
| 22:22 | <bga_> | The_8472 yeah. Task is catch only nodes with specific attribute, not all nodes |
| 22:22 | <jamesr> | that doesn't help as much with the efficiency issues as you might think it would |
| 22:24 | <The_8472> | even if we would restrict it to level 2 selectors? |
| 22:26 | <The_8472> | but yeah... i guess the call overhead alone could eat quite some performance |
| 22:27 | <jamesr> | also if it's a DOM event then you have to calculate the propagation chain and all that gunk |
| 22:27 | <jamesr> | the callback-not-event proposals help there |
| 22:28 | <The_8472> | considering that it would already have scoping the event propagation would be quite redundant imo |
| 22:28 | <jamesr> | still have to spend CPU calculating the propagation chain |
| 23:18 | <boblet> | AryehGregor: re: your reply on blockquote/footer, I don’t understand “This means it's tied to the nearest <section> or <article> or such. It's not supposed to be specifically related to any other type of ancestor, like <blockquote>.” blockquote is a sectioning root element… |
| 23:21 | <Hixie> | boblet: why do you want to have the footer in the blockquote? |
| 23:22 | <boblet> | Hixie: to include attribution about the block quote… |
| 23:24 | <boblet> | Hixie: why in specifically rather than in surrounding prose: CSS styling, pre-HTML5 pattern, ‘logical’ association, and that seems a cromulent use of footer according to “A footer typically contains information about its section” |
| 23:24 | <Hixie> | CSS styling is the only one of those that seems like a real reason (as opposed to "i want to") |
| 23:24 | <Hixie> | what kind of styling do you want to do? |
| 23:25 | <TabAtkins> | Presumably throw a border around the whole blockquote. |
| 23:25 | <boblet> | It’s common for blockquote attribution to appear as part of the block quote. Common styles for block quotes include indenting (default), a different background color, or a left border. On HTML5 Doctor we use a border and box-shadow. If the attribution is outside the blockquote, making the styles match is annoying, requiring a class for eg indent, or a wrapper div for eg box-shadow. |
| 23:26 | <erlehmann> | cromulent. |
| 23:26 | <erlehmann> | wat |
| 23:27 | <TabAtkins> | http://www.google.com/webhp?q=define%3Acromulent |
| 23:27 | <boblet> | erlehmann: http://html5doctor.com/ruby-rt-rp-element/#en ;) |
| 23:29 | <Hixie> | boblet: just wrap the blockquote and attribution in a div, and style that :-) |
| 23:29 | <erlehmann> | then do microdata magic to connect it? |
| 23:30 | <erlehmann> | TabAtkins, boblet, intredasting. |
| 23:32 | <Hixie> | erlehmann: why? what problem would that solve? |
| 23:32 | <boblet> | Hixie: that’s possible, and one of the pre-HTML5 patterns I found. but I’d still argue that it’s annoying to do so. using footer seems much cleaner, fits the usage pattern of footer, and blockquote is a sectioning root element… |
| 23:33 | <TabAtkins> | Hixie: <footer>s are attached to the nearest ancestor section, thus *not* the preceding blockquote sibling. |
| 23:33 | <erlehmann> | Hixie, so it is known that it is an attribution? |
| 23:33 | <Hixie> | using footer here doesn't seem like it solves any problems |
| 23:33 | <Hixie> | just use <p> |
| 23:33 | <boblet> | I should mention that I’m not expecting any special implementor behaviour associated with this |
| 23:33 | <Hixie> | <div><blockquote>...</blockquote> <p>— ...</p></div> is what i do, works fine |
| 23:34 | <erlehmann> | boblet, what if you want to quote a footer? HA! :D |
| 23:35 | <boblet> | erlehmann: a footer just contains information about its section. There’s no restriction on having two footers in a sectioning element, so there’s no problem with quoting a footer and then having attribution in another footer. And if the block quote includes content and a footer, then the footer will still refer to the content, regardless of whether it is quoted or contains attribution |
| 23:35 | <Hixie> | ok i'm checking http://www.whatwg.org/specs/web-apps/current-work/complete.html#stream-api in shortly, first chance to tell me i'm off in the weeds :-) |
| 23:37 | <boblet> | Hixie: why *not* use footer, given blockquote is a sectioning root element? |
| 23:37 | <Hixie> | because you're not quoting a footer |
| 23:37 | <boblet> | but the footer is providing information about the section, in this case the blockquote’s content |
| 23:39 | <Hixie> | boblet: but you're not quoting it |
| 23:40 | <boblet> | Hixie: also, doesn’t that mean you’d need to change footer’s current definition so that it’s not allowed in blockquote (unless it’s being quoted)? |
| 23:40 | <erlehmann> | i like how hixie is just letting that flow. |
| 23:40 | <erlehmann> | against a wall :) |
| 23:41 | <boblet> | erlehmann: you’re not helping :p |
| 23:41 | <Hixie> | boblet: that is already its definition |
| 23:41 | <Hixie> | boblet: by definition, nothing in blockquote is allowed unless it's being quoted, since the meaning of blockquote is "this is being quoted" and you're not allowed to use elements that violate their meaning |
| 23:41 | <erlehmann> | i second that motion. |
| 23:41 | zewt | squints trying to read weirdly-rendered sentence with five quotostrophies |
| 23:42 | <erlehmann> | zewt, how are people styling that? do they use different quotes beyond single-and-double-quotes? |
| 23:43 | <boblet> | so what’s the logic behind figcaption, vs wrapping figure in div and adding a caption in a paragraph? |
| 23:43 | <zewt> | ' :) |
| 23:43 | <boblet> | zewt: wow, 5 levels of quotation is pretty rare |
| 23:43 | <boogyman> | boblet: the latter doesn't doesn't offer the same context |
| 23:43 | <zewt> | erlehmann: oh, you mean the glyph itself? |
| 23:44 | <zewt> | many fonts have different glyphs for close-single-quote and apostrophe, and using the former for the latter looks strange |
| 23:44 | <erlehmann> | boblet, http://schema.org/CreativeWork can have an author. if you wish to include attribution, why not use microdata? |
| 23:44 | <boblet> | boogyman: what do you mean by context? |
| 23:45 | <boogyman> | boblet: how a user-agent processing and understands the relation of two or more elements |
| 23:46 | <zewt> | erlehmann: http://i.imgur.com/pmBiJ.png it's an extreme example (crappy font I'm in at the moment), but it happens in more common, proportional fonts as well |
| 23:46 | <boogyman> | a <div><p> provides no context, as it is a general "wrapper" where a <figure><figcaption> creates a relationship between the two "objects" |
| 23:46 | <boblet> | erlehmann: sure, it’s possible to use microdata (or microformats or RDFa) to indicate an author as mentioned in http://html5doctor.com/blockquote-q-cite/ |
| 23:47 | <zewt> | (enough that it sticks out and looks weird) |
| 23:47 | <erlehmann> | zewt, i reject your font and substitute my own. |
| 23:47 | <erlehmann> | fun fact: i use droid sans for interfaces :) |
| 23:47 | <boblet> | zewt: youd prefer txtspeak? |
| 23:47 | <zewt> | erlehmann: for that font, fair enough :) my client isn't smart enough with fonts so I have it in a fugly japanese font for some channels |
| 23:48 | <erlehmann> | boblet, Y U NO TXTSPK? |
| 23:48 | <erlehmann> | :B |
| 23:48 | <boblet> | boogyman: same logic to my argument for using footer in blockquote |
| 23:49 | <boblet> | erlehmann: “”‘’ are on my keyboard… why not |
| 23:49 | <erlehmann> | nifty tables there on html5doctor |
| 23:50 | <erlehmann> | boblet, i use neo2 and have even more characters! „“”‚‘’⟨⟩»«›‹ |
| 23:50 | <erlehmann> | but i mostly use „“ and ‚‘ (german) |
| 23:51 | <erlehmann> | CSS styling quotes is rad :) |
| 23:57 | <boblet> | Hixie: another styling issue with your idea — I’d have to always use a wrapping div, even for blockquotes with no attribution, or hang the styles on a class and apply that to div (for attribution case) or blockquote (for no attrib case) |
| 23:58 | <boblet> | alternatively if I wanted to just use straight blockquote (no class) when there’s no attribution, I’d need to overwrite all the blockquote styles if there’s a parent div class="blockquote" |
| 23:59 | <Hixie> | :not(div.bq) > blockquote { } |
