| 00:03 | <smaug____> | dglazkov: I don't understand the need for nested <template> elements |
| 00:04 | <smaug____> | looks like trying to take some of the mvc proposal (or whatever it was called) into webcomponents |
| 01:44 | <sicking> | Hixie: ping |
| 01:44 | <Hixie> | pong |
| 01:45 | <sicking> | Hixie: the webidl for the global scope interfaces in workers look wrong |
| 01:45 | <sicking> | Hixie: specifically, SharedWorkerGlobalScope both inherits and 'implements' WorkerGlobalScope |
| 01:45 | <Hixie> | ignore the implements thing, that's an oversight |
| 01:45 | <Hixie> | will fix |
| 01:46 | <Hixie> | wait |
| 01:46 | <sicking> | Hixie: so both shared and dedicated scopes will inherit workerglobalscope? |
| 01:46 | <Hixie> | other way around |
| 01:46 | <sicking> | Hixie: nooooo |
| 01:46 | <sicking> | Hixie: why other way around? |
| 01:46 | <Hixie> | no, you're right, should be inheritance |
| 01:47 | <sicking> | Hixie: being able to check |x instanceof WorkerGlobalScope| seems useful |
| 01:47 | <Hixie> | looks like i screwed it up when fixing it |
| 01:47 | <sicking> | Hixie: cool |
| 01:47 | <Hixie> | WorkerGlobalScope is NoInterfaceObject |
| 01:47 | <Hixie> | currently |
| 01:47 | <sicking> | why? |
| 01:47 | <Hixie> | it was only ever meant to be an editorial convenience |
| 01:47 | <Hixie> | i don't feel strongly about it |
| 01:48 | <Hixie> | hm, i wonder what i meant to do when i did this |
| 01:48 | <Hixie> | clearly not what i wrote |
| 01:49 | <sicking> | Hixie: hehe |
| 01:50 | <sicking> | Hixie: i don't think there are any good use cases for messing with the interface object of global scopes. *Possibly* with exception of being able to do instanceof checks |
| 01:50 | <sicking> | Hixie: but it seems like having objects with prototypes which aren't interface objects would be inconsistent |
| 01:50 | <sicking> | Hixie: keeping things simple and consistent seems better |
| 01:51 | <Hixie> | well originally i just wanted the global scope to be WorkerGlobalScope and to have just one flat prototype |
| 01:51 | <Hixie> | (different in dedicated, worker, and window contexts) |
| 01:51 | <sicking> | Hixie: i remember |
| 01:52 | <sicking> | Hixie: i don't think creating "shallow" proto chains is that important |
| 01:52 | <sicking> | Hixie: all script engines avoid walking up proto chains heavily anyway. You need to otherwise the DOM is dog slow |
| 01:52 | <Hixie> | it was more of an aesthetical concern |
| 01:53 | <sicking> | Hixie: meh. I think making things consistent and predictible is more important. I don't think it matters a whole lot either way though |
| 01:57 | <Hixie> | anyway |
| 01:57 | <Hixie> | fixed |
| 02:05 | <Hixie> | sicking: look ok? |
| 02:05 | <sicking> | Hixie: looking |
| 02:05 | <sicking> | Hixie: woot! looks great, thanks! |
| 02:05 | <Hixie> | np |
| 02:06 | <Hixie> | really have no idea what i was thinking when i last changed it |
| 02:08 | <sicking> | heh |
| 02:09 | <michaelw> | hmm, according to the spec, the html5 parser error recovery for </span</div> appears to emit a </span<> tag and discard the "div", is that correct? |
| 02:09 | <Hixie> | sounds right |
| 02:10 | <michaelw> | what was likely meant is </span></div>, though... why not correct that way? |
| 02:11 | <Hixie> | that's even what HTML4 required, it wasn't even a non-conforming syntax back then |
| 02:11 | <Hixie> | the short answer is "see the /topic" |
| 02:11 | <Hixie> | long answer is some complicated story about compatibility with something or other, i expect |
| 02:11 | <Hixie> | though i forget the details |
| 02:11 | <michaelw> | the "door" part? :) |
| 02:13 | <michaelw> | would it be futile if I would rework the spec to correct to </span></div>? |
| 02:13 | <Hixie> | yes and yes :-) |
| 02:14 | <michaelw> | bah :) |
| 02:15 | <michaelw> | Hixie: well, thanks anyway |
| 02:17 | <Hixie> | it's already shipped, changing it would be too much pain, too high risk, and too little reward |
| 02:19 | <llrcombs> | has anyone ever considered adding a CSS value to the <img> tag that makes text wrap around the alpha channel of the image, like it does in a word processor? |
| 02:36 | <roc> | yes |
| 02:44 | <llrcombs> | roc: is there a reason it doesn't exist, or has it just never been spec'd? |
| 02:45 | <MikeSmith> | llrcombs: I would think for the same reasons described here: |
| 02:45 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html |
| 02:47 | <roc> | I think it actually might happen as part of "CSS exclusions" |
| 02:47 | <roc> | Alex's concern is not a problem; the browser can get access to the alpha channel if it needs to |
| 02:47 | <roc> | various features require it |
| 02:48 | <llrcombs> | roc: link? |
| 02:48 | <roc> | http://google.com |
| 02:48 | <roc> | sorry, don't have it handy |
| 02:48 | <llrcombs> | alrighty, that was fast |
| 02:48 | <MikeSmith> | roc: it's good to hear that it's not a problem |
| 02:49 | <MikeSmith> | because I would be great to have something to address the hit-testing case as well |
| 02:50 | <roc> | right |
| 02:51 | <llrcombs> | roc: yeah, looks like it'd fit there pretty well. Still, I don't see anything on non-rectangular shapes for the exclusion box |
| 02:51 | <llrcombs> | so... to the mailing list? |
| 02:56 | <roc> | and beyond! |
| 02:59 | <llrcombs> | alrighty then |
| 06:58 | <zcorpan> | Wilto: did you send your use cases to the list? |
| 07:32 | <zcorpan> | http://simon.html5.org/specs/quirks-mode.src |
| 07:38 | <jgraham> | hsivonen: Isn't the backwards-compatible template parsing solution spelled <script type="template"> ? |
| 07:39 | <jgraham> | Although I guess it sucks to then have scripts in the template itself |
| 07:53 | <hsivonen> | jgraham: maybe it is |
| 08:31 | <zcorpan> | what's the right spec reference for the css width and height properties? |
| 08:32 | <zcorpan> | http://dev.w3.org/csswg/css3-box/#the-width-and-height-properties ? |
| 08:33 | zcorpan | considers a different approach |
| 08:53 | <hsivonen> | yet another commentator who seems to be attached to prefixes: http://qfox.nl/weblog/244 |
| 08:53 | <hsivonen> | as if not undermining prefixes or not killing prefixes were goals |
| 08:57 | <annevk> | not sure anyone who is not doing browser QA knows enough about the shit they cause |
| 08:57 | <annevk> | pretty hard to write specs too without browser QA experience |
| 08:58 | <hsivonen> | commentators often seem to be confused about who does the actual speccing work at the W3C and who pays for their time |
| 08:59 | <jgraham> | We need more than just hsivonen's article pointing out that prefixes are aligned with many interests but not with that of the open web |
| 08:59 | <annevk> | time to start a blog? |
| 09:00 | <annevk> | or you could use blog.whatwg.org |
| 09:00 | <hsivonen> | jgraham: you could write an article. I'll link to it |
| 09:00 | <annevk> | there's also james.html5.org still |
| 09:00 | <zcorpan> | ok, got hashless hexcolors and unitless lengths covered now |
| 09:01 | <hsivonen> | also it seems common for readers of the minutes to not realize that Florian is from Opera |
| 09:01 | <annevk> | he's our CSS guy now |
| 09:01 | <zcorpan> | we need a blog post that translates the minutes to English |
| 09:01 | <annevk> | I'm sure people will get used to it |
| 09:02 | <annevk> | zcorpan: heh |
| 09:02 | <hsivonen> | zcorpan: indeed! I've been thinking there'd already be an English translation if Mark Pilgrim was still blogging |
| 09:06 | <hsivonen> | aaaaand glazou goes for the "educade Web authors" option: http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW |
| 09:07 | <jgraham> | I am honmestly surprised that glazou still thinks that evangalism can work to persuade people not do do things that are in their own best interests |
| 09:07 | <jgraham> | and using prefixed properties is very much in author's best interests |
| 09:08 | <jgraham> | Because it allows them to create new designs that people haven't managed before, and blog about them. This helps establish their professional credibility in a competitive market |
| 09:09 | <jgraham> | Even if they only use them in demos, the effects can becoem popular enough that people demand them on their production sites |
| 09:09 | <jgraham> | Which is very easy to justify if it only breaks lower-marketshare browsers |
| 09:09 | jgraham | is just saving up notes in case he ever writes that blog article |
| 09:10 | <jgraham> | (I realise I am preaching to the choir here) |
| 09:10 | <jgraham> | Anyway, my original point is that galzou has been around long enough to see evangalism fail |
| 09:10 | <jgraham> | Repeatedly |
| 09:11 | <jgraham> | So it's kind of sad that he thinks it will work in his pet case |
| 09:12 | <hsivonen> | well, at least I guessed correctly what the most important blog post ever was going to be |
| 09:14 | <hsivonen> | This could use a translation by Mark Pilgrim, too |
| 09:15 | <hsivonen> | the "also represents an official discussion of the CSS Working Group and was decided by consensus in the Group" part is probably the most sad one |
| 09:15 | <zcorpan> | what was it with "chair should be neutral" again? |
| 09:18 | <zcorpan> | "In many if not most cases, the -webkit-* properties WebKit-specific web sites are using do have -moz-*, -ms-*, -o-* equivalents." |
| 09:18 | <zcorpan> | I am high as a kite. |
| 09:18 | <wilhelm_> | Apart from the minor fact that is't not going to work, he does have a point. |
| 09:18 | <hsivonen> | using -moz-, -ms- and -o- also misses the point. that pattern means there can never be a new entrant to the market who doesn't implement someone else's prefixes |
| 09:18 | <zcorpan> | unless he means that the browsers have implemented their equivalent prefixed properties |
| 09:19 | <zcorpan> | which maybe he did |
| 09:21 | zcorpan | goes back to standardizing quirks |
| 09:22 | <jgraham> | zcorpan: Heresy! |
| 09:28 | <matjas> | how is <input type=email value=foo@mañana.com> invalid markup? |
| 09:29 | <matjas> | trying to understand what Hixie’s saying here https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489#c12 |
| 09:29 | <zcorpan> | matjas: see the requirements for the value attribute |
| 09:29 | <hsivonen> | matjas: validating email values is a long-standing unimplemented feature in V.nu, FWIW |
| 09:30 | <hsivonen> | email addresses are hard |
| 09:30 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state-(type=email) |
| 09:30 | <zcorpan> | "The value attribute, if specified and not empty, must have a value that is a single valid e-mail address." |
| 09:30 | <zcorpan> | foo@mañana.com does not match the production http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address |
| 09:31 | <zcorpan> | hsivonen: just use the non-normative regex. :-) |
| 09:31 | <matjas> | thanks |
| 09:31 | <matjas> | hah, in a way, that’s what that bug is about — “why not allow IDN emails?” |
| 09:32 | <zcorpan> | there's a difference between allowing the user to type IDN emails and allowing the author to use IDN emails in markup |
| 09:33 | <zcorpan> | the former is already supported |
| 09:33 | <zcorpan> | the latter is not |
| 09:33 | <matjas> | yeah, but i don’t see what’s so bad about the latter |
| 09:34 | <zcorpan> | me either |
| 09:34 | <zcorpan> | but i haven't heard any use cases |
| 09:34 | <zcorpan> | not that i have been listening really :-) |
| 09:36 | <zcorpan> | it's similar to <input type=color value=blue> |
| 09:36 | <zcorpan> | which is also not allowed |
| 09:36 | <zcorpan> | sure, the browser could convert the value |
| 09:36 | <zcorpan> | but what's the use case? |
| 09:37 | <zcorpan> | allowing one syntax and not doing conversion makes the impl simpler, which means less bugs overall |
| 09:37 | <zcorpan> | and more time can be spent on adding more features that actually give new abilities |
| 09:37 | <matjas> | i don’t know, say you’ve imported an email database from a desktop app that allowed IDN addresses… |
| 09:38 | <zcorpan> | just convert it to ASCII before putting it in markup |
| 09:38 | <zcorpan> | what if you have a database of colors using a mix of hex and keywords and you want to use them in <input type=color value=...>? |
| 09:39 | <matjas> | that means web devs need to implement a punycode encoder, even though the browser already has that built-in |
| 09:39 | <zcorpan> | yeah |
| 09:39 | <zcorpan> | aren't there libraries available to do that already? |
| 09:40 | <matjas> | probably |
| 09:40 | <matjas> | (I know I’ve written one in JS) |
| 09:49 | <zcorpan> | wait. css font-size keywords and <font size> aren't different between quirks and standards anymore? or am i doing something wrong in my testing? |
| 10:08 | <hsivonen> | my sarcasm detector is broken: https://twitter.com/#!/slightlylate/status/167549285754339328 |
| 10:35 | <roc> | boy |
| 10:37 | <zcorpan> | :hover and :active quirk specced |
| 10:42 | <roc> | at least glazou's pointing his guns in the right directions, even if he doesn't have any ammo. For a while I thought he was going to shoot the messengers |
| 10:44 | <MikeSmith> | zcorpan: specced where? |
| 10:44 | <Ms2ger> | http://simon.html5.org/specs/quirks-mode.src |
| 10:44 | <MikeSmith> | oh cool |
| 10:49 | <MikeSmith> | https://twitter.com/#!/balmer/status/167553463792832512 is good |
| 11:08 | <wilhelm_> | Heh. https://twitter.com/#!/TinaHolmboe/status/167562350910652416 |
| 11:16 | <zcorpan> | In quirks mode, the font element changes the color of text decorations specified on ancestor elements |
| 11:16 | <zcorpan> | -> In this spec. Should maybe move the HTML's rendering section. |
| 11:16 | <zcorpan> | In WebKit, <font> always overrides the ancestor's text-decoration color, even in standards mode. |
| 11:16 | <zcorpan> | In Opera, <font> overrides the ancestor's text-decoration in quirks mode if it has a color attribute and the color is not overridden by CSS. |
| 11:16 | <zcorpan> | In Gecko, <font> overrides the ancestor's text-decoration in quirks mode if it has a color attribute that is not the empty string or consists of only whitespace. |
| 11:16 | <zcorpan> | Since there's lack of interop, let's drop the check of the color attribute. |
| 11:16 | <zcorpan> | WebKit's behavior also seems tempting, but then this really should move to HTML. |
| 11:16 | <zcorpan> | What does IE do? |
| 11:17 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1332 can be used for experimenting in case somebody has IE and is curious enough |
| 11:19 | <wilhelm_> | zcorpan: foo is black, bar is red, baz is black. Underline is black. |
| 11:19 | <wilhelm_> | IE9. |
| 11:20 | <zcorpan> | wilhelm_: what about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1333 ? |
| 11:20 | <wilhelm_> | Identical rendering. |
| 11:21 | <zcorpan> | woah |
| 11:21 | <zcorpan> | so maybe this quirks isn't really needed |
| 11:21 | <zcorpan> | thanks! |
| 11:23 | <wilhelm_> | zcorpan: Just in case I'm colour blind, here's a screenshot: http://i.imgur.com/YXJjY.png |
| 11:23 | <zcorpan> | yep, the underline is black alright |
| 11:23 | <zcorpan> | are you color blind? |
| 11:24 | <wilhelm_> | Not to my knowledge. (c: |
| 11:24 | <zcorpan> | k :) |
| 11:25 | <zcorpan> | can you check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1334 also? |
| 11:26 | <zcorpan> | (does bar have underline?) |
| 11:27 | <wilhelm_> | No. |
| 11:27 | <zcorpan> | thanks |
| 11:27 | <wilhelm_> | No underline after the last “o” in “foo”. |
| 11:33 | <annevk> | hsivonen: I think Alex is serious |
| 11:33 | <annevk> | hsivonen: also wrong |
| 11:44 | <zcorpan> | wilhelm_: what about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1335 - does the table show a border around the first (empty) cell in ie? |
| 11:45 | <wilhelm_> | Yes. |
| 11:45 | <zcorpan> | excellent |
| 11:46 | <zcorpan> | several quirks can be dropped it seems |
| 11:46 | <wilhelm_> | Fun. |
| 11:50 | <annevk> | speccing quirks mode finally? |
| 11:50 | <annevk> | oh joy |
| 11:53 | <zcorpan> | yep |
| 11:53 | <zcorpan> | today is our first "do WTF you want" day |
| 11:53 | <zcorpan> | so that's what i'm doing |
| 11:54 | <wilhelm_> | Company-wide? |
| 11:56 | annevk | made eggs |
| 11:57 | <zcorpan> | don't know if it's company wide |
| 11:57 | <annevk> | just core afaik |
| 12:00 | <annevk> | http://intertwingly.net/blog/2012/02/09/Dominos is pretty straightforward |
| 12:19 | <asmodai> | The whole CSS thing reached tweakers.net as well |
| 12:21 | <wilhelm_> | Interesting comments. |
| 12:22 | <asmodai> | I like the amount of "W3C is slow as molasses" comments. |
| 12:23 | <zcorpan> | yeah, they're fucking slow |
| 12:23 | <zcorpan> | if only they could fuck faster |
| 12:23 | <asmodai> | zcorpan: lol |
| 12:34 | <zcorpan> | wilhelm_: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1337 does ie wrap the table? |
| 12:34 | <zcorpan> | w00t i got 1337 |
| 12:36 | <zcorpan> | (or if somebody else has ie...) |
| 12:37 | <wilhelm_> | zcorpan: No. There is one line of text. |
| 12:37 | <zcorpan> | and what if you remove the doctype? |
| 12:38 | <wilhelm_> | No difference. |
| 12:38 | <zcorpan> | hah |
| 12:38 | <wilhelm_> | (You should get a Windows VM :P) |
| 12:39 | <zcorpan> | yeah. you know, come to think of it, i could just borrow my wife's computer. doesn't have ie9, but is probably good enough |
| 12:39 | <zcorpan> | thanks for the help! |
| 13:10 | <MikeSmith> | zcorpan: congrats on scoring 1337 |
| 13:10 | <MikeSmith> | must be some kind of sign from god |
| 13:10 | <MikeSmith> | you have been chosen |
| 13:11 | <MikeSmith> | wilhelm_: hahaha |
| 13:11 | <MikeSmith> | The Day the Music Died |
| 13:12 | <wilhelm_> | Indeed. |
| 13:12 | <zcorpan> | so anyone know what happened to the font-size:small quirk? i can't reproduce it in any of my browsers, including IE |
| 13:13 | <MikeSmith> | wilhelm_: great touch the scare quotes too |
| 13:13 | <MikeSmith> | HTML "5" |
| 13:13 | <zcorpan> | http://www.cs.tut.fi/~jkorpela/quirks-mode.html "Font size keywords are interpreted incorrectly so that medium is larger than the browser’s basic font size and small equals that basic font size. Similarly, the entire scale of keywords, xx-small, x-small, small, large, x-large, xx-large is interpreted systematically wrong: each value is interpreted as one step larger than it should." |
| 13:14 | <zcorpan> | i totally remember this quirk |
| 13:17 | <zcorpan> | oh, this was ie9. i thought it was ie8 |
| 13:18 | <zcorpan> | ie9 normal quirks mode doesn't have this quirk |
| 13:18 | <zcorpan> | but ie9 quirks mode in "compat view" has it |
| 13:18 | <zcorpan> | awesome |
| 13:18 | <wilhelm_> | MikeSmith: This really is all the politics of the past 15 years distilled down to a single discussion. All factions appear to be represented. Quite fascinating. |
| 13:19 | <MikeSmith> | The Sound and the Fury, man |
| 13:20 | wilhelm_ | had to look that up. (c: |
| 13:35 | <Ms2ger> | "CSS Rates and Velocities Community Group"? |
| 14:21 | <zcorpan> | http://simon.html5.org/specs/quirks-mode - first draft |
| 14:23 | <annevk> | you should somehow define these only apply in quirks mode :) |
| 14:23 | <annevk> | and reference the HTML term for that |
| 14:25 | <zcorpan> | dude quirks mode is a DOM4 term |
| 14:25 | <annevk> | dude |
| 14:26 | <annevk> | where is my spec dude |
| 14:26 | <zcorpan> | sweet |
| 14:26 | <zcorpan> | what does mine say? |
| 14:30 | <volkmar> | someone knows in which spec the Screen interface is specified? |
| 14:31 | <Ms2ger> | HTML? |
| 14:31 | <Ms2ger> | Or CSSOM |
| 14:32 | <volkmar> | Ms2ger: CSSOM |
| 14:32 | <volkmar> | Ms2ger: thanks :) |
| 14:32 | <Ms2ger> | Np |
| 14:33 | <zcorpan> | annevk: fixed |
| 14:40 | <smaug____> | hmm, web needs some new tools to prevent memory leaks |
| 14:40 | <smaug____> | memory leaks in the pages |
| 14:42 | smaug____ | has seen leaks in Google services way too often |
| 14:44 | <MacTed> | G+ leaks uncontrollably. something about endlessly increasing pagelength, constantly prepending more content, no way to go to "next page" when scrolling through the stream... |
| 14:47 | <zewt> | last i saw, gmaps leaked continually in chrome, though that seemed like a webkit/chrome bug |
| 14:47 | <AryehGregor> | So I've started to get used to mq. |
| 14:48 | <smaug____> | yeah, that happens with Google Reader too, and I think in some cases with Gmail. Of course other web sites have similar problems. IRCcloud for example |
| 14:48 | <smaug____> | ah, I haven't look gmaps |
| 14:48 | <zewt> | found it fascinating that one of google's most high-profile products leaks in one of their others |
| 14:48 | <smaug____> | but anyway, it is way too easy to write leaky web pages |
| 14:48 | <AryehGregor> | It seems like it serves roughly the same purpose as git branches, except inferior in almost every conceivable fashion. |
| 14:48 | <zcorpan> | now, where should i email this? www-style? |
| 14:48 | <zewt> | webkit seems (seemed? been a while) to leak whenever lots of dynamic images were used |
| 14:48 | <smaug____> | I'm not talking about browser leaks |
| 14:48 | <AryehGregor> | Like how you have to manage them using an entirely separate set of commands, which inexplicably work in slightly different ways from the ones you use for actual commits. |
| 14:49 | <smaug____> | I'm talking about web site leaks |
| 14:49 | <Ms2ger> | zcorpan, depends, how much time do you have to waste on the resulting permathread? :) |
| 14:49 | <zewt> | that's no easier than in any language |
| 14:49 | <AryehGregor> | Like, qnew doesn't prompt you for a commit message by default. Why not? I don't know. |
| 14:49 | <zewt> | except perhaps for the lack of weakrefs (but most people who end up with code that leaks refs probably don't know what those are anyway) |
| 14:49 | <zcorpan> | Ms2ger: not much. :-) |
| 14:49 | <AryehGregor> | And you have to give every patch an arbitrary name. |
| 14:49 | <Ms2ger> | zcorpan, in that case I'd recommend whatwg :) |
| 14:49 | <smaug____> | zewt: well, there is weakmap |
| 14:49 | <smaug____> | (at least in some JS engs) |
| 14:50 | Ms2ger | removes quirks instead |
| 14:50 | <AryehGregor> | And everything refuses to do anything whatsoever if you have uncommitted changes. git will pretty much always just try to merge your changes with whatever you're doing, which is normally the correct thing. |
| 14:51 | <zcorpan> | ok sent to whatwg |
| 14:51 | <AryehGregor> | I've had to resort to hg diff > /tmp/patch; hg revert --all; hg purge; hg qpop -a; hg qq -c somenewqueue; hg qimport /tmp/patch |
| 14:51 | <smaug____> | zewt: I don't know if there are any good tools to debug js leaks |
| 14:51 | smaug____ | should write one for FF based on cycle collector logs |
| 14:51 | <AryehGregor> | As opposed to, in git: git branch -c somenewbranch master; git commit -a |
| 14:51 | <karlcow> | in Normandy, it has been a very long time we know that CSS (Camenbert Style Sheet) is leaking in web pages http://la-grange.net/2004/03/24-css-fluid-design |
| 14:53 | <AryehGregor> | "In WebKit, <font> always overrides the ancestor's text-decoration color, even in standards mode." |
| 14:54 | <AryehGregor> | zcorpan, FWIW, that's because WebKit's handling of text-decoration is completely not per CSS2.1. |
| 14:54 | <AryehGregor> | Only one text-decoration of a given type (underline, etc.) can apply to any given glyph, and it always takes the size and color of that glyph. |
| 14:54 | <zcorpan> | AryehGregor: i tried with <span style=color:red> and it didn't change the color |
| 14:54 | <AryehGregor> | Really? |
| 14:54 | <AryehGregor> | Maybe I'm just thinking of size. |
| 14:54 | AryehGregor | tests |
| 14:55 | <AryehGregor> | You're right. |
| 14:55 | <AryehGregor> | Weird. |
| 14:55 | <zcorpan> | ok i'm done for today. i'll read the logs |
| 14:55 | <AryehGregor> | I'm thinking of superscript/subscript. |
| 15:17 | <jgraham> | AryehGregor: I have roughly the same impression of mq fwiw |
| 15:28 | <Ms2ger> | Hrm |
| 15:28 | <Ms2ger> | <table border cellpadding=-10><tr><td>A<td>B</table> |
| 15:29 | <Ms2ger> | What should the padding on the cells be? |
| 15:29 | <AryehGregor> | How does the spec say to parse cellpadding? |
| 15:30 | <GlitchMr> | I would guess either 0 or cellpadding value being ignored... |
| 15:30 | <Ms2ger> | "The table element's cellpadding attribute maps to the pixel length properties 'padding-top', 'padding-right', 'padding-bottom', and 'padding-left' of any td and th elements that have corresponding cells in the table corresponding to the table element." |
| 15:30 | <Ms2ger> | "When the text below says that an attribute attribute on an element element maps to the pixel length property (or properties) properties, it means that if element has an attribute attribute set, and parsing that attribute's value using the rules for parsing non-negative integers doesn't generate an error, then the user agent is expected to use the parsed value as a pixel length for a presentational hint for properties." |
| 15:31 | <Alesk\o_> | hello |
| 15:33 | <GlitchMr> | Negative paddings don't exist in CSS (negative margins exist in CSS nevertheless), so it would be syntax error. Attribute would be ignored (visual part of it, it will be still in DOM), I guess. |
| 15:33 | <GlitchMr> | But that's just my guess |
| 15:34 | <Ms2ger> | I just want someone to tell me that Chrome and Opera are wrong |
| 15:34 | <GlitchMr> | In what? |
| 15:35 | <Ms2ger> | In having 0 padding |
| 15:36 | <GlitchMr> | It has 0 padding even without this invalid attribute |
| 15:36 | <Ms2ger> | No it doesn't, it has 1 pixel |
| 15:36 | <GlitchMr> | I don't see difference... weird... |
| 15:37 | <GlitchMr> | It has 1 pixel padding. |
| 15:37 | <GlitchMr> | Either with invalid attribute or without attribute at all. |
| 15:37 | <GlitchMr> | According to Opera debugging tools... |
| 15:39 | <GlitchMr> | Oh wait, I had cellpading lol |
| 15:39 | <GlitchMr> | Yeah, you're right... |
| 15:40 | <Ms2ger> | Good |
| 15:40 | Ms2ger | wanders off |
| 15:40 | <GlitchMr> | I wouldn't say it's issue. You're using obviously bad HTML code. |
| 15:40 | <GlitchMr> | I will even skip that cellpadding is deprecated in HTML5... |
| 15:43 | <Alesk\o_> | hello, what about a reset property ? in CSS |
| 16:17 | <Alesk\o_> | no ? :) |
| 16:28 | <AryehGregor> | Is there some way with mq to reorder patches in a queue? I don't see it in hg help mq . . . |
| 16:30 | <Philip`> | AryehGregor: Pop them all, then edit .hg/patches/series |
| 16:30 | <AryehGregor> | . . . |
| 16:31 | <AryehGregor> | That is patently ludicrous. |
| 16:31 | <Philip`> | http://mercurial.selenic.com/wiki/MqExtension#Using_Mercurial_Queues |
| 16:47 | <AryehGregor> | (although, thanks for the tip) |
| 16:47 | <AryehGregor> | (I just hate Mercurial) |
| 16:47 | <AryehGregor> | (as regulars of this channel might have noticed) |
| 16:55 | <MikeSmith> | AryehGregor: not ht push --move foo ? |
| 16:55 | <AryehGregor> | MikeSmith, what? |
| 16:55 | <MikeSmith> | *hg qpush --move foo |
| 16:56 | Philip` | likes it when all the metadata is in nice simple text files that he can edit with a standard text editor, instead of having to memorise sequences of command line arguments |
| 17:01 | <AryehGregor> | MikeSmith, ah, that might do it. Thanks. |
| 17:02 | <AryehGregor> | Philip`, I'm fine with the text files, just not text-file editing as the recommended way to do things. It's harder to ensure integrity -- mistype and you could corrupt the file. |
| 17:05 | <Philip`> | Then you'll just get an error when qpushing and you can go and fix it, hopefully |
| 17:06 | <Philip`> | (I suppose the "hopefully" part is worrying) |
| 17:18 | <bga> | continue 'all in one' idea of opera http://leechcraft.org/ |
| 18:05 | <erlehmann> | oh hai |
| 18:08 | <erlehmann> | dat prefix |
| 18:08 | <erlehmann> | ._. |
| 18:09 | <erlehmann> | is there anything that can be said against http://leaverou.github.com/prefixfree/ ? |
| 18:09 | <Wilto> | I have Opinions, but I don’t think you’re looking for the thoughts of some scrub non-WHATWG developer. |
| 18:10 | <erlehmann> | show and tell |
| 18:12 | <Wilto> | I think it is clever. I think it is well-coded. I will never, ever use it because it is terrifying to me. |
| 18:13 | <Wilto> | It is a massive solution to a almost non-existent problem: a minor increase in the verbosity of one’s CSS. |
| 18:13 | <Wilto> | It’s a new point of failure, it’s a mashing-together of concerns; I dunno. I get the idea—and like I said, it’s cleverly done. I never fault anyone for making cool things. But I wouldn’t use it. |
| 18:15 | <erlehmann> | Wilto, intredasting. |
| 18:15 | <Wilto> | She’s good people, too. I feel bad bad-mouthing it. |
| 18:15 | <Wilto> | Anyway. |
| 18:15 | <zewt> | quotostrophes |
| 18:16 | <erlehmann> | wat |
| 18:16 | <Wilto> | Sorry, sorry. Force of habit. |
| 18:16 | <AryehGregor> | So looks like elementFromPoint() only works on stuff in the viewport. Rats. |
| 18:16 | <erlehmann> | Is it “she's”, “she`s”, “sh |
| 18:17 | <erlehmann> | e‘s” or „she’s“ ? |
| 18:17 | <erlehmann> | AryehGregor, what you use it for? |
| 18:17 | <AryehGregor> | erlehmann, testing the bounds of transformed elements programmatically. |
| 18:17 | <AryehGregor> | Looks like I have to keep them in the viewport somehow. |
| 18:18 | <erlehmann> | scrollTo |
| 18:18 | <erlehmann> | AryehGregor, is that a solution? |
| 18:19 | AryehGregor | will try |
| 18:19 | <AryehGregor> | Seems like Opera's elementFromPoint() is a stub that just always returns undefined. |
| 18:19 | <AryehGregor> | Guess it will fail all these tests. |
| 18:19 | <AryehGregor> | Oh well. |
| 18:20 | <erlehmann> | scrollTop |
| 18:20 | <erlehmann> | set element.scrollTop |
| 18:20 | <dglazkov> | good morning, Whatwg! |
| 18:21 | <erlehmann> | AryehGregor, this is how i scroll http://warumnicht.so/wn-8.html |
| 18:21 | <dglazkov> | hsivonen: how does DWIM deabbreviate? |
| 18:21 | <AryehGregor> | dglazkov, "do what I mean" |
| 18:21 | <dglazkov> | sure! I'll do it. What do you mean? :) |
| 18:22 | <dglazkov> | AryehGregor: and thanks -- I suspected as much, just wanted to check. |
| 18:24 | <gsnedders> | AryehGregor: elementFromPoint should return stuff at times. |
| 18:24 | <AryehGregor> | gsnedders, good to know. |
| 18:25 | <AryehGregor> | Seems to not work in my test-cases, though. |
| 18:25 | <gsnedders> | AryehGregor: http://tc.labs.opera.com/apis/cssom/023.htm is a case of us returning too much! |
| 18:52 | <BenoitRen> | Hi there. I'm a bit confused about the q element and have a question about the i element. |
| 18:52 | <BenoitRen> | See, I've always used the q element for lines spoke by characters in fan fiction. |
| 18:52 | <BenoitRen> | Additionally, I've also used the q element for characters's thoughts, with a "thoughts" class to have them in italics. |
| 18:53 | <BenoitRen> | I just did some reading and I may have been using the q element wrong, at least for thoughts. It seems the i element should be used for those. |
| 18:54 | <BenoitRen> | As for using the q element for character lines, I'm not sure about that. |
| 18:54 | <BenoitRen> | Please advice. |
| 19:05 | <Philip`> | BenoitRen: What's wrong with just using double-quotes to denote speech? |
| 19:05 | <BenoitRen> | Philip`: Nothing; I just thought using the q element added semantic value. |
| 19:06 | <erlehmann> | BenoitRen, which value? if you are not quoting something? |
| 19:06 | <erlehmann> | if you are quoting something, i understand q. |
| 19:06 | <BenoitRen> | erlehmann: I thought I was quoting the speaker. |
| 19:07 | <erlehmann> | BenoitRen, does the speaker have a URI? |
| 19:07 | <BenoitRen> | erlehmann: No... |
| 19:07 | <erlehmann> | BenoitRen, what are you denoting then? |
| 19:07 | <BenoitRen> | erlehmann: A quote, I thought. |
| 19:08 | <AryehGregor> | Okay, so if you have a patch in your queue and it was applied upstream and you qpop -a, pull -u, qpush -a . . . every patch that was applied upstream fails with merge conflicts and you have to manually delete it? |
| 19:08 | <AryehGregor> | Really? |
| 19:08 | <erlehmann> | BenoitRen, try to phrase it subject-verb-object. |
| 19:09 | <AryehGregor> | As opposed to git rebase, which silently drops any patches that were accepted upstream? |
| 19:09 | <AryehGregor> | Is there some smart way to avoid this, or do I just have to manually delete those patches? |
| 19:09 | <erlehmann> | like, someone said „x“ |
| 19:10 | <Philip`> | BenoitRen: I think "semantic value" by itself isn't usually worthwhile - markup is only useful when it's interpreted by something, and then you can use the way it's interpreted as a guide to how you should use the markup |
| 19:11 | <AryehGregor> | Okay, so maybe I want to do hg qfinish -a? |
| 19:11 | <Philip`> | BenoitRen: and I'm not aware of <q> being interpreted usefully by anything (though that may just be my ignorance) |
| 19:11 | <AryehGregor> | That looks like it does what I want. |
| 19:11 | <AryehGregor> | Oh, no, it doesn't. |
| 19:11 | <erlehmann> | Philip (i cannot find out which quote character is that) |
| 19:11 | <AryehGregor> | Grrr. |
| 19:11 | <erlehmann> | Philip, q @cite can be interpreted usefully. |
| 19:12 | <erlehmann> | also styling hooks |
| 19:12 | <erlehmann> | q[lang=en] |
| 19:12 | <erlehmann> | „quotes“ can be ”different” |
| 19:14 | <Philip`> | Seems easier to just write the quote characters that you want, using whatever system you already have in place for i18n to handle all the language-specific things that can't be hooked onto <q> |
| 19:14 | <erlehmann> | i always use q and blockquote with cite, in case i have to untangle something. |
| 19:15 | <erlehmann> | Philip, “whatever system you already have in place” certainly isn't easier ;) |
| 19:15 | <erlehmann> | but writing quote characters for speech, that i support. |
| 19:28 | <BenoitRen> | So, uh, I've been using the quote characters wrong, then? :S |
| 19:28 | <BenoitRen> | The q element, I mean. |
| 19:28 | <BenoitRen> | s/quote characters/q element |
| 19:30 | <Philip`> | BenoitRen: I think the problem is that "wrong" is hard to define, when there is basically no noticeable effect from using the elements at all, so you can't tell whether it's having an appropriate or inappropriate effect |
| 19:31 | <BenoitRen> | Philip`: I define 'wrong' as 'is not what the spec says it should be used for'. |
| 19:31 | <Philip`> | Specs can be wrong :-) |
| 19:32 | <BenoitRen> | Then the spec has to be fixed! But in the meantime, it is what I'm using... |
| 19:33 | <Philip`> | Per my reading of HTML5, using <q> for speech inside a piece of text is wrong, since you're not quoting from an external piece of text |
| 19:34 | <BenoitRen> | Okay. |
| 19:34 | <Philip`> | though I wouldn't be entirely certain about that |
| 19:34 | <BenoitRen> | *a smash into a wall could be heard* |
| 19:35 | <Philip`> | but then I'm never certain about the semantics of any of HTML, because they always seem to be phrased strangely and/or vaguely :-) |
| 19:37 | <Philip`> | If you want an 'official' answer, I guess the best way is to file a bug asking for the spec to clarify your particular case, and see what Hixie thinks the semantics should be |
| 19:40 | <BenoitRen> | B-b-but I already asked for a clarification a couple months ago on a different issue in an existing bug and didn't get a reply. :'( |
| 19:41 | <Philip`> | Some people wait years for a response from the editor :-) |
| 19:42 | Philip` | thinks 5 years is about the longest he's seen |
| 19:42 | <erlehmann> | the spec should have a section “leters from the editor” |
| 19:43 | <Philip`> | I suppose it'd be quicker if someone else on IRC understands the issue properly and can help |
| 19:44 | Philip` | doesn't know much, and just has a general distrust of vague subjective semantics that don't provide any real value to anyone :-p |
| 19:44 | <Hixie> | matjas: you'll need to have a punycode encoder anyway, before you can send your e-mails |
| 19:46 | <matjas> | Hixie: not if your back-end scripting language or mail client handles that for you automatically |
| 19:46 | <Hixie> | well if it handles it for you automatically, you already have a punycode encoder |
| 19:46 | <Hixie> | so just use that |
| 19:47 | <Hixie> | bbiab, gotta go to the office |
| 19:47 | <matjas> | what if it doesn’t expose the API? |
| 19:47 | <erlehmann> | be back in a binute? |
| 19:48 | <matjas> | erlehmann: boat* |
| 19:54 | <BenoitRen> | So can I use the i element for an onomatopoeia? |
| 19:55 | <erlehmann> | stop doing that |
| 19:56 | <BenoitRen> | I haven't done it yet, but I'm asking if it's appropriate. |
| 19:56 | <BenoitRen> | If not, what element would be appropriate? |
| 20:09 | <erlehmann> | BenoitRen, what exactly are you trying to convey here? |
| 20:10 | <BenoitRen> | erlehmann: An onomatopoeia? Hold on, I'll paste the relevant line. |
| 20:10 | <BenoitRen> | "Hearing the loud /ka-KLANG/ of an iron door slamming shut is a scary experience." |
| 20:11 | <erlehmann> | well, make it strong? |
| 20:11 | <erlehmann> | or wait |
| 20:11 | <erlehmann> | is it a different, set-off tone? |
| 20:11 | <Wilto> | I mean, that _is_ an "alternate voice," I suppose. |
| 20:15 | <BenoitRen> | I don't have much more to go on other than that line and the fact that the ka-KLANG must be in italics. |
| 20:15 | <BenoitRen> | Because it's an onomatopoeia. |
| 20:15 | <BenoitRen> | It sounds like a different tone to me, though. |
| 20:16 | <BenoitRen> | Full disclosure: people send me stories, I zap the typos, then mark them up. |
| 20:23 | <erlehmann> | BenoitRen, how much does that pay? |
| 20:25 | <Philip`> | BenoitRen: If it would usually be rendered in italics in a visual medium, and there isn't an obviously more appropriate semantic element, then that sounds like a good use for <i> |
| 20:50 | <BenoitRen> | erlehmann: Pay? I'm doing this for free. It's for a fansite. |
| 20:53 | <Wilto> | I bet it's a WHATWG fansite. I could've sworn I heard a "ka-KLANG" in here earlier. |
| 21:03 | BenoitRen | wonders what ka-KLANG has to do with WHATWG. |
| 21:04 | <bga> | http://mozilla-antarctica.org/ |
| 21:09 | <BenoitRen> | I'm always disappointed to find out that Mozilla-related sites make no effort at being standards compliant. |
| 21:11 | <roc> | what's wrong with it? |
| 21:12 | <roc> | erlehmann: the only thing against prefix-free and other similar tools is that if everyone used them, we might as well not have vendor prefixes at all |
| 21:13 | <BenoitRen> | Divitis, fake XHTML, some invalid CSS, doesn't resize to viewport... |
| 21:13 | <erlehmann> | roc, but vendor prefixes work differently and have different notations. |
| 21:15 | <roc> | the point of vendor prefixes is (was?) to let people experiment without creating compatibility issues around the unprefixed name |
| 21:15 | <BenoitRen> | Oh, I see the root of the problem already; the site uses WordPress. |
| 21:15 | <bga> | as result you will need jq for css. was attachEvent or addEventListener, become css prefixes w/ defferent notations |
| 21:15 | <roc> | everything that encourages Web developers to start using the unprefixed name immediately, reduces that benefit. |
| 21:16 | <roc> | if all Web developers use the unprefixed name immediately, there is no benefit. |
| 21:16 | <BenoitRen> | When I look at my Error Console I wonder who had the bright idea of reporting every use of vendor-prefixed CSS as a warning. |
| 21:16 | <erlehmann> | roc, i see. |
| 21:17 | <roc> | Henri explained all this quite some time ago :-) |
| 21:17 | <BenoitRen> | It even reports CSS that's valid but that it doesn't support yet. |
| 21:18 | <erlehmann> | Benoit, that is a good idea. |
| 21:19 | <roc> | it's hard to tell whether CSS we don't support yet is valid or not :-) |
| 21:19 | <roc> | yes, it would seem to make sense to suppress warnings for other vendor's prefixed properties |
| 21:19 | <roc> | dunno why we don't do that |
| 21:28 | <jgraham> | BenoitRen: "divitis" and "doesn't resize to the viewport" are hardly standards compliance isues |
| 21:28 | <BenoitRen> | jgraham: You're wrong. |
| 21:28 | <jgraham> | Convince me |
| 21:29 | <jgraham> | (also it doesn't seem to be fake XHTML, just to have a lot of vendor-specific, non-compliant facebook crap. Which makes it roughly like every other site on the internet) |
| 21:32 | <jgraham> | (to be fair it is not just facebook, there are several species of pseudo-namespaces living there) |
| 21:32 | <BenoitRen> | jgraham: It is fake XHTML. It's not sent as application/xhtml+xml, it has xmlns and rogue slashes, plus CDATA nonsense in JavaScript so an XML parser wouldn't barf on it. |
| 21:33 | <jgraham> | The rouge slashes are silly but allowed per spec |
| 21:33 | <BenoitRen> | jgraham: As for standards compliance, accessibility and using HTML semantically are part of standards compliance as defined by the W3C. |
| 21:33 | <jgraham> | The xmlns isn't for XHTML |
| 21:33 | <gsnedders> | @xmlns is allowed on the root element too, per spec. |
| 21:34 | <jgraham> | gsnedders: Not like this |
| 21:34 | <gsnedders> | But this isn't @xmlns |
| 21:34 | <gsnedders> | This is @xmlns:fb |
| 21:34 | <BenoitRen> | xmlns is an XML construct that's often used in XHTML, because XHTML is HTML in XML form. |
| 21:35 | <jgraham> | BenoitRen: you haven't explained why it is inaccesible. I see it using lots of divs for layout but lots of elements with more specific semantics in mostly OK ways |
| 21:35 | <BenoitRen> | Hence anyone who tries to use it in a web page is implicitly trying to write XHTML. |
| 21:35 | <gsnedders> | BenoitRen: Or trying to write RDFa. |
| 21:36 | <jgraham> | BenoitRen: In this case they are trying to do whatever they have to do to get the addthis script to work |
| 21:36 | <jgraham> | Which appears to involve some gunk involving the string "xmlns" but otherwise be entirely unconnected to XHTML |
| 21:36 | <jgraham> | It doesn't even look much like RDFa |
| 21:37 | <BenoitRen> | jgraham: <div>Written by: <a href="http://mozilla-antarctica.org/author/JanB/"; title="Posts by Jan" rel="author">Jan</a></div> |
| 21:38 | <gsnedders> | fb:like:layout is invalid in both XHTML and RDFa and just bizzare. |
| 21:38 | <gsnedders> | BenoitRen: How does that div cause any problem for AT? |
| 21:38 | <BenoitRen> | gsnedders: That's an example of divitis. The div element is abused there. |
| 21:39 | <jgraham> | Yeah it's not ideal but I doubt it would make a practical difference in any UA to spell <div> <p> in that case |
| 21:40 | <BenoitRen> | <div><p>? Replacing div by p would be enough. |
| 21:40 | <BenoitRen> | It's a piece of text. |
| 21:40 | <BenoitRen> | div is meant to make sections of block-level elements. |
| 21:40 | <BenoitRen> | Text is not a block-level element. |
| 21:42 | <jgraham> | That is almost, but not quite entirely, unlike what the spec says |
| 21:43 | <jgraham> | "The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements." |
| 21:43 | <hober> | s/ entirely,/, entirely/ |
| 21:43 | <gsnedders> | hober: The two statements are both grammatically possible, though semantically different. |
| 21:43 | <gsnedders> | hober: I expect jgraham meant what he wrote. |
| 21:44 | <jgraham> | hober's sentence is closer to H2G2 though |
| 21:44 | <jgraham> | Which is really what I meant |
| 21:45 | <jgraham> | (at least if wikipedia managed to copy it correctly) |
| 21:45 | gsnedders | remembers jgraham saying that he would lend him And Another Thing… a while ago. |
| 21:46 | <gsnedders> | But seeming I live in another country now that seems mostly irrelevant. |
| 21:54 | <bga> | http://common-lisp.net/project/closure/ |
| 22:13 | <BenoitRen> | Does narration count as a different voice or tone for which the i element would be used? |
| 22:13 | <BenoitRen> | I imagine it's similar to stage directions, which are used with it. |
| 22:24 | <erlehmann> | BenoitRen, then upgrade your browser. |
| 22:24 | <BenoitRen> | erlehmann: ? |
| 22:24 | <erlehmann> | 22:18 <BenoitRen> When I look at my Error Console I wonder22:18 <BenoitRen> When I look at my Error Console I wonder who had the bright idea of reporting every use of vendor-prefixed CSS as a warning. |
| 22:24 | <erlehmann> | sorry, pastefail |
| 22:25 | <BenoitRen> | erlehmann: Does the latest version no longer do that, or something? |
| 22:25 | <erlehmann> | BenoitRen, does the latest version support more CSS? |
| 22:26 | <BenoitRen> | erlehmann: A little bit, I guess. I'm really most annoyed at the warnings about vendor-specific CSS, though. |
| 22:26 | <BenoitRen> | erlehmann: I don't think it supports box-shadow and other CSS3 friends, though. |
| 22:27 | <erlehmann> | BenoitRen, vendor-specific CSS is not good. stop using it. |
| 22:27 | <BenoitRen> | erlehmann: There's no other option if you want rounded corners in all web browsers. |
| 22:28 | <erlehmann> | BenoitRen, then you *don't* want that. let it degrade gracefully instead. |
| 22:28 | <BenoitRen> | erlehmann: I think you'll have a hard time selling that to your employers... |
| 22:29 | <zewt> | non-real-world viewpoints detected |
| 22:29 | <BenoitRen> | erlehmann: I don't see the problem as long as you include the standards compliant version so things will still look the same when the browsers do support CSS3 better. |
| 22:29 | <erlehmann> | BenoitRen, I am not an expert on the topic of “selling” but there are things a dev should not do. |
| 22:30 | <zewt> | and using vendor css is not one of them |
| 22:30 | <erlehmann> | BenoitRen, that is one acceptable thing. |
| 22:30 | <jarek> | Hello |
| 22:30 | <Philip`> | Yeah, you certainly shouldn't try to solve your customer's/employer's real problems, and you should focus on hypothetical future concerns instead |
| 22:30 | <roc> | this entire mini-thread is an excellent case study of why Henri is right and vendor prefixes can't work |
| 22:30 | <erlehmann> | roc, what does Henri say? |
| 22:31 | <jarek> | why do we have to use document.createElementNS() in order to create SVG element in HTML5? |
| 22:31 | <jarek> | it doesn't make sense, HTML has no namespaces |
| 22:31 | <erlehmann> | jarek, broblem? |
| 22:31 | <BenoitRen> | jarek: I'd imagine because SVG is XML-based. |
| 22:31 | <Hixie> | jarek: DOM has namespaces |
| 22:31 | <jarek> | BenoitRen: but document.createElementNS() belongs to HTML document :/ |
| 22:31 | <roc> | http://hsivonen.iki.fi/vendor-prefixes/ |
| 22:31 | <Hixie> | jarek: technically HTML has namespaces too, it's text/html that doesn't have them |
| 22:32 | <jarek> | if it's not required to specify namespace in markup, why should it be necessary when creating elements via JavaScript? |
| 22:32 | <heycam|away> | I would love it if createElement("svg") would work -- but I have a feeling we can't do that |
| 22:33 | <BenoitRen> | Hixie: Could you please enlighten me for a second by telling me if it's appropriate to use the q element for character lines spoken in a fan fiction story? |
| 22:33 | <BenoitRen> | Hixie: The spec is ambiguous. |
| 22:33 | <BenoitRen> | jarek: Because JavaScript interacts with the DOM, I think. |
| 22:33 | <Hixie> | jarek: so we know which namespace to put it in (in text/html, you specify the namespace too, by using certain elements before the others) |
| 22:34 | <Hixie> | BenoitRen: i would just use quote marks |
| 22:35 | <Hixie> | BenoitRen: <q> is supposed to be for specifically quoting another source |
| 22:35 | <jarek> | Hixie: but SVG element names don't clash with HTML or MathML element names, this seems to unnecessary |
| 22:35 | <Hixie> | jarek: sure they do |
| 22:35 | <jarek> | s/to/to be |
| 22:35 | <Hixie> | jarek: <a>, for example |
| 22:35 | <BenoitRen> | Hixie: Okay. Should I file a bug then about the spec? Because I don't think the spec makes this clear enough, specificially in the examples. |
| 22:35 | <jarek> | ahh... right... |
| 22:35 | <BenoitRen> | *specifically |
| 22:36 | <Hixie> | BenoitRen: if you think it's important, sure |
| 22:36 | <BenoitRen> | Hixie: I think an unambiguous spec is important. :) Thanks! |
| 22:38 | <jgraham> | """Meanwhile, to the people who think the solution is for Mozilla and others to just "work harder" at evangelism, or implementation, or standards work --- I cast aspersions in your direction. You have no idea how hard we work.""" - roc, you are awesome |
| 22:39 | <jgraham> | (for saying that rather than for how hard you work) |
| 22:39 | <jgraham> | (although I don't dobt you work hard :) |
| 22:39 | <erlehmann> | I would like to see the strategic papers of the WebKit dev people. |
| 22:39 | <roc> | there aren't any |
| 22:39 | <roc> | there's no conspiracy |
| 22:40 | <roc> | they're even good people |
| 22:40 | <erlehmann> | roc, then it's worse than I thought :( |
| 22:40 | <jamesr_> | WebKit isn't even one thing in this discussion |
| 22:40 | <roc> | it's just market forces at work |
| 22:40 | <jamesr_> | we (chrome) have to reverse-engineer the implementaiton of -webkit- prefixed things to ship |
| 22:40 | <jamesr_> | the main difference for us is we don't have the same moral issues with shipping a -webkit- prefixed implementation of something that, say, a firefox or IE would |
| 22:41 | <jamesr_> | maybe that's wrong |
| 22:41 | <erlehmann> | jamesr_, aren't you using webkit? why reverse-engineer then? |
| 22:41 | <jamesr_> | but when you see webkit vendor prefixes sometimes it means that all webkit-based browsers share an implementation, and sometimes they're totally differen |
| 22:41 | <jamesr_> | erlehmann, the implementation isn't always in WebKit proper |
| 22:41 | <erlehmann> | lesson learned: if you ship stuff in a broken state, support it forever. |
| 22:41 | <jamesr_> | for example 3d transforms - the parsing and some of the logic is in webkit, but all of the rendering stuff we've had to reverse-engineer and reimplement something that kind of sort of matches CoreAnimation |
| 22:41 | <jamesr_> | just like everyone else |
| 22:41 | <jgraham> | s/in a broken state/ |
| 22:42 | <jgraham> | The rule is "if you ship stuf everyone has to deal with the legacy you create" |
| 22:43 | <roc> | it's certainly true that Webkit browser companies could have done, and still could do, a lot more to support the open Web |
| 22:43 | <roc> | but it's not surprising that they haven't, or even wrong really |
| 22:44 | <erlehmann> | roc, wrong in a moral sense? |
| 22:44 | <jgraham> | It's not really in their best interests. And it is very easy to ignore stuff that isn't in your best interests when you are being praised for it. |
| 22:45 | <erlehmann> | hehe |
| 22:45 | <erlehmann> | then it may be good that people are creating awareness |
| 22:45 | <jgraham> | Creating awareness of what? |
| 22:46 | <jgraham> | So far the message that I have got is that Mozilla + Opera + Microsoft are evil for wanting content to work in their browsers |
| 22:46 | <jgraham> | That's not a message I care to endorse |
| 22:47 | <jamesr_> | discussions centered around who is and isn't being evil are safe to ignore |
| 22:47 | <jamesr_> | nothing productive comes out of them |
| 22:49 | <jgraham> | If only the chair of the CSS WG shared that opinion |
| 22:49 | <roc> | erlehmann: what, if anything, "morally" means for a company is a really hard question. Certainly I find it hard to single out Apple and Google as morally wrong for doing whatever's legal to maximize their profits, which is our current legal environment says they are obliged to do |
| 22:49 | <jamesr_> | jgraham, in this instance i think the chair can be ignored |
| 22:50 | <roc> | if only |
| 22:50 | <roc> | our press people are being bombarded |
| 22:50 | <erlehmann> | roc, in german we call this „rechtspositivismus“ and do not hold this position in high regard |
| 22:50 | <erlehmann> | (at least that's what i got from my history lessons) |
| 22:51 | <erlehmann> | roc, advocating that what a company is doing is legal does not solve any moral problem. |
| 22:51 | <erlehmann> | next up: don't hate webkit because it's so successful ;) |
| 22:57 | <roc> | Oh, I don't think everything legal is moral. I'm a Christian, I think tons of legal things are immoral. But the change that's needed is much more than just telling companies they should behave morally. They need to be reprogrammed with different goals. |
| 23:00 | <roc> | I disagree with jamesr_ on one thing though, which is that something productive can come of talking about who's evil. Namely, a lot of people don't like working for evil companies, and we can use that to put them at a hiring disadvantage. |
| 23:02 | <erlehmann> | a *lot* of people? color me surprised. |
| 23:02 | jgraham | notes for posterity that he agrees with the entire line starting "Oh, I don't think", with the single change s/a Christian/an atheist/ |
| 23:03 | <erlehmann> | hehe |
| 23:03 | <roc> | put it this way, we don't hire a lot of great people at Mozilla because of the stock options |
| 23:03 | <gavin> | let the offical record reflect that I also concur |
| 23:04 | <jamesr_> | it can be a factor. there aren't many people who you would want to influence in this way to begin with. it's not immediately useful for changing the CSS WG policies, though |
| 23:04 | <jgraham> | erlehmann: Yeah, I think there is a large set of people that would be loathe to work at a company they didn't believe in |
| 23:04 | <Philip`> | Dungeon Keeper has taught me that evil is fun, so I'd only want to work for evil companies |
| 23:05 | <jgraham> | jamesr_: I'm not sure what is useful for changing their policy |
| 23:06 | <jgraham> | To my eyes they are clinging to a comforting fiction in the face of stark evidence it is wrong |
| 23:06 | <jamesr_> | they = us, for many of us anyway |
| 23:07 | <jamesr_> | CSS WG = browser vendors, web developers and other interested parties |
| 23:07 | <jgraham> | Well sure |
| 23:07 | <roc> | none of the browser vendors are arguing against supporting -webkit prefixes, not even you or Apple |
| 23:09 | <Hixie> | roc: maximising profits isn't, as far as i can tell, a legal requirement. (If it was, why would companies be giving profits away to charity all the time, even beyond any possible tax benefit?) |
| 23:09 | <roc> | it's Web devs and standardistas who are agains tit |
| 23:09 | <erlehmann> | :/ |
| 23:09 | <roc> | Hixie: companies justify it as buying goodwill/PR |
| 23:09 | <jamesr_> | roc, you mean arguing against webkit-derived browsers supporting -webkit prefixes, or all browsers supporting -webkit? |
| 23:09 | <roc> | all |
| 23:10 | <Hixie> | roc: some may |
| 23:10 | <jgraham> | roc: It is much less clear that people from web browsers (including Opera) are in favour of dropping the prefix system entirely |
| 23:10 | <jamesr_> | in the US public companies are required to do what they promise to do in their filing documents |
| 23:10 | <roc> | jgraham: indeed |
| 23:10 | <jamesr_> | which may or may not be maximizing shareholder profit (it often is, but you can create a public company with another goal and be safe against shareholder suits for failing to maximize profits if you can show that you never said you would) |
| 23:12 | <jamesr_> | it's a common misconception that it's illegal to fail to maximize profits |
| 23:13 | <gsnedders> | Mozilla Corp. is wholly owned by the Foundation, right? |
| 23:13 | <gavin> | yes |
| 23:14 | <roc> | ok then |
| 23:14 | <roc> | I take it back |
| 23:14 | <roc> | Apple and Google are evil for prioritizing profits over the open Web |
| 23:15 | <BenoitRen> | I just read almost all of that weblog post about vendor prefixes. Phew. |
| 23:15 | <jamesr_> | this is where i have a problem, the discussion is starting out in a way that it can't end up productively |
| 23:15 | <BenoitRen> | I think he has some good points, but no, the box models should not have been changed to IE's. |
| 23:15 | <BenoitRen> | *box model |
| 23:16 | <jarek> | I hope that the vendor prefix madness will get even worse |
| 23:17 | <jarek> | ... because I'm developing CSS ide that will be inserting them automatically |
| 23:17 | <erlehmann> | perverse incentices |
| 23:18 | <jgraham> | jarek: Man, I hadn't even thought about tool vendors as a constituent. No wonder Glazou wants to keep them so badly ;) |
| 23:18 | <jarek> | at some point it will be possible to write CSS by hand, they will have to buy my product :P |
| 23:18 | <jarek> | s/possible/impossible |
| 23:19 | <jarek> | jgraham: Glazou is the author of BlueGriffon, right? |
| 23:19 | <jgraham> | yup |
| 23:19 | <roc> | the conspiracy unmasked! |
| 23:21 | <jamesr_> | roc, i think it's a mistake to try to start a conversation with accusations and blame |
| 23:21 | <roc> | I didn't |
| 23:21 | <jamesr_> | ok, it's a mistake to put it in the middle of a conversation then |
| 23:21 | <roc> | http://robert.ocallahan.org/2012/02/alternatives-to-supporting-webkit.html no accusations, no blame |
| 23:22 | <roc> | apart from the people saying we should just work harder --- they suck |
| 23:23 | <roc> | and that dig at Apple I guess, but that's just fact |
| 23:23 | <jarek> | what about this idea https://news.ycombinator.com/item?id=3570609 |
| 23:24 | <jarek> | "Evangelize Web developers to not use prefixed properties on production sites." |
| 23:24 | <roc> | I used to think the "common prefix" approach was dumb, but I'm gradually warming to it |
| 23:24 | <erlehmann> | jarek, implying anyone would write a draft before implementing? |
| 23:24 | <roc> | it might add some value |
| 23:24 | <erlehmann> | i thing it is dump. |
| 23:24 | <erlehmann> | dumz |
| 23:24 | <erlehmann> | dumb |
| 23:24 | <erlehmann> | right key. |
| 23:24 | <jarek> | I doubt anyone could convince me to drop vendor prefixes, there are too awesome |
| 23:24 | <roc> | not as good as "experimental features off by default in release builds" though |
| 23:24 | <jarek> | s/there/they |
| 23:25 | <erlehmann> | jarek, too awesome? |
| 23:25 | <erlehmann> | roc, I think “experimental features off by default” is something that would be nice. |
| 23:25 | <jgraham> | jarek: That isn't substantially better. It makes it easier for multiple people to implement prefixed stuff without having to fight tedious political battles, but as long as there is content that depends on -dev- then it still creates a legacy of undocumented features that the WG feel they can ignore |
| 23:25 | <gsnedders> | roc: Need to drop prefixes more quickly though relaly. |
| 23:25 | <gsnedders> | roc: (for that to work) |
| 23:26 | <jarek> | erlehmann: yeah, especially the stuff that landed in WebKit recently (filters, shaders) |
| 23:26 | <gsnedders> | But basically I think we should drop prefixes more quickly and have prefixed stuff off by default |
| 23:26 | <erlehmann> | jarek, I bet you also use IE filters. |
| 23:26 | <erlehmann> | gsnedders, i concur |
| 23:26 | jgraham | doesn't see how you will get people to agree to turn prefixed stuff of by default |
| 23:26 | <jarek> | erlehmann: only for gradients... |
| 23:26 | <jgraham> | *off |
| 23:26 | <jgraham> | It just doesn't align with their incentives |
| 23:26 | <erlehmann> | jarek, oh you |
| 23:27 | <erlehmann> | jgraham, one can still propose it. |
| 23:28 | <jgraham> | erlehmann: One can propose that we depend on FTL travel to violate causality and so get standards based on implementations before the implementations ship. It won't happen though. |
| 23:28 | <karlcow> | jarek: awesome in which ways? Are we not sometimes into "CSS Otaku", attracted by the last feature because it is our domain but the majority of users don't give a shit. |
| 23:28 | <roc> | sometimes we can persuade browser vendors to do things that don't align with their incentives |
| 23:28 | <erlehmann> | jgraham, you so negative |
| 23:28 | <roc> | Web authors are hopeless because there are too many of them |
| 23:28 | <erlehmann> | karlcow, harr harr |
| 23:28 | <jgraham> | roc: It is easier, I grant you |
| 23:28 | <roc> | for browsers, there's really only a small number of people who need to be persuaded |
| 23:28 | <erlehmann> | roc, i believe it when apple does vorbis ;) |
| 23:28 | <roc> | *sometimes* |
| 23:29 | <gsnedders> | erlehmann: Not everything is equally easy to persuade. |
| 23:29 | <jgraham> | roc: If you can get people to agree to never ship experimental stuff by default then I won't stand in your way |
| 23:29 | <roc> | also, the vast majority of browser developers are really excellent people, we have personal contacts, and so forth |
| 23:29 | <erlehmann> | gsnedders, i have no idea where to even start. |
| 23:29 | <jgraham> | Indeed I will be both ha[[y and impressed |
| 23:29 | <jgraham> | *happy |
| 23:29 | <roc> | jgraham: will you join in? |
| 23:29 | <erlehmann> | roc, “excellent people” is a null information. :/ |
| 23:30 | <jgraham> | But I predict they will argue that shipping stuff by default is needed to get large scale feedback |
| 23:30 | <roc> | we can try |
| 23:30 | <roc> | I'm actually in favour of shipping stuff by default, but off by default behind about:config or similar |
| 23:30 | <jgraham> | and will be under pressure from their marketing people to ship stuff on by default for PR reasons |
| 23:31 | <gsnedders> | (e.g., shipping first) |
| 23:31 | <zewt> | ... which i'd agree with; even on hobby sites i'd very rarely bother trying any API that isn't enabled on browsers by default |
| 23:31 | <jgraham> | Right "by default" I mean "on in the default config" |
| 23:31 | <roc> | Tab said he was in favour of this |
| 23:32 | <gsnedders> | roc: I think you'll find most engineers in favour of it. Whether that's enough is a different question. |
| 23:32 | <roc> | I don't know if it was discussed on webkit-dev. If there was agreement there, I'm pretty sure it would fly with Mozilla |
| 23:32 | <roc> | TabAtkins: ^^^ |
| 23:32 | <jgraham> | It's not webkit-dev I am mostly worried about. It's pr⊙ac and similar |
| 23:33 | <erlehmann> | well, engineers. aren't that the guys who also use RF codecs? ;) |
| 23:33 | <erlehmann> | what jgraham said with less bitterness |
| 23:33 | <roc> | I think we're going to do it anyway where there isn't competitive pressure, like our new SVG Opentype fonts work |
| 23:34 | <jgraham> | roc: Great :) |
| 23:34 | <jgraham> | It is a little past my bedtime... |
| 23:34 | jgraham | -> sleep |
| 23:36 | <karlcow> | ah jgraham going to his -bedkit- |
| 23:40 | <BenoitRen> | So we're going to have websites who tell users to enable something in about:config to have some whiz-bang CSS work. |
| 23:41 | <bga> | heh you spawn new ie6 and now want to fight against it's monopoly |
| 23:42 | <jarek> | + afaik there is no about:config in IE10 |
| 23:42 | <jarek> | btw, what's the stance of Microsoft on this issue? |
| 23:42 | <jarek> | they have implement a lot of -ms-* properties in IE10 |
| 23:42 | <roc> | BenoitRen: they can try that, but it probably won't work for most users, so sites wouldn't be able to rely on it |
| 23:44 | <BenoitRen> | Sites will just add more instructions for other browsers, like they already do for cookies, for example. |
| 23:44 | <erlehmann> | hell, not even „install a browser that can play h.264“ works |
| 23:44 | <erlehmann> | people just leave the site |
| 23:44 | <BenoitRen> | "PLEASE ENABLE COOKIES OUR WEB DEVELOPERS WERE TOO DUMB TO HAVE THE SITE WORK WITHOUT" |
| 23:45 | <BenoitRen> | erlehmann: Of course not. That's too vague. ;) |
| 23:45 | <jamesr_> | roc, we'd like to ship things only to our canary+dev channels and off in beta+stable |
| 23:45 | <BenoitRen> | But if people really want to see the dancing bunnies, they /will/ see the dancing bunnies! |
| 23:45 | <erlehmann> | BenoitRen, cookies are entrenched. also, round up those web devs and give them a scornful speech! |
| 23:46 | <roc> | jamesr_: maybe if just you guys and us and Opera agree, that's enough |
| 23:46 | <roc> | Apple and IE are less of a problem because of their slower update cycle |
| 23:47 | roc | wonders what the right way is to organize this |
| 23:47 | <BenoitRen> | erlehmann: If only I could. I once phoned a webshop's customer service to complain about their user agent sniffing that meant that some critical JavaScript wasn't provided. I couldn't even get the idiot to forward my complaint to the web developers; he was convinced that my browser was the problem. |
| 23:48 | <jamesr_> | roc, we have to get buy-in from apple on these sorts of things |
| 23:48 | <jamesr_> | i think they're a little less convinced of the channel idea |
| 23:48 | <jamesr_> | (since they have no such concept) |
| 23:48 | <jamesr_> | but maybe |
| 23:48 | <erlehmann> | BenoitRen, my provider sends mystery RST packets and they blamed the kernel of my device. |
| 23:48 | <jamesr_> | roc, note when i say "we" i mean "some of us" |
| 23:48 | <jamesr_> | we aren't a monolithic bloc in lockstep |
| 23:48 | <erlehmann> | jamesr_ i have said it before and i'll say it again: safari [mobile] is the new IE6 |
| 23:48 | <jamesr_> | just like mozilla isn't, and just like apple isn't |
| 23:48 | <roc> | Webkit allows you to enable/disable experimental features, so I guess technically it's possible |
| 23:48 | <roc> | and Safari lags behind because of the update schedule anyway |
| 23:49 | <jamesr_> | webkit controls a lot of stuff with compile-time switches |
| 23:49 | <roc> | but I understand |
| 23:49 | <roc> | that's why I wondered if there was a webkit-dev discussion last time Tab raised this |
| 23:52 | <jamesr_> | and there's a genuine concern about landing code for features that they feel uneasy about even if we promise to restrict to some channels |
| 23:54 | <roc> | not sure I follow |
