| 00:30 | <GPHemsley> | Just a reminder to annevk and others: Please use spaces in wiki page titles. CamelCase is unnecessary and makes things harder to search for. |
| 08:01 | <annevk> | http://xkcd.com/1481/ :-) |
| 08:12 | <annevk> | Whoa, Googlebot only just added support for TLSv12 |
| 08:12 | <annevk> | Would have been nice if Adam Langley had pointed that out while telling everyone only TLSv12 is cryptographically secure |
| 08:25 | <dbz> | Hello |
| 08:26 | <dbz> | I'm having trouble with my canvas element. I want it to be full screen, and when I set height/width to 100%, then the things the canvas draws also get bigger |
| 08:27 | <dbz> | To be specific, I'm trying to turn this game I made into a phonegap app: http://dbz.github.io/BubbleChain/ |
| 08:27 | <dbz> | And when I make the canvas height/width 100%, then the balls get huge and don't act like the walls are the walls |
| 12:45 | <ondras_> | so, <my-element> and <div is=my-element> are mutually exclusive, right? My custom element is unable to support both invocations? |
| 12:47 | <annevk> | ondras_: not sure what you mean |
| 12:47 | <ondras_> | okay |
| 12:48 | <ondras_> | so, if I do registerElement(, {extends:...}) |
| 12:48 | <ondras_> | I need to use @is |
| 12:48 | <ondras_> | and the <my-element> version does not work |
| 12:48 | <ondras_> | if I omit "extends", it goes the other way around |
| 12:48 | <ondras_> | at least in chrome canary. |
| 12:48 | <annevk> | sounds about right |
| 12:49 | <ondras_> | "My custom element is unable to support both invocations?" |
| 12:49 | <ondras_> | does this question make sense now? |
| 12:49 | <annevk> | I don't think we should do is="", we should make MyElement extends HTMLDivElement work |
| 12:49 | <annevk> | ondras_: yeah I guess, I don't really see it as invocations |
| 12:49 | <ondras_> | okay, blame my poor english skills then |
| 12:49 | <ondras_> | my point is |
| 12:49 | <ondras_> | what shall I do? |
| 12:50 | <ondras_> | as an author of a custom element |
| 12:50 | <ondras_> | shall I use "extends" or not? |
| 12:50 | <annevk> | ondras_: not sure, neither Apple nor Mozilla is interested in supporting the current prototype-based custom elements |
| 12:51 | <ondras_> | ah |
| 12:51 | <ondras_> | dammit :) |
| 12:51 | <ondras_> | looks like the hype wave already took off; this will probably be a hard landing for many |
| 12:52 | <annevk> | ondras_: I wrote some blog posts and there's also https://wiki.whatwg.org/wiki/Custom_Elements |
| 12:53 | <annevk> | ondras_: and over a hundred emails on public-webapps |
| 12:54 | <ondras_> | annevk: right. the amount on public-webapps is staggering. I follow that group but I am reluctant to read that much mail .) |
| 12:55 | <ondras_> | annevk: anyway, thanks for the info about status quo |
| 15:27 | <ondras_> | is there any js api to access and modify styling for ::before and ::after pseudo-elements? |
| 15:28 | <zcorpan> | ondras_: not really, but you can add a rule to a stylesheet to style them |
| 15:29 | <zcorpan> | ondras_: what are you trying to do? |
| 15:31 | <ondras_> | zcorpan: change the "color" css property of a ::before element :/ |
| 15:31 | <ondras_> | but the color is js-generated, unfortunately |
| 15:31 | <ondras_> | so I am out of options, apparently |
| 15:32 | <ondras_> | scoped stylesheets are no longer supported, iirc? |
| 15:32 | <zcorpan> | i mean you can add a rule to a stylesheet with JS |
| 15:32 | <zcorpan> | or modify an existing rule |
| 15:33 | <ondras_> | right |
| 15:33 | <ondras_> | well say I have ten <div>s and I want to modify the ::before of one particular div |
| 15:33 | <ondras_> | those are not divs, those are my custom elements |
| 15:33 | <ondras_> | I have no control about their count, IDs and so on |
| 15:34 | <annevk> | ondras_: there's a proposal to expose them I think, but not in current browsers |
| 15:35 | <annevk> | ondras_: but then custom elements are not cross browser either :-) |
| 15:35 | <ondras_> | well, obviously. but the polymer's platform.js works quite okay |
| 15:44 | <annevk> | Domenic: so if custom-button { @extends button } can be done automatically, what is left? |
| 15:45 | <annevk> | Domenic: basically replacing the localName checks with something that looks like instanceof but is really ignoreRealmInstanceOf |
| 15:45 | <annevk> | Domenic: right? |
| 15:46 | <Domenic> | annevk: focus, a11y, a few other things |
| 15:46 | <annevk> | Domenic: the only fallback you miss at that point is non-script fallback |
| 15:46 | <annevk> | Domenic: why would that be gone? |
| 15:46 | <Domenic> | annevk: getting a button's CSS doesn't give you its focus behavior... |
| 15:46 | <annevk> | Domenic: yes, but if it's a proper subclass you should get that |
| 15:46 | <Domenic> | well, maybe, but you'd have to modify the focus spec for that |
| 15:46 | <annevk> | Domenic: and if you update the localName checks elsewhere with ignoreRealmInstanceOf |
| 15:47 | <Domenic> | better to add an extensible focus mechanism so that you don't have to subclass a focusable element to get focus behavior |
| 15:47 | <annevk> | Domenic: is there anything in the focus spec that would require something else from modifying a localName check? |
| 15:47 | <annevk> | Domenic: that seems separate |
| 15:47 | <Domenic> | it would be better if focus spec was like https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit# so that it checked el.isTabStop() |
| 15:48 | <Domenic> | then isTabStop() behavior is inherited if you inherit from the HTMLButtonElement prototype |
| 15:48 | <Domenic> | But also could be configured separately |
| 15:48 | <annevk> | I don't disagree with any of this |
| 15:48 | <Domenic> | heh ok |
| 15:48 | <annevk> | However, I'm not sure why that has to be done first |
| 15:48 | <Domenic> | i guess the idea is that if you actually make all these things extensible then you don't need any local name *or* ignoreRealmInstanceOf checks |
| 15:49 | <Domenic> | You use inherited protocols for all of them, instead of switch statements |
| 15:49 | <Domenic> | Polymorphism etc. etc. |
| 15:49 | <annevk> | Getting from <input is=x-x> to <x-x> was two things I thought. Style and localName checks. |
| 15:49 | <annevk> | Okay, so that would be an alternative way to get there |
| 15:49 | <annevk> | But that seems more invasive on the short term |
| 15:49 | <Domenic> | agreed |
| 15:50 | <Domenic> | trying to think if there was anything more. which i guess was your original question. |
| 15:50 | <annevk> | :-) |
| 15:51 | <Domenic> | i think for a sufficiently expansive definition of "localname checks" (which might be broader than the amount of times implementations check localNames) that is correct |
| 15:51 | <Domenic> | E.g. I don't think implementations have a switch(localName) to assign accessibility behavior |
| 15:52 | <Domenic> | and specs say "<button> behaves like this" |
| 15:52 | <Domenic> | you'd have to modify it to say "HTMLButtonElement and any inheritors behave like this" |
| 15:52 | <Domenic> | the switch(localName)s, in specs at least, appear in only a few cross-cutting places, like IIRC focus |
| 15:56 | <annevk> | One other problem with this is <input> btw. Ideally you'd subclass one of the types, not <input> in general. But I guess there's not really a way around that. |
| 15:56 | <annevk> | Even better would be <input type=my-custom> maybe? |
| 15:56 | <annevk> | Has the same graceful degradation |
| 15:57 | <annevk> | Yeah, for specifications we want a phrase for "button-and-subclasses elements" |
| 15:59 | <Domenic> | hmmmm I like this <input type="my-custom"> idea... |
| 15:59 | <Domenic> | Seems hard to make work |
| 15:59 | <Domenic> | But it's true that type="" is kind of the is="" of 1999 |
| 16:00 | <Domenic> | On the other hand we only have one HTMLInputElement constructor/prototype. |
| 16:22 | <annevk> | Domenic: yeah, HTML's design and JavaScript's object model are not a great match |
| 16:27 | <hemanth> | > But it's true that type="" is kind of the is="" of 1999 <- history repeats ? |
| 16:28 | <annevk> | Domenic: e.g. even if you offered some kind of solution specific to <input>, you still couldn't subclass <input type=password> |
| 16:28 | <annevk> | Domenic: it'll always be a little bit weird |
| 21:23 | <dglazkov> | https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ is great |