| 02:28 | <othermaciej> | just waiting on html4diffs and h:tml to be updated now |
| 02:33 | <MikeSmith> | othermaciej: I just now updated the h:tml draft and waiting for the cvs commit to complete |
| 02:33 | <MikeSmith> | oK |
| 02:33 | <MikeSmith> | done |
| 02:33 | <othermaciej> | MikeSmith: hawt |
| 02:33 | <othermaciej> | MikeSmith: so now we're just waiting on Anne |
| 02:33 | <MikeSmith> | OK |
| 02:34 | <MikeSmith> | annevk still awake? |
| 02:34 | <othermaciej> | I asked him to update earlier today, so hopefully he'll do it whenever he gets up |
| 02:34 | <othermaciej> | I am assuming no |
| 02:34 | <othermaciej> | I asked him to update ~5 hours ago |
| 02:35 | <othermaciej> | even though it is an arbitrary milestone, I am for some reason very excited about publishing |
| 02:39 | <MikeSmith> | othermaciej: I think the biggest positive effect of WD publication is that it gets documents a lot wider attention than just editor's-draft publication does |
| 02:40 | <MikeSmith> | at least as far as W3C publication goes |
| 02:40 | <MikeSmith> | and for a certain period of time, at least |
| 02:40 | <othermaciej> | in the context of HTML5, I have not seen it result in a higher level of technical review |
| 02:40 | <MikeSmith> | yeah |
| 02:40 | <othermaciej> | though it does get some sort of attention in the tech press |
| 02:42 | <MikeSmith> | othermaciej: yeah, the downside of that is that one of the first questions all the media people seem to ask every time W3C publishes and HTML5 WD is that, "OK, so when will HTML5 be done?" question |
| 02:43 | <MikeSmith> | to which it seems to me the only proper response is to try to get them to see that they're asking the wrong question |
| 02:43 | <MikeSmith> | but that's not usually successfull |
| 02:43 | <othermaciej> | then we can just point to the charter and indicate that the next milestone is Last Call |
| 02:43 | <othermaciej> | which is on schedule, so long as we can invent time travel technology in the next few months |
| 02:43 | <MikeSmith> | heh |
| 02:45 | <Hixie> | the ietf guys argued that websocket would get wider review if we went through the ietf, but so far all the useful feedback i've received has been either off-list or on the whatwg list |
| 02:46 | <Hixie> | similar to how it was argued that html5 would get more review if we went through the w3c |
| 02:46 | <Hixie> | looks to me like the standards organisations are out of date in terms of what gets wider useful feedback :-) |
| 02:47 | <othermaciej> | Hixie: I sent useful feedback on the ietf list... I think |
| 02:48 | <Hixie> | i think everything you said on the list you first said on the adam/you/me thread we had |
| 02:48 | <Hixie> | and adam and you would have reviewed the spec anyway, regardless of whether we went w3c, whatwg, or ietf |
| 02:48 | <othermaciej> | nah, I pointed out the reverse cross-protocol problem on the list first, then discussed it with you on IRC, then on the email thread with Adam |
| 02:48 | <othermaciej> | I would like to say I would have given that feedback anyway but I only thought of it due to people questioning the handshake |
| 02:49 | <Hixie> | fair enough |
| 02:49 | <MikeSmith> | Hixie: standards organizations are out of date in a lot of ways.. I guess until we actually work on coming up with viable alternative, we are stuck with what we got, and hopefully at least we can (or have) managed to get some improvements made |
| 02:49 | <othermaciej> | I mean, I might have still had the thought |
| 02:50 | <Hixie> | MikeSmith: my most successful standard i think has been pingback, which didn't involve a standards organisation at all |
| 02:50 | <othermaciej> | it's not clear to me how to make a good standards org |
| 02:50 | <Hixie> | MikeSmith: so it's not clear to me that we _need_ an alternative |
| 02:50 | <MikeSmith> | I think the existence of the Web Sockets discussion at IETF has helped to changed the IETF culture for the better |
| 02:50 | <othermaciej> | all the existing ones either come down to pay-to-play voting or dictatorship by an elite oligarchy, if you push hard enough |
| 02:51 | <Hixie> | really? how so? |
| 02:51 | <Hixie> | er, that was to mike |
| 02:51 | <Hixie> | othermaciej: i think the oligarchy mechanism is the only one that truly works, but it only works so long as the oligarchy has the respect of the implementors |
| 02:52 | <Hixie> | othermaciej: and i think it pretty much stops having the respect as soon as there's a process in place, because a process forcibly distances the oligarchy from the implementors |
| 02:52 | <Hixie> | part of the problem the w3c and ietf both have is that they try to solve too many problems at once |
| 02:52 | <Hixie> | having multiple focus areas is a huge red flag for a std org imho |
| 02:52 | <MikeSmith> | Hixie: I think the implementors issue is something that the Web Sockets work has helped to raise awareness about in the IETF |
| 02:53 | <othermaciej> | oligarchy can work with the right oligarchs |
| 02:53 | <othermaciej> | and so long as it does not get overwhelmed with legitimacy disputes |
| 02:53 | <Hixie> | legitimacy disputes = lack of respect |
| 02:54 | <MikeSmith> | Hixie: the awareness being that it is risky to develop a spec without also working hard to get implementor buy-in during the spec-development process |
| 02:54 | <othermaciej> | IETF and W3C try to have consensus/voting as the front line decision-making tool, with escalation to a dictator/oligarchy |
| 02:54 | <othermaciej> | sometimes I wonder if the other way around would work better |
| 02:54 | <othermaciej> | of course, in the HTML WG we kinda have a sandwich |
| 02:54 | <Hixie> | not really |
| 02:55 | <Hixie> | we just have three tiers of <span>abort the |
| 02:55 | <Hixie> | er |
| 02:55 | <Hixie> | mispaste |
| 02:55 | <Hixie> | we just have three tiers of oligarchy |
| 02:55 | <othermaciej> | I guess layers at least limit the damage that can be done by any one layer going off the rails |
| 02:56 | <Hixie> | each tier being further removed from the issues, leading to more and more random resolutions as an issue is escalated ;-) |
| 02:57 | <othermaciej> | I find I need to have a lot more familiarity with the issues than I think I should have to for my role |
| 02:58 | roc | wonders what Apple's Webkit devs are doing |
| 02:58 | <othermaciej> | right now? |
| 02:58 | <othermaciej> | most of them are either at home, or having dinner |
| 02:59 | <Hixie> | roc: i think he means his role as htmlwg chair, not webkit manager :-P |
| 02:59 | <othermaciej> | oh |
| 02:59 | <othermaciej> | yeah |
| 02:59 | <roc> | no, my comment was random |
| 02:59 | <MikeSmith> | heh |
| 03:01 | <othermaciej> | trac would give you a good approximation if you can filter down to Apple committers |
| 03:01 | <roc> | indeed |
| 03:01 | <MikeSmith> | webkit devs seem to be doing a lot of bug fixing these days, as opposed to feature implementation |
| 03:02 | <othermaciej> | MikeSmith clearly reads the webkit commits twitter feed |
| 03:03 | <MikeSmith> | I do notice that Dirk Schulze seems to still be actively been doing some refinements to the svg filters stuff |
| 03:05 | <MikeSmith> | I wish trac had a better way to track commits per-developer |
| 03:06 | <MikeSmith> | per-committer feeds |
| 03:06 | <Hixie> | i wish trac had a lot of things |
| 03:12 | <MikeSmith> | Hixie: who's developed the http://html5.org/tools/web-apps-tracker UI, annevk ? |
| 03:12 | <Hixie> | yes |
| 03:12 | <Hixie> | iirc |
| 03:12 | <Hixie> | at last he hosts it |
| 03:12 | <MikeSmith> | OK |
| 03:12 | <Hixie> | it's in google code if you want to offer patches |
| 03:12 | <Hixie> | product html5, iirc |
| 03:12 | <MikeSmith> | OK |
| 03:13 | <MikeSmith> | I would like for it to have a feature that lets users supplement that indicators |
| 03:13 | <roc> | man, the per-platform test results make Webkit SVN enormous |
| 03:30 | <Hixie> | ok, bbl, food time. |
| 03:30 | <Hixie> | if anyone wants to review proposals for websocket, i just regenned the complete.html spec with the new proposed handshake |
| 05:32 | <MikeSmithX> | Hixie: (when you get back) - I'm wondering if you made any changes at all in response to Noah's message about explicitly defining the term "conforming document" - http://lists.w3.org/Archives/Public/public-html-comments/2010Feb/0011.html |
| 05:54 | <MikeSmith> | othermaciej: I think at some point we should publish a WD of the static "author view" of HTML5 |
| 05:54 | <MikeSmith> | http://dev.w3.org/html5/spec-author-view/ |
| 05:54 | <othermaciej> | MikeSmith: I agree |
| 05:55 | <othermaciej> | MikeSmith: should it still have all the trappings of normativity? |
| 05:55 | <MikeSmith> | that part I dunno |
| 05:55 | <othermaciej> | I feel weird having multiple normative references for the same thing even if they are mechanically generated from a single source |
| 05:55 | <othermaciej> | but other than that - we did suggest to the TAG that we'd like to do this |
| 05:55 | <MikeSmith> | and that TAG seems to actually like that doc OK |
| 05:56 | <MikeSmith> | Noah at least does, I know |
| 05:56 | <MikeSmith> | well, I guess I shouldn't say "I know", but I think he has publicly commented quite positively |
| 05:57 | <MikeSmith> | anyway, I suppose we should start discussion about publishing after we get the current round of WDs out |
| 05:57 | <MikeSmith> | *publishing the author view |
| 05:58 | <othermaciej> | yeah I'd like to get the current round done |
| 05:58 | <othermaciej> | and get more issues in the pipeline |
| 05:58 | <othermaciej> | we have 10 sitting on "Chairs" now |
| 06:04 | <MikeSmith> | othermaciej: I also have a couple of bugzilla bugs assigned to me that have not been escalated to issues yet and that I'm hoping won't have to be |
| 06:05 | <MikeSmith> | hmm, http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Mar/0008.html |
| 06:05 | <MikeSmith> | "Can the script element please allow the scope attribute in the same semantic way as the style element? The dom would be limited to only elements under that node." |
| 06:06 | <othermaciej> | interesting idea |
| 06:06 | <othermaciej> | hard to implement and use |
| 06:06 | <othermaciej> | probably not viable as as a security feature, if that is what the commentor intends |
| 06:13 | <MikeSmith> | not sure what the commenter intends -- the embedded commenting feature is great for reporting outright bugs but doesn't encourage a lot of elaboration |
| 06:36 | <hsivonen> | Hixie: so your most successful spec depends on xml-rpc! |
| 07:03 | <MikeSmith> | hsivonen: which one is that? |
| 07:06 | <Hixie> | MikeSmith: i don't think so... did he file a bug? |
| 07:07 | <MikeSmith> | Hixie: no, he didn't.. I can suggest to him that he should, or I can file one myself, I guess. He just posted only to the public-html-comments list about it, as far as I can see |
| 07:07 | MikeSmith | goes to raise new bug for it |
| 07:07 | <hsivonen> | MikeSmith: pingback according to the log |
| 07:08 | <MikeSmith> | ah |
| 07:08 | <Hixie> | hsivonen: yeah, that's embarassing as heck :-) |
| 07:13 | <annevk> | MikeSmith, I'll update nowish I guess |
| 07:13 | annevk | is trying to wake up |
| 07:13 | <MikeSmith> | annevk: great |
| 07:13 | annevk | has a headache for unknown reasons |
| 07:13 | annevk | wonders if it's because the heating is working again and his body is no longer used to the warmth |
| 07:14 | <MikeSmith> | Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9178 (new bug for defining "conforming document") |
| 07:14 | <MikeSmith> | btw, I notice that pubrules still doesn't recognize CSS3 color names |
| 07:15 | <MikeSmith> | I would say, "That seems like it would be relatively easy to fix" but if I did I would probably get asked to fix it |
| 07:26 | <MikeSmith> | othermaciej: I guess one advantage of publishing the author view of the spec as non-normative would be that we'd not need to do an LC round for it |
| 07:26 | <MikeSmith> | nor CR |
| 07:26 | <othermaciej> | MikeSmith: we'd probably want to anyway, to let it stay in sync with the main HTML5 draft |
| 07:26 | <MikeSmith> | yeah, true |
| 07:27 | <MikeSmith> | no, not true |
| 07:27 | <othermaciej> | MikeSmith: how hard do you think it would be to get pubrules changed to allow HTML5 as a publication format? |
| 07:27 | <othermaciej> | I periodically have the urge to try to pursue that, but I am not sure if it is worth my time |
| 07:27 | <MikeSmith> | pubrules would be relatively easy to change, actually |
| 07:28 | <MikeSmith> | it's not a technical problem that blocks that |
| 07:28 | <othermaciej> | I didn't mean "how technically hard" |
| 07:28 | <MikeSmith> | well, not hard, then |
| 07:28 | <othermaciej> | I mean, "If I suggested it, is there a chance I'd get anywhere?" |
| 07:28 | <MikeSmith> | I meant, "well, hard, then" |
| 07:28 | <othermaciej> | and if so, what would be the right venue |
| 07:28 | <othermaciej> | should I ask privately what the actual blocker is? |
| 07:29 | <MikeSmith> | no need to ask privately |
| 07:29 | <othermaciej> | what's the actual blocker? |
| 07:30 | <othermaciej> | I wondered if maybe there was some idea that a format spec had to be at REC before it could be used, but I notices that even Working Drafts of XHTML1 were published as XHTML1, not as HTML4 |
| 07:30 | <MikeSmith> | the blocker is that the team doesn't believe it's appropriate yet to be publishing documents that use features from HTML5 that are not at least in a PR draft |
| 07:30 | <othermaciej> | so it doesn't seem like there is a hard and fast rule |
| 07:30 | <MikeSmith> | as far as XHTML1 and HTML4, that was then, this is now |
| 07:31 | <MikeSmith> | there were a whole lot of corners cut in publishing HTML4 and XHTML1 |
| 07:31 | <MikeSmith> | I would suggest that we don't want to use their publication approach as a precedent |
| 07:31 | <othermaciej> | it just seems like an embarrassment to me that we can't publish HTML5 as HTML5 |
| 07:31 | <othermaciej> | but from what you say, it sounds like it would be a waste of time to pursue it |
| 07:32 | <Hixie> | it's an embarassment to the w3c |
| 07:32 | <Hixie> | html5 has been published as html5 for years |
| 07:32 | <MikeSmith> | fwiw, I have argued that simply using <!doctype html> as the doctype on a document does not constitute publishing it as HTML5 |
| 07:32 | <othermaciej> | it's an embarrassment to the HTML WG, even though it is not up to us |
| 07:34 | <othermaciej> | anyway I'll mentally file it away as "it's political and not worth pursuing" unless the other HTML WG chairs decide they care too at some point |
| 07:35 | <MikeSmith> | I am happy to pursue it if the chairs will agree to support pushing for it |
| 07:35 | <othermaciej> | I'll ask the other co-chairs then |
| 07:35 | <othermaciej> | another data point: XHTML 1.1 Working Drafts were also published as XHTML 1.1 |
| 07:35 | <othermaciej> | that's not quite as long ago as HTML4 or XHTML 1.0, but still pretty long ago |
| 07:37 | <MikeSmith> | XHTML 1.1 is another case of a spec that I don't think it'd be prudent to use as a precedent for anything |
| 07:37 | <MikeSmith> | anyway, I don't want to (re)raise it if somebody's going to end up pulling the rug out from underneath |
| 07:37 | <othermaciej> | I'm not asking you to pursue it right now |
| 07:37 | <othermaciej> | I just wanted to understand the issue |
| 07:37 | <MikeSmith> | OK |
| 07:38 | <MikeSmith> | I do want to say that a technical way we could address this is in part is by having <!doctype html> be defined in a separate spec that we could move through Rec track more quickly |
| 07:39 | <othermaciej> | this is the relevant rule, right: http://www.w3.org/2005/07/pubrules?uimode=filter&uri=#format |
| 07:40 | <MikeSmith> | othermaciej: yeah |
| 07:40 | <othermaciej> | interesting note: the XHTML 1.1 REC is in violation of that rule |
| 07:41 | <MikeSmith> | yep |
| 07:43 | <MikeSmith> | anyway, to be clear, I do think it is worth pursuing at least getting agreement to be allowed to publish the spec with the <!doctype html> doctype |
| 07:44 | <MikeSmith> | but I suggest that not be considered the same thing as "publishing |
| 07:44 | <hsivonen> | othermaciej: occasionally, I wish people who raise process issues about the HTML WG went raise the same issues about the XHTML2 WG first |
| 07:44 | <othermaciej> | the most recent violation of pubrules format requirements I can find so far was January 16, 2009 |
| 07:44 | <annevk> | MikeSmith, I doubt that would go to REC more quicly |
| 07:44 | <MikeSmith> | meant to write, I suggest that not be considered the same thing as publishing the spec "as HTML5" |
| 07:44 | <MikeSmith> | annevk: why? |
| 07:45 | <annevk> | MikeSmith, because there's a bunch of open debates around the DOCTYPE |
| 07:45 | <annevk> | (I also have no idea how you would separate it out, but aside from that...) |
| 07:46 | <othermaciej> | to be fair this is only a Note, perhaps those are not considered to have any normative versions at all |
| 07:46 | <othermaciej> | http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/ |
| 07:46 | <MikeSmith> | hsivonen: it does seem that the HTML WG gets singled for process problems that are not unique to this group |
| 07:47 | <othermaciej> | but the pubrules for WG Notes still have the format requirements |
| 07:47 | <othermaciej> | this one seems to have slipped through the checker |
| 07:47 | <hsivonen> | if the doctype were a separate spec, versioning fans could object to it and say in public that they aren't objecting to HTML5--just the doctype |
| 07:48 | <MikeSmith> | othermaciej: I'm not sure whether the pubrules checker has always checked for the doctype constraint or not |
| 07:48 | <MikeSmith> | I think mi |
| 07:48 | <MikeSmith> | it might just pass it to the validator as-is |
| 07:48 | <MikeSmith> | hsivonen: I suppose |
| 07:49 | <othermaciej> | I do fear that splitting off the doctype could harm substantive progress |
| 07:49 | <JonathanNeal> | Is role="banner" gone? |
| 07:49 | <MikeSmith> | so the thing is, we would then need to define what we mean by "publishing as HTML5" |
| 07:49 | <othermaciej> | JonathanNeal: it still exists - just not default |
| 07:49 | <JonathanNeal> | I couldn't find it anywhere in the draft. |
| 07:50 | <MikeSmith> | for example, does "publishing as HTML5" mean we want it to be OK for a document to include features that don't yet have any implementation support? |
| 07:50 | <othermaciej> | JonathanNeal: it's specified in WAI-ARIA, which is a reference |
| 07:50 | <JonathanNeal> | or the WAI ARIA @ http://www.w3.org/TR/wai-aria/#banner (seems to have been removed?) |
| 07:51 | <hsivonen> | JonathanNeal: ARIA changed to publishing only the TOC at the main URL |
| 07:51 | <othermaciej> | JonathanNeal: http://www.w3.org/TR/wai-aria/roles#banner |
| 07:51 | <othermaciej> | it's a multipage spec |
| 07:51 | <JonathanNeal> | Thanks hsivonen and othermaciej, found it now. |
| 07:51 | hsivonen | doesn't like multipage specs |
| 07:51 | JonathanNeal | agrees with hsivonen on that one. |
| 07:51 | <othermaciej> | MikeSmith: I think we would want to exercise judgment and not use markup features that break in current browsers or that are expected to break (or change) in the future |
| 07:52 | <othermaciej> | MikeSmith: perhaps the WC3 Team would not trust the HTML WG to exercise that level of judgment |
| 07:52 | <othermaciej> | I like my find in page, so me three |
| 07:52 | <JonathanNeal> | A lot of these roles are now elements in HTMl5. |
| 07:53 | <annevk> | MikeSmith, what does publishing as HTML4 mean? |
| 07:53 | <annevk> | MikeSmith, we could publish HTML4 that validates perfectly fine but is not usable in any browser, is that more acceptable than HTML5? |
| 07:54 | <annevk> | I'd argue that with HTML5 such a problem is less likely to occur |
| 07:55 | <othermaciej> | annevk: you could write validating HTML5 that is not usable in any browser (for example if it makes assumptions about default rendering) |
| 07:55 | <MikeSmith> | annevk: you're preaching to the choir here -- I'm saying we need to make sure we be clear about what it is we want to get approval for |
| 07:56 | <othermaciej> | I will ask the other two co-chairs if they feel this is an important issue |
| 07:56 | <othermaciej> | to me it's lower on the priority list than getting to Last Call, but it does kinda bother me |
| 07:57 | <MikeSmith> | othermaciej: as far as trust, it would seem to me at least that the W3C Team does trust that chairs of the HTML WG |
| 07:57 | <MikeSmith> | otherwise they would not continue to be the chairs |
| 07:57 | <othermaciej> | all trust has limits, I don't think they would give me the W3C's bank account number |
| 07:57 | <othermaciej> | then again, nor do I want it |
| 07:59 | <sicking> | i wouldn't mind if someone gave it to me |
| 08:00 | <MikeSmith> | sicking: ! |
| 08:00 | <sicking> | as long as I got permission to use it for whatever i wanted :) |
| 08:00 | <sicking> | hey Mike! |
| 08:00 | <MikeSmith> | long time no see |
| 08:01 | <sicking> | yeah, i think my irc client wasn't configured to autoconnect here for a long time |
| 08:01 | <sicking> | iirc as a result of my mac dying |
| 08:02 | sicking | looks at maciej |
| 08:02 | <sicking> | though really it was seagates fault, it was due to hard drive failure |
| 08:03 | <MikeSmith> | some might argue that hard drive failures are inevitable, so that any unforeseen consequences of a hard-drive failure are actually pilot error (that is, lack of preparing for the inevitable) :) |
| 08:06 | <othermaciej> | sicking: your Mac died? |
| 08:06 | <othermaciej> | sorry to hear |
| 08:07 | <sicking> | MikeSmith: it is true. Our desktop admin had asked me to get backup for quite some time |
| 08:07 | <Hixie> | why is the doctype an issue? |
| 08:07 | <Hixie> | that's not the interesting part of html5 |
| 08:07 | <sicking> | othermaciej: work mac. HD failed. It ended up not being a huge deal, just lost a few days worth of work |
| 08:07 | <othermaciej> | I see |
| 08:08 | <sicking> | othermaciej: could have been *much* worse, but i got lucky |
| 08:08 | <othermaciej> | I concur with blaming yourself and/or the drive manufacturer |
| 08:08 | <sicking> | now i back up religiously. I have to say that time machine rocks |
| 08:08 | <othermaciej> | my most important things are checked into repositories or on mail or web servers |
| 08:08 | <othermaciej> | it would mostly be a personal annoyance, not a work one, if my drive totally failed |
| 08:09 | <roc> | for Mozilla development it's pretty easy to keep your work in Mercurial patch queues and save them to http://hg.mozilla.org/users/rocallahan_mozilla.com/ etc |
| 08:10 | <roc> | sicking: just don't lose XBL2! |
| 08:11 | <sicking> | roc: you push your mq repository there? |
| 08:11 | <annevk> | XBL2 is more than a pipe dream? :) |
| 08:11 | <roc> | I push some there |
| 08:11 | <roc> | now that I mention it, I really should push my other big queue there too |
| 08:13 | <othermaciej> | I guess for extra safety I could post more works-in-progress to bugs.webkit,.org |
| 08:13 | <othermaciej> | as a manager I don't have the time to code anything that complicated though |
| 08:13 | roc | anxiously scans his patch queue for anything embarrassing |
| 08:14 | <roc> | hg qdel video-h264 |
| 08:15 | <annevk> | othermaciej, MikeSmith, http://dev.w3.org/html5/html4-differences/ |
| 08:16 | <othermaciej> | annevk: thanks |
| 08:17 | <othermaciej> | if you're gonna do that then I guess I should delete my ogg patch from bugs.webkit.org |
| 08:18 | <MikeSmith> | heh |
| 08:18 | <MikeSmith> | annevk: ah, cool |
| 08:19 | <sicking> | roc: dude, you're sitting there watching youtube on <video> but holding out on the rest of us? |
| 08:20 | <sicking> | roc: i want lolcats in HTML too!! |
| 08:21 | <roc> | annevk: that's a great document |
| 08:24 | <annevk> | thanks! |
| 08:46 | <zcorpan> | annevk: "Web Sockets" should not be a link? |
| 08:47 | <zcorpan> | annevk: under 5.3. Changes from 12 February 2009 to 23 April 2009 |
| 08:49 | <zcorpan> | annevk: "potential hostile content inline" - potentially |
| 08:52 | <MikeSmith> | ah, cool.. Opera "Check for Updates" works for me now in my 10.5 alpha install and lets me install beta 1 |
| 08:53 | <annevk> | zcorpan, potentially, really? |
| 08:53 | <annevk> | zcorpan, there's two separate drafts, wasn't sure what to link to |
| 08:56 | <Hixie> | it's called "WebSocket" now btw (the specs are WebSocket API and WebSocket protocol) |
| 08:57 | <annevk> | i guess I can rename it |
| 08:58 | <annevk> | Hixie, maybe remove "The" before WebSocket API? e.g. it's also Selectors API and hardly any other spec has "The" |
| 09:03 | <zcorpan> | annevk: i'm no english expert but i'd say potentially there |
| 09:03 | <annevk> | zcorpan, same here, but then for potential |
| 09:04 | <annevk> | MikeSmith, opinions? |
| 09:05 | <MikeSmith> | annevk: sorry, wasn't paying attention.. what's the particular thing you guys have been talking about? |
| 09:06 | <annevk> | the phrase "potential hostile content inline" in my draft |
| 09:07 | <MikeSmith> | annevk: I think zcorpan is right that "potentially" would be better |
| 09:08 | <MikeSmith> | because "potentially" is an adverb modifying "hostile" |
| 09:08 | <MikeSmith> | whereas otherwise I suppose it might be ambiguous about meaning "potential content" |
| 09:08 | <annevk> | fixored |
| 09:10 | <MikeSmith> | so, I guess I can start getting the drafts staged into the dated TR URLs |
| 09:35 | othermaciej | wonders where to find 15-year-old HTML |
| 09:35 | othermaciej | also wonders where to find whatever dope dbaron has been smoking |
| 09:37 | <annevk> | img { border:0 } is one of the few things I always use when I add images |
| 09:38 | <othermaciej> | does Opera put borders on img in links by default? |
| 09:38 | <annevk> | nope |
| 09:38 | <annevk> | which is a reason I not always use that rule anymore I think |
| 09:38 | <annevk> | just forget about it sometimes |
| 09:39 | <Philip`> | I wish Opera did, so that I wouldn't accidentally make pages that look uglier than expected in Firefox |
| 09:39 | <annevk> | I believe zcorpan did some research at some point on this subject |
| 09:40 | <othermaciej> | we have never had it in WebKit |
| 09:40 | <othermaciej> | and I don't think we ever got a bug, internal or external, to add it |
| 09:41 | <hsivonen> | othermaciej: Mac IE 5 didn't have the border |
| 09:42 | <othermaciej> | hsivonen: yeah, but in the early days, Mozilla/Phoenix/Firebird/Firefox was most people's standard of "correct' rendering |
| 09:42 | <othermaciej> | for people who filed bugs anyway |
| 09:43 | <asmodai> | annevk: If you ever see TMS (again), make sure to bring him stroopwafels |
| 09:46 | <othermaciej> | ok, I found a bug related to borders around images |
| 09:46 | <othermaciej> | it was that we still drew a border for <input type=image border=0> in Safari 0.6 |
| 09:48 | <othermaciej> | hmm I take it back, I found a site that deliberately adds a blue border to image links: |
| 09:48 | <othermaciej> | http://news.google.com/ |
| 09:49 | <hsivonen> | othermaciej: that's not the *default* blue border, though, in any browser |
| 09:49 | <othermaciej> | hsivonen: indeed |
| 09:54 | <annevk> | asmodai, TMS being? |
| 09:55 | <asmodai> | TMS!~Thomas⊙poc |
| 09:56 | <zcorpan> | annevk: i researched image borders? |
| 09:56 | <annevk> | zcorpan, maybe I misremembered |
| 09:56 | <zcorpan> | i might well have, don't remember either :) |
| 09:58 | <annevk> | asmodai, ah |
| 09:58 | <othermaciej> | I could understand arguing they are needed for compat, I was surprised at the argument that it's actually a good default |
| 10:17 | <Hixie> | there's a request that we report whether a websocket connection closed gracefully or not |
| 10:17 | <Hixie> | i see two ways to do this: |
| 10:17 | <Hixie> | 1. add some state data to the 'close' event |
| 10:17 | <Hixie> | 2. add a new event |
| 10:17 | <Hixie> | if we go with 2, does anybody have any suggestions for what the two events should be? |
| 10:17 | <Hixie> | onclose and onerrorclose? |
| 10:18 | <Hixie> | (onerror is going to be used for when an unexpected frame type is received) |
| 10:20 | <jgraham> | I think I prefer 1). Having to register two different event handlers in the case that you don't care about the error seems unweildy |
| 10:21 | <Philip`> | Are people usually going to want to perform the same processing in response to both types of closing? |
| 10:21 | <jgraham> | Plus the state seems needed anyway if there is more than one possible type of error |
| 10:21 | <Hixie> | k |
| 10:21 | <othermaciej> | Hixie: are there any non-fatal errors? |
| 10:21 | <othermaciej> | I would say "close" and "error" if there were two events |
| 10:21 | <Hixie> | othermaciej: yeah, receiving a frame of an unexpected type |
| 10:21 | <othermaciej> | I also think extra info in the "close" event is good |
| 10:21 | <Hixie> | k |
| 10:22 | <othermaciej> | it would be nice if the close event could tell you the last message known to be delivered, but that requires more than clean close I think |
| 10:24 | <Hixie> | v2. |
| 10:24 | <Hixie> | actually you couldn't do that in the close event anyway |
| 10:24 | <Hixie> | you need to reconnect to find that information |
| 10:25 | <annevk> | can't we use a different event for a frame of an unexpected type |
| 10:25 | <annevk> | the error event has always been used for network errors |
| 10:25 | <Hixie> | we can use whatever event you want |
| 10:26 | <Hixie> | what would you like |
| 10:28 | <annevk> | messageerror? |
| 10:28 | <Hixie> | done |
| 10:29 | <annevk> | http://isgeolocationpartofhtml5.com/ sweet |
| 10:29 | <othermaciej> | Hixie: last message *known* to be delivered - it would be a pessimistic estimate in the error case, and exact in the clean close case |
| 10:29 | <othermaciej> | Hixie: would not require reconnectin |
| 10:29 | <othermaciej> | Hixie: but it would require some form of per-message acks |
| 10:30 | <Hixie> | othermaciej: definitely v2. |
| 10:30 | <othermaciej> | not saying this is essential, just theorizing |
| 10:30 | <othermaciej> | annevk: a lot of people would disagree with that site |
| 10:30 | <othermaciej> | Hixie: I don't know if it has to be v-anything |
| 10:31 | <othermaciej> | there is a tension in designing this protocol |
| 10:31 | <othermaciej> | on the one hand, it would be hugely valuable to have practical experience before adding a lot of stuff |
| 10:31 | <othermaciej> | on the other hand, you really don't want to accidentally lock in a flawed design prematurely |
| 10:31 | <othermaciej> | that seems like a weakness in Roy's proposed "deploy first, then standardize" model |
| 10:33 | <Hixie> | specs have to be written while implementations grow |
| 10:33 | <Hixie> | there's no magical solution, you just have to be careful |
| 10:33 | <Hixie> | anyway, what should this event attribute be. event.closeError? |
| 10:34 | <Hixie> | (boolean) |
| 10:35 | <othermaciej> | I like booleans to start with something like "has" or "is" but that's hard to do in this case |
| 10:36 | <Hixie> | event.wasClean? |
| 10:37 | <Hixie> | what's the opposite of a clean close |
| 10:37 | <Hixie> | abrupt? |
| 10:37 | <Hixie> | terminated? |
| 10:37 | <annevk> | why do we need an event attribute if you have error/close? |
| 10:37 | <Hixie> | annevk: it was argued that we should have only one event |
| 10:37 | <annevk> | that's not really consistent with <img>, XHR, etc. |
| 10:38 | <Hixie> | since in most cases you won't care |
| 10:38 | <Hixie> | well on those this event is called "load" |
| 10:38 | <annevk> | you can just do socket.onerror = x; socket.onclose = x; |
| 10:38 | <Hixie> | (which isn't really especially meaningful here) |
| 10:38 | <Hixie> | annevk: yeah but that means the simple case is harder |
| 10:38 | <Hixie> | which is bad API design |
| 10:39 | <annevk> | i guess those will get img.onloadend or some such |
| 10:39 | <annevk> | at some point |
| 10:39 | <annevk> | hmm |
| 11:09 | <MikeSmith> | zcorpan: how about "A void element is an element whose content model never allows it to have contents under any circumstances." ? |
| 11:09 | <MikeSmith> | that would seem to exclude the <colgroup span> case |
| 11:10 | <Hixie> | an element being void or not has nothing to do with its content model, in theory |
| 11:10 | <MikeSmith> | Hixie: so what does it have to do with? |
| 11:10 | <Hixie> | (though of course in practice there's a relationship) |
| 11:10 | <Hixie> | it's just a syntax thing |
| 11:10 | <Hixie> | there's a list of elements that are void |
| 11:10 | <Hixie> | they are the ones that never have an end tag |
| 11:11 | <Hixie> | that's all there is to it |
| 11:11 | <MikeSmith> | so you are not defining them as "void" in the XML syntax? |
| 11:11 | <Hixie> | "void" is a text/html syntax feature, it has no equivalent in XML |
| 11:12 | <Hixie> | it's similar to optional tags |
| 11:12 | <Hixie> | or RCDATA elements |
| 11:13 | <asmodai> | hahaha |
| 11:13 | <asmodai> | http://i.imgur.com/Zdk4B.jpg |
| 11:13 | <asmodai> | Now that's nifty |
| 11:16 | <zcorpan> | Hixie: why messageerror and not just error? |
| 11:16 | <MikeSmith> | Hixie: I guess rather than getting hung up on the word "void", I am more interested in finding a way to describe what the common characteristic of this particular set of elements is in the abstract language, rather than in any particular syntax |
| 11:16 | <Hixie> | zcorpan: anne asked for it, see about an hour ago in the irc logs |
| 11:16 | <Hixie> | zcorpan: i'd rather have error, so if you convince him to change his mind, i'll change it :-) |
| 11:17 | <Hixie> | MikeSmith: the concept of "void" is a syntax thing, it has nothing to do with the abstract language |
| 11:17 | <zcorpan> | annevk: error isn't always about network errors |
| 11:17 | <zcorpan> | annevk: what's the benefit of messageerror over error? |
| 11:18 | <Hixie> | MikeSmith: you can probably come up with some characteristic of the abstract language that all the void elements share, but it'll be just a coincidence |
| 11:19 | <zcorpan> | MikeSmith: how do you describe elements that have optional tags? |
| 11:21 | <MikeSmith> | zcorpan: I don't label them with anything. Is your suggestion that it would be an improvement to not have any special label for "elements that are not allowed to have contents under any circumstances"? |
| 11:21 | <zcorpan> | MikeSmith: it's similar in concept; i don't suggest which approach is better |
| 11:21 | <annevk> | zcorpan, I thought we were going to have an event for network errors as well |
| 11:22 | <zcorpan> | MikeSmith: but if you're talking about void elements, i think the definition should be accurate |
| 11:22 | <annevk> | zcorpan, and since I thought that was the case I thought it should be error rather than closeerror |
| 11:22 | <MikeSmith> | OK |
| 11:23 | <annevk> | zcorpan, Hixie, so since we now expose this information on close I suppose we can use error after all |
| 11:23 | <annevk> | zcorpan, Hixie, though having said that, is there a context where error is dispatched more than once? |
| 11:23 | <annevk> | hmm, maybe applicationCache |
| 11:23 | <Hixie> | script onerror |
| 11:24 | <Hixie> | as in, window.onerror |
| 11:24 | <zcorpan> | but that's not an actual event :) |
| 11:24 | <zcorpan> | media elements can get error several times if you load() it several times |
| 11:24 | <Hixie> | workers too |
| 11:25 | <zcorpan> | or change src |
| 11:25 | <annevk> | zcorpan, well yeah, but goes for <img>, XMLHttpRequest etc. too |
| 11:25 | <annevk> | zcorpan, I meant one operation causing it to be dispatched multiple times |
| 11:25 | annevk | forgot how window.onerror worked |
| 12:09 | <hsivonen> | sigh. I broke sync XHR semantics |
| 12:09 | <hsivonen> | (locally only but still annoying) |
| 12:12 | <zcorpan> | should .ogg be video/ogg or audio/ogg ? |
| 12:12 | <Philip`> | No |
| 12:13 | <Lachy> | application/ogg |
| 12:13 | <Lachy> | I think |
| 12:13 | <Lachy> | .ogv is conventially video/ogg |
| 12:13 | <Philip`> | Seems like you need more information than the file extension to make a correct choice |
| 12:13 | zcorpan | leaves out .ogg from his article |
| 12:14 | <jgraham> | It seems like media is all too confusing and should be served with a mime type like media/theres-no-way-I-made-the-right-choice |
| 12:16 | <Dashiva> | Thanks to .ogg existing, you can't even tell whether it's audio or video... |
| 12:17 | <GarethAdams|Home> | zcorpan: if you could determine MIME types based solely on file extension, there wouldn't be a need for MIME types |
| 12:17 | <Lachy> | Dashiva, that's an inherent problem with container formats that can contain 1 or more streams of multiple formats |
| 12:18 | <annevk> | jgraham, just omit Content-Type! |
| 12:19 | <Dashiva> | media/unknown |
| 12:19 | <Philip`> | unknown/ogg |
| 12:20 | <Dashiva> | Lachy: Makes me wonder, what happens if you give a file containing multiple audio streams as input to <audio>? |
| 12:21 | <Lachy> | I believe it will select the first audio stream |
| 12:21 | <Lachy> | since there is no stream selection in the api |
| 12:21 | hsivonen | notes that Larry took credit on putting MIME into HTTP in his latest blog post |
| 12:21 | <hsivonen> | s/on/for/ |
| 12:21 | <Lachy> | but UAs might provide some stream selection mechanism |
| 12:25 | <Dashiva> | "In a normal standards group, the group would have a discussion, and come to some conclusion, and the editor would follow along with the group consensus." |
| 12:25 | <Dashiva> | Kind of like how the group had a discussion and concluded canvas was in scope |
| 12:32 | <asmodai> | Well, that was funny, opened a linked Google Wave and the scripts it uses is making Firefox cry and hang. Good thing I got a stop script at one point. |
| 13:11 | <foolip> | zcorpan: .ogg should actually be audio/ogg according to some RFC, for legacy reasons mostly |
| 13:14 | <zcorpan> | foolip: yeah i've heard that, although i think some conversion tools output ogg videos with .ogg extensions |
| 13:15 | <zcorpan> | which kinda makes the rfc out of touch with reality, and we'll probably end up with videos labeled as audio/ogg |
| 13:16 | <zcorpan> | which is why browsers will assume <video> when loading audio/ogg content directly |
| 13:34 | <asmodai> | zcorpan / annevk: congratz on 10.50 |
| 13:37 | <foolip> | zcorpan: doesn't matter, serving everything as any "maybe" or "yes" mime type (e.g. .m4v as audio/x-wav) would work |
| 13:38 | <foolip> | I'm not sure if browsers rejecting e.g. text/plain will actually lead to the right mime type being used |
| 13:41 | <zcorpan> | asmodai: thanks |
| 13:42 | <zcorpan> | foolip: gif/jpg/ico are in the same situation, but are mostly correctly labeled (i think) |
| 13:43 | <zcorpan> | and png |
| 13:48 | <Dashiva> | For some definition of mostly |
| 13:48 | <Dashiva> | I get warnings about mislabeled images from irfanview regularly |
| 14:36 | <gsnedders> | Hixie: yt? |
| 16:06 | <hsivonen> | ok, so now Opera has Theora support, too. now if xiph released a thusnelda version of xiphqt, I could write a tutorial without hand-waving about future software |
| 16:19 | <TabAtkins> | Argh, why would you use script and abspos to simulate fixpos? Pretty sure everyone supports it. |
| 16:27 | <miketaylr> | TabAtkins: 'cept for ie6, yes |
| 16:35 | <TabAtkins> | miketaylr: Man, seriously? I always forget what IE6 doesn't support, dammit. >_< |
| 16:36 | <TabAtkins> | Lucky me I'm allowed to ignore it. |
| 16:36 | <miketaylr> | me too :D |
| 16:36 | <miketaylr> | this guy sometimes helps, http://a.deveria.com/caniuse/#feat=css-fixed |
| 16:37 | <TabAtkins> | Ah, right. I like that page. |
| 16:54 | <annevk> | sad that Apple is not using patents just for defense |
| 16:55 | <jgraham> | sad that the BBC is proposing to close down 6Music |
| 16:55 | <jgraham> | OK, that might just be me |
| 16:55 | <jgraham> | But I just found out and am devestated |
| 16:55 | <Philip`> | It wouldn't be until the end of 2011, apparently |
| 16:56 | <jgraham> | That doesn't help much if they do in fact do it |
| 16:57 | <jgraham> | It only means there is a little time to try to stop them |
| 16:57 | <Philip`> | It also means you can spend the next two years listening to it |
| 16:57 | jgraham | is confused by the whole thing, like how they propose to make more money abroad whilst simultaneously cancelling their most popular shows abroad like Top Gear |
| 16:58 | <Philip`> | You could even save the two years' output to disk, and play it on loop for the rest of forever |
| 16:58 | <annevk> | they are cancelling Top Gear? |
| 16:58 | <annevk> | aaah |
| 16:58 | <Philip`> | since you'll have forgotten about the earlier shows later on |
| 16:58 | <annevk> | whenever I see it that show is fun |
| 16:58 | Philip` | hadn't heard that about Top Gear |
| 16:58 | <Philip`> | I'd heard they were planning to sell the Top Gear magazine, but that's quite different |
| 16:58 | <jgraham> | Philip`: It just means I will spend two years being upset at the stupidity of whoever thinks that UK Commerical radio is an acceptable alternative |
| 16:59 | <jgraham> | Oh maybe I got the wrong idea about Top Gear |
| 16:59 | <jgraham> | I was still in shock by that part of the article |
| 16:59 | annevk | listens to Norwegian radio now and then nowadays |
| 16:59 | jgraham | has not listened to much Swedish radio, but it has always been utterly dreadful |
| 17:00 | <annevk> | oh yes |
| 17:00 | <annevk> | my HD arrived |
| 17:01 | <annevk> | time to power down and start over I guess |
| 17:02 | <jgraham> | (I guess I don't have very Swedish taste in music) |
| 17:07 | <AryehGregor> | Could I file a bug with the W3C validator team asking them that if they find a page using a strict doctype is invalid, that they check it against HTML5 and report it as valid HTML5 if it is? |
| 17:07 | <AryehGregor> | That would make MediaWiki's switch to HTML5 significantly smoother. |
| 17:08 | <AryehGregor> | Does anyone know who I could talk to about it? |
| 17:19 | <JonathanNeal> | Is <nav role="navigation"> completely unnecessary or good accessibility practice? |
| 17:22 | <AryehGregor> | JonathanNeal, completely unnecessary. |
| 17:23 | <JonathanNeal> | Is the role attribute alltogether unnecessary, or can it be used for good accessibility practice? |
| 17:25 | <paul_irish> | JonathanNeal: peep these two sections: http://www.whatwg.org/specs/web-apps/current-work/#annotations-for-assistive-technology-products-(aria) and http://www.w3.org/WAI/PF/aria-implementation/ |
| 17:25 | <AryehGregor> | If it were altogether unnecessary, would it have been added to the spec? |
| 17:26 | <workmad3> | in that case, I'd say completely unnecessary as it's redundant... you're in a navigation element, so repeating that the navigation element is used for navigation is redundant |
| 17:26 | <workmad3> | but you can put more useful roles in |
| 17:26 | <AryehGregor> | <nav> is defined to have a default role of "navigation". |
| 17:26 | <workmad3> | heh :) there we go |
| 17:26 | workmad3 | should really look at aria a bit more) |
| 17:27 | <AryehGregor> | At least, I assume it is. |
| 17:27 | <JonathanNeal> | I hate how these pages hang in Firefox. |
| 17:27 | <AryehGregor> | Yep. |
| 17:27 | <JonathanNeal> | I have to wait until Firefox is done doing whatever, and then open them in Chrome. |
| 17:27 | <AryehGregor> | JonathanNeal, you can add "multipage/" before the "#" and it will load fine, even with a section anchor. |
| 17:27 | <AryehGregor> | I think it's fixed in Firefox 3.7, anyway. |
| 17:27 | <workmad3> | ho hum... waiting for FF to sort itself |
| 17:28 | <JonathanNeal> | Well, it works in Chrome just fine. |
| 17:29 | <JonathanNeal> | Oh my, so header is banner and hgroup is header? |
| 17:30 | <JonathanNeal> | header element -> No role, if specified, role must be banner ... and then ... hgroup element -> heading role |
| 17:41 | <TabAtkins> | JonathanNeal: banner is a page-unique role, so they can't just apply it to all <header>s by default (though we tried to at first). That's why <header> has no default role. |
| 17:41 | <JonathanNeal> | I'm aware, I just figured that <header> would be "heading" and <hgroup> would be "banner" |
| 17:41 | <JonathanNeal> | Since usually the banner does not contain the navigation. |
| 17:42 | <JonathanNeal> | And usually the heading does. |
| 17:42 | <AryehGregor> | MikeSmith, do you know anyone I could contact on the W3C validator team to suggest that if a document has an obsolete but conforming doctype, and fails parsing under that doctype, the W3C validator should try parsing as HTML5 and declare it valid if it's valid HTML5? |
| 17:42 | <AryehGregor> | Otherwise Wikipedia (and all other MediaWikis) will look like invalid XHTML 1 Strict, which is kind of a pain for evangelism. |
| 17:43 | <AryehGregor> | (well, all other MediaWikis by default, unless they disable well-formed XML) |
| 18:00 | <TabAtkins> | JonathanNeal: Why did you think that? Did you think that <h1-6> were "banner" instead of "heading"? |
| 18:02 | <TabAtkins> | That is to say, is it the aria names that were confusing you, or the HTML names? |
| 18:04 | <JonathanNeal> | It was the combination of <header> being "banner" and <hgroup> being "heading" but it makes sense with the understanding of H1 |
| 18:06 | <TabAtkins> | Gotcha. |
| 18:09 | <JonathanNeal> | Also, I was suprised to have a <nav> inside a role="banner" |
| 18:11 | <TabAtkins> | So the name for that ARIA role seems unintuitive for you? |
| 18:14 | <JonathanNeal> | No, I think I can adjust my meaning of banner, which isn't specific. |
| 18:14 | <JonathanNeal> | A banner can include navigation. |
| 18:14 | <JonathanNeal> | I'm just bringing it forward as I processed it. |
| 18:15 | <TabAtkins> | Yeah, but your earlier understanding of the word didn't match up. I'm just narrowing down where the confusion originated. ^_^ |
| 18:43 | <annevk> | installed |
| 18:43 | <annevk> | that took ages |
| 18:43 | <annevk> | for some reason the USB stick was broken after all so I had to create a new one which was kind of tricky |
| 18:45 | <htcn> | when you create a Pattern in a canvas context, can you offset it |
| 18:45 | <htcn> | or just center it |
| 18:46 | <htcn> | I used a pattern for drawing a hue/saturation/brightness colorwheel's hue circle |
| 18:47 | <JonathanNeal> | Would anyone be willing to look at the source of http://sandbox.thewikies.com/html5-layout/ and share their thoughts on the notes I've included? |
| 18:51 | <roc> | annevk: "sad that Apple is not using patents just for defense" --- what was that about? |
| 18:53 | <annevk> | roc, according to daringfireball they're attacking HTC |
| 18:53 | <TabAtkins> | JonathanNeal: What's the "Zen" business sprinkled throughout your notes? |
| 18:55 | <TabAtkins> | Oh, I see. For one of the display modes. |
| 18:55 | <roc> | ta |
| 18:59 | <JonathanNeal> | Zen, yea it's not entirely useful, but I kept it so I could mark meaningful classnames used throughout the document versus (structural classnames). |
| 19:01 | <roc> | annevk: it looks like they're suing over mostly software patents :-( |
| 19:05 | <paul_irish> | JonathanNeal: looks good. nice to have the implied role's in there |
| 19:06 | <JonathanNeal> | paul_irish, thanks, I'll work on a better name than "Zen", but something that implies to us "this is meaningful markup" |
| 19:08 | <AryehGregor> | Yes, well, everyone sensible always knew Apple was evil. |
| 19:10 | <annevk> | according to gruber it's the first attack they've made |
| 19:10 | <annevk> | i kind of hoped they'd never do that |
| 19:11 | <annevk> | guess I'm going to consider switching away from apple hardware entirely |
| 19:11 | AryehGregor | has never owned an Apple product, and doesn't ever plan to. |
| 19:28 | <JonathanNeal> | I also think I could remove <nav class="portlet-toolbar"><ul ... /></nav> for <menu class="portlet-toolbar"><ul ... /></nav> what do you guys think? |
| 19:34 | <roc> | the problem is that you can only debug Mac bugs on Apple hardware, because you can't virtualize Mac OS (because Apple is evil) |
| 19:37 | <annevk> | according to markp soon everything will be iPhone OS'd so that shouldn't be an issue |
| 19:44 | <roc> | why do people on www-font care about better tools for creating EOT fonts |
| 19:46 | <Philip`> | Because they want to make sites that look the same in IE as in other browsers |
| 19:46 | <TabAtkins> | Because (1) if we want to use @font-face widely, EOT is still necessary, and (2) CWT, one of the deliverables for FontWG, is basically EOT. |
| 19:47 | <annevk> | we're having a Font WG after all? oh god |
| 19:47 | <othermaciej> | Is CWT still in the Font WG deliverables? |
| 19:47 | <TabAtkins> | Just to define WOFF and CWT, and get tests for font-face. |
| 19:47 | <annevk> | I'm very much opposed to all this |
| 19:48 | <TabAtkins> | annevk: You just hate all the non-TTF formats. ^_^ |
| 19:48 | <othermaciej> | Apple is not enthusiastic about implementing random new font formats, but with Mozilla backing the Fonts WG and WOFF there is not much point trying to oppose it |
| 19:51 | <roc> | we're not backing CWT |
| 19:51 | <TabAtkins> | Hrm, having trouble finding the recent email about the proposed charter. |
| 19:51 | <roc> | I'm not even sure we're backing the Fonts WG |
| 19:52 | <Philip`> | http://www.w3.org/2009/08/WebFonts/charter says just WOFF |
| 19:54 | <TabAtkins> | Ah damn, that did get taken out, didn't it. |
| 19:54 | <TabAtkins> | ;_; |
| 19:54 | <roc> | you say that like it's a bad thing |
| 19:55 | <TabAtkins> | Everyone has a stupid kneejerk reaction to CWT just because it's an EOT version. It's just a custom header on top of a TTF file! |
| 19:55 | <JonathanNeal> | http://downforeveryoneorjustme.com/whatwg.org |
| 19:55 | <JonathanNeal> | "It's not just you! http://whatwg.org looks down from here." |
| 19:55 | <annevk> | TabAtkins, and for a reason |
| 19:56 | <TabAtkins> | annevk: Reason being? |
| 19:56 | <annevk> | TabAtkins, adding complexity and obfuscation to TTF just for poltical reasons is silly |
| 19:56 | <TabAtkins> | Well, no, it's for compat reasons. CWT is usable in IE6+. It's a useful variant of TTF. |
| 19:57 | <TabAtkins> | It happens to also fulfill the "light obfuscation" thing that some vendors want, but that's not its reason for existing. |
| 19:57 | <AryehGregor> | What ever happened to the same-origin thing? |
| 19:58 | <TabAtkins> | Fonts are supposed to be same-origin only, modulated by CORS. |
| 19:58 | <roc> | CWT is useless because to enforce the same-origin stuff that font vendors want, you have to use Referer checking |
| 19:58 | <AryehGregor> | When I left www-font, the prevailing objection was that either you made the root string blank and IE would serve it from any domain, or you didn't and other browsers would ignore root strings of existing files, which is also bad. |
| 19:58 | <annevk> | I was talking about WOFF |
| 19:58 | <annevk> | also, I'm opposed to abusing CORS as I previously explained |
| 19:58 | <AryehGregor> | Well, and also if you used the root string, people would have to actually maintain it to get it to work with IE, but I guess that's no worse than just using EOT. |
| 19:59 | <annevk> | CWT seems even more silly |
| 19:59 | <TabAtkins> | roc: It's exactly equivalent in restriction to the other formats; the same level of (non)restriction is present if you server TTF or WOFF. |
| 19:59 | <AryehGregor> | My position was always that if there was any solution that allowed one font file to be served to everyone, take it, however hacky. |
| 20:00 | <TabAtkins> | AryehGregor: Exactly, though CWT is at least minimally hacky. You don't even have a rootstring. (Not even a rootstring hidden in padding, in the current proposed version.) |
| 20:00 | <roc> | TabAtkins: not so. we can add convenient same-origin restrictions to TTF and WOFF (and have, in Firefox). that is not an option when you serve CWT to IE. |
| 20:00 | <AryehGregor> | TabAtkins, then IE just accepts it from any domain? |
| 20:01 | <AryehGregor> | But we figure it's not such a big deal because it will fail in Firefox, so people won't be enthusiastic to do that? |
| 20:01 | <TabAtkins> | roc: That's only a problem if people are okay with their fonts *only* working in legacy IE. |
| 20:01 | <TabAtkins> | AryehGregor: Yeah. |
| 20:01 | <AryehGregor> | Seems reasonable enough to me. |
| 20:01 | <AryehGregor> | Although there are other problems with IE, IIRC, like not supporting italic/bold fonts easily? I got out of this a long time ago. |
| 20:02 | <AryehGregor> | Glad to hear that a solution was reached that's acceptable to both Mozilla and MS. |
| 20:02 | <roc> | If a font license requires the author to protect the font from cross-origin access, and the author doesn't but "it's OK because only IE can access the font cross-origin", how many corporate legal departments would be OK with that? |
| 20:02 | <AryehGregor> | Now if only we could solve the "page doesn't render while font downloads" problem. |
| 20:02 | <TabAtkins> | Legacy IEs have buggy @font-face support, but you can work around it. |
| 20:02 | <zcorpan> | there's no event when 'buffered' changes because cached data has been thrown away |
| 20:03 | <zcorpan> | so it's hard to know when to update the UI |
| 20:03 | <AryehGregor> | roc, do any foundries state things exactly that way? Or do they say exactly what technologies they permit? |
| 20:03 | <TabAtkins> | roc: Any website which leeches your font won't work in a large percentage of browsers. |
| 20:03 | <TabAtkins> | It's just not a good deal. |
| 20:03 | <AryehGregor> | Anyway, has anyone thought about progressive rendering for fonts? |
| 20:03 | <zcorpan> | should we fire 'progress' in that case? |
| 20:03 | <AryehGregor> | Like putting all the ASCII characters in the front and ensuring that the browser can render those right away? Is this impossible with TTF? |
| 20:03 | <AryehGregor> | I guess the Chinese are out of luck regardless. :) |
| 20:03 | <TabAtkins> | AryehGregor: You can get mild progressive rendering by ordering the tables correctly. I think FF already does that somewhat? |
| 20:04 | <AryehGregor> | It still has FOUC-like effects. |
| 20:04 | <AryehGregor> | Unless you use heavy subsetting, maybe? |
| 20:04 | <TabAtkins> | WOFF organizes the font in such a way as to present some layout information immediately. |
| 20:04 | <AryehGregor> | How big is a font with only basic Latin, a few kilobytes? If it fits in a single TCP window . . . |
| 20:04 | <roc> | AryehGregor: I believe that's how it works (or rather, is going to work). I poked and prodded the font vendors who supported CWT/EOT to try to get specific details, they were not cooperative |
| 20:05 | <AryehGregor> | roc, maybe if you were a customer they'd be more willing to explain. :) |
| 20:05 | <TabAtkins> | They're still too tied up in their legal department wranglings. >_< |
| 20:05 | <roc> | TabAtkins: I understand that, but ignoring font licensing requirements because "the font vendor isn't going to care in practice" isn't going to be acceptable to lawyers in general |
| 20:06 | <AryehGregor> | No, but if they don't mind in principle, and enough customers ask them about it, they'll tell their legal department to allow it explicitly. |
| 20:06 | <TabAtkins> | roc: We'd need details on exactly what they're trying to prevent, though. If it's generic enough, then just allowing your font to be downloaded with wget may be enough to violate the license. |
| 20:06 | <roc> | in theory the font vendors could carve out an exception in their licenses, but my suggestive prodding failed to elicit such a plan |
| 20:06 | <AryehGregor> | One Mozilla developer asking them, however awesome he is, is probably not enough to get them to ask a lawyer to look at it. :) |
| 20:07 | <AryehGregor> | But if a bunch of customers ask, or one large customer, that would be a different story. |
| 20:07 | <roc> | what if the answer to the question might affect Mozilla's support for their font format? |
| 20:07 | <TabAtkins> | I should prod them too. |
| 20:08 | <TabAtkins> | roc: Well, since their non-answer's effect seems to be "Mozilla wont' support it", they don't have much to lose. ^_^ |
| 20:08 | <roc> | sure |
| 20:08 | <roc> | good luck |
| 20:08 | <AryehGregor> | roc, then you're deadlocked. This is what fora like a Fonts WG are supposed to prevent. :) |
| 20:08 | <roc> | we're not deadlocked |
| 20:08 | <paul_irish> | what's the prodding for? i have a few good contacts. |
| 20:09 | <roc> | so have I |
| 20:09 | <AryehGregor> | paul_irish, would EOT with no root strings be okay, if non-IE browsers implemented it with cross-origin restrictions? |
| 20:09 | <roc> | they could change the landscape by just announcing that they will license CWT fonts in a way that lets you deploy them on IE without any cross-origin protection |
| 20:09 | <TabAtkins> | paul_irish: Seeing if it would be acceeptable to font foundries for a website to serve CWT, which will be same-origin protected on modern browsers but not on legacy IEs. |
| 20:09 | <roc> | I asked them to make such an announcement |
| 20:09 | <roc> | they didn't do so |
| 20:09 | <roc> | <shrug> |
| 20:10 | <paul_irish> | didnt FontFont just announce their licensing their work for CWT and woff only? |
| 20:10 | <zcorpan> | http://simon.html5.org/temp/2d0zbqtzv.html - not finished, but feedback welcome (i'll read the logs) |
| 20:11 | <paul_irish> | and ascender, of course, is behind CWT.. i havent seen much foundry-based opposition to it |
| 20:12 | <AryehGregor> | "Opera requires that your video file is served as video/ogg for it to play." Why? |
| 20:12 | <zcorpan> | that's not entirely accurate; we also accept application/ogg and audio/ogg and audio/wav etc |
| 20:12 | <zcorpan> | but text/plain and text/html etc are rejected |
| 20:12 | <zcorpan> | because the spec says so |
| 20:13 | <AryehGregor> | Oh, feh. |
| 20:13 | <AryehGregor> | Why does the spec say so? These aren't script, are there security problems? |
| 20:14 | <AryehGregor> | Apache seems to serve application/ogg by default for Ogg, or at least a rule in /etc/apache2/magic seems to say so. |
| 20:14 | <AryehGregor> | Still not sure why this is necessary. |
| 20:15 | <zcorpan> | it's just to avoid mislabeled content |
| 20:15 | <AryehGregor> | Which will fail anyway when you feed it to GStreamer, no? |
| 20:16 | <AryehGregor> | The server might mislabel, the video player will know for sure whether it can play the file. |
| 20:16 | <AryehGregor> | Server-set MIME types should be treated as hints of intent, not an actual description of what the content is, because how should the server know that? But maybe there's a good reason here. |
| 20:17 | <zcorpan> | sure, but if we play text/plain videos, then we need to sniff for video for text/plain if we want to be able to play mislabeled videos when loaded directly |
| 20:17 | <zcorpan> | plus, we want to reject video/mp4 if we can't play mpeg-4 |
| 20:17 | <AryehGregor> | Well, I assume you already do other types of sniffing there anyway, so why not? |
| 20:18 | <zcorpan> | so it's not much effort to also reject text/plain |
| 20:18 | <zcorpan> | because we don't know what gstreamer supports so we don't know what to sniff for |
| 20:18 | AryehGregor | doesn't get what the benefit is to users or authors that outweighs the annoyance of authors potentially having to configure their servers. |
| 20:18 | <AryehGregor> | So let GStreamer sniff. It presumably returns an error graciously if it can't play it, right? |
| 20:19 | <AryehGregor> | GStreamer is the only part of the system that knows for sure what can be played. |
| 20:19 | <AryehGregor> | Once you've already received the HTTP headers, you've received the start of the content too, so just feed that to GStreamer and that will be a lot more reliable than guessing based on header. |
| 20:19 | <AryehGregor> | Of course, it makes sense to sniff based on MIME type in the HTML, because that way you can avoid unnecessary requests. |
| 20:24 | <AryehGregor> | zcorpan, you should mention that old browsers may return "no" from canPlayType(). Your examples should be updated to reflect that too. |
| 20:27 | <zcorpan> | AryehGregor: old video-supporting browsers return bogus results for canPlayType anyway, iirc |
| 20:31 | <zcorpan> | added a note |
| 20:31 | <roc> | Safari 3 |
| 20:39 | asmodai | eyes Google Docs... |
| 20:39 | <asmodai> | Am I the only one for which their spreadsheet is acting weird on FF 3.6? |
| 20:55 | <zcorpan> | nn |
| 21:06 | <hober> | hsivonen: http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx |
| 21:07 | <hober> | I think http://ieblog.members.winisp.net/images/MarcSil_IE8_Document_Mode_2.png looks even more complicated than http://hsivonen.iki.fi/doctype/ie8-mode.png |
| 21:18 | mpilgrim | catches up on the font format discussion |
| 21:19 | <mpilgrim> | yeah... this isn't doing much to change my opinion of the font foundries |
| 21:19 | <JonathanNeal> | I'm not sure the context for <menu type="toolbar"> and <menu type="context menu"> after reading the docs. I have visible buttons in the upper-righthand area of an application, so for the visible buttons I used <menu type="toolbar">, and then for the drop down menus I used <menu type="context menu"> |
| 21:19 | <JonathanNeal> | Does that sound right? |
| 21:19 | <asmodai> | mpilgrim: Obssessive people? :) |
| 21:20 | <TabAtkins> | JonathanNeal: I think context menu <menu>s are intended only for actual context menus; that is, right-click menus. |
| 21:21 | <JonathanNeal> | I wasn't sure if context could be triggered by left clicking an icon. |
| 21:23 | <TabAtkins> | Well, that's supposed to be handled by the UA. |
| 21:24 | <JonathanNeal> | Sure, well in that case, I will leave it blank for the "menu" role. |
| 21:24 | <TabAtkins> | Ideally, the UA exposes the commands in a UA-specific manner when the user asks for a context menu. |
| 21:24 | <TabAtkins> | Yeah. |
| 21:24 | TabAtkins | should put together a toy impl of that tonight. |
| 21:27 | <MikeSmith> | AryehGregor: about the validator question you asked, the place to discuss that would be on the public-qa-dev list or www-validator list |
| 21:28 | <MikeSmith> | there really is not currently much of a team working actively on maintaining the existing validator |
| 21:28 | <MikeSmith> | it mostly one guy, Ville Skyttä |
| 21:29 | <JonathanNeal> | Thanks TabAtkins, you can see how I implemented it @ http://sandbox.thewikies.com/html5-layout/ (read source code on line 247+ for documentation) |
| 21:29 | <JonathanNeal> | It's cross browser too. |
| 21:30 | <Philip`> | hober: Ooh, nice that they're documenting it in some actual detail now |
| 21:30 | <MikeSmith> | AryehGregor: what you suggest sounds like something that could really be a feature of validator.nu itself |
| 21:31 | <Philip`> | (Still seem to be entirely missing the details about how they determine the modes for doctypes, though) |
| 21:44 | <roc> | my opinion of the font vendors ("foundries" implies an unwarranted special status IMHO) is pretty low too. However I think it's worth making a small compromise to get interoperable Web fonts more widely accepted, faster. WOFF is so simple, it's a very small compromise indeed from my point of view. |
| 21:46 | <TabAtkins> | Sigh. "I'd like light ranch dressing, please." "Ok, ranch dressing." "LIGHT ranch." "Ok, here you go, italian dressing." |
| 22:07 | <mpilgrim> | i'm just waiting for the first firefox extension that notices embedded WOFF fonts, automatically converts them to TTF, installs them in your local font directory, and puts up a toaster-style notification saying "Congratulations, your font library just got expanded!" Preferably with an icon of an "R" wearing a pirate patch. |
| 22:08 | <TabAtkins> | Why the R? |
| 22:09 | <roc> | sure |
| 22:09 | <roc> | perhaps Linux systems will get native support for WOFF too |
| 22:09 | <mpilgrim> | wouldn't have to be an "R". could be an "A". i guess the concept of "typography" is used iconified using an "A", isn't it? |
| 22:09 | <roc> | doesn't matter |
| 22:09 | <TabAtkins> | Ah, got it. |
| 22:09 | <mpilgrim> | but an "R" with a pirate patch would probably look cooler |
| 22:10 | <mpilgrim> | anyway, the entire thing is an exercise in making copying bits less convenient |
| 22:10 | <mpilgrim> | that never ends well, regardless of good intentions |
| 22:10 | <TabAtkins> | Well, WOFF actually comes with some nice benefits over TTF. |
| 22:10 | <TabAtkins> | CWT doesn't have any direct benefits over TTF, but it good simply because of increased compat. |
| 22:11 | <mpilgrim> | does one of them include "native support on every major computing platform on the planet"? |
| 22:11 | <TabAtkins> | No? |
| 22:11 | <roc> | once you unwrap and gunzip, yes |
| 22:11 | <TabAtkins> | Well, yes. |
| 22:11 | <mpilgrim> | i serve my embedded TTF fonts gzipped already |
| 22:13 | <roc> | WOFF reorders the tables and compresses them independently, which could be helpful if you want to analyze just the CMAP |
| 22:15 | <mpilgrim> | could i not do that with a TTF file directly? (non-rhetorical question) |
| 22:18 | <roc> | you could reorder the tables and gzip the whole thing. Then the browser could read the CMAP quicker, but when you wanted the other tables you'd have to re-uncompress the whole file from scratch, unless you saved the gzip state. It's considerably more complex. |
| 22:19 | <TabAtkins> | Sigh. Why do tables have to act so weird? Specifically with respect to floating and positioned descendants. |
| 22:21 | <mpilgrim> | thanks, roc |
| 22:22 | <mpilgrim> | and how does this all help the font vendors in their quest to make bits less copyable? |
| 22:22 | <mpilgrim> | i.e. why are they behind such a format? |
| 22:22 | <roc> | simply that you cannot download a WOFF font and drop it in your Fonts folder and have it work |
| 22:22 | <roc> | that's all |
| 22:22 | <TabAtkins> | It's a "garden fence", for now. |
| 22:22 | <roc> | well |
| 22:23 | <roc> | I guess there's also the fact that the only browser that implements WOFF today has a default same-origin restriction, so it's easy for authors to comply with font licenses that require them to protect fonts from cross-site linkage. But strictly speaking that's an author benefit. |
| 22:26 | <TabAtkins> | So, roc, am I restating your objection to CWT correctly if I say that it's *too* interoperable; eg, the problem is that it works in browsers that don't have same-origin restrictions? |
| 22:27 | <roc> | I wouldn't put it that way |
| 22:28 | <roc> | I'd say that IE has origin restrictions for fonts, but CWT forbids you from using them |
| 22:29 | <TabAtkins> | I'd say that's at least as biased a phrasing as what I provided. ^_^ |
| 22:29 | <roc> | definitely :-) |
| 22:30 | <TabAtkins> | It also makes it seem like everything would be better if only CWT allowed you to use IE's origin-restriction mechanism, but in fact allowing that mechanism was one of your objections to the earlier CWT draft, iirc. |
| 22:31 | <roc> | IIRC I have not objected to having CWT say that the header is opaque and hence may contain data that IE would interpret as a rootstring |
| 22:31 | <TabAtkins> | All right, I may be risremembering. I know that several people *did* object to precisely that. |
| 22:31 | <roc> | yes |
| 22:32 | <roc> | I may be misremembering too |
| 22:32 | TabAtkins | doesn't want to comb through his archives to find the answer. |
| 22:32 | <roc> | such an approach has some problems, like the fact that different browsers using different access control policies would be suboptimal |
| 22:32 | <TabAtkins> | Indeed. |
| 22:33 | Philip` | wonders if anyone happened to notice that Microsoft removed the 5000-byte name string limit (which broke lots of fonts that embed the Open Font License) in a security update recently |
| 22:33 | <TabAtkins> | Ooh, I didn't. Good to know. |
| 22:33 | <TabAtkins> | Augh, god, SHODAN keeps scaring me. |
| 22:34 | <TabAtkins> | I have her flashing for a fraction of a second every few minutes on the GLaDOS system at work. |
| 22:44 | TabAtkins | is pissed that he has to wrap the contents of a <td> in a <div height:100%> just to provide a positioning root. |
| 22:55 | <othermaciej> | TabAtkins: can't you just put position:relative on the TD? |
| 22:55 | <TabAtkins> | othermaciej: Nope. Not working in FF3.6, at least. It *should* work, but it's not. |
| 22:56 | <othermaciej> | roc: we're probably gonna support double-clicking WOFF fonts to install them, same as for OpenType |
| 22:56 | <othermaciej> | roc: if only because it would be extra work not to |
| 22:56 | <othermaciej> | so we see WOFF as pure waste |
| 22:57 | <othermaciej> | TabAtkins: I know Firefox has a problem with the table not being eligible to be a containing block for absolute positioned content, did not know there was an issue with cells |
| 22:58 | <roc> | cells don't necessarily support relative positioning in CSS 2.1 |
| 22:58 | <roc> | "The effect of 'position:relative' on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined." |
| 22:58 | <TabAtkins> | Argh, that is stupid and wrong. |
| 22:58 | <TabAtkins> | Presumably bugwards compatibility. |
| 22:58 | <paul_irish> | othermaciej: seriously? doubleclick to install woff fonts? |
| 22:59 | <othermaciej> | it's what we do for OpenType |
| 22:59 | <othermaciej> | and our easiest path to WOFF is to treat them same as any other font in the font system |
| 22:59 | <roc> | I'm surprised that that's the easiest thing to do, but OK |
| 23:00 | <othermaciej> | well, we could have a layer to translate from WOFF to TrueType in WebKit, if we were specifically motivated to prevent these fonts from working in apps that don't use WebKit for display |
| 23:00 | <othermaciej> | though increasingly more apps use WebKit for display, so that wouldn't even be very effective |
| 23:01 | <othermaciej> | TabAtkins: no, just the fact that tables are underdefined in CSS |
| 23:01 | <roc> | I don't see how your support work work if it doesn't do that. You'd add WOFF support to Quartz? |
| 23:01 | <TabAtkins> | othermaciej: Indeed, they are. And that's stupid and wrong. ^_^ |
| 23:01 | <TabAtkins> | Long-term goal: overdefine CSS. |
| 23:02 | <roc> | it looks like Webkit doesn't actually support relative positioning on table cells |
| 23:03 | <roc> | but position:relative still makes the cell a container for abs-pos elements |
| 23:03 | <TabAtkins> | Argleasdjf;alf |
| 23:03 | <roc> | oh hang on |
| 23:03 | <roc> | Webkit behaves exactly like Firefox here |
| 23:04 | <roc> | totally ignores position:relative on cells |
| 23:04 | <othermaciej> | that's believable |
| 23:04 | <roc> | the cell doesn't become an abs-pos container |
| 23:04 | <roc> | ok, everyone move along |
| 23:04 | <othermaciej> | seems like it is useful to make a cell be an absolute positioned containing block |
| 23:04 | <TabAtkins> | It is very useful. |
| 23:04 | <TabAtkins> | I am making a calendar right now which could use it. |
| 23:04 | <othermaciej> | roc: same parts of the system that support OpenType/TrueType would support WOFF |
| 23:05 | <othermaciej> | on Mac |
| 23:05 | <othermaciej> | at least that is our current tentative plan |
| 23:05 | <roc> | ok |
| 23:05 | <TabAtkins> | <td><div height:100%; position:relative;>foo</div></td> works, but is obviously stupid. |
| 23:08 | <roc> | I presume, though, you must have some support in Webkit for font formats, since you need it for SVG fonts, so I presume you have some good reason to not add WOFF support there (since all ports would benefit from that) |
| 23:09 | <roc> | (now SVG fonts --- *that*'s a pure waste :-) ) |
| 23:09 | <Rik`> | iirc, the iphone only supports svg fonts :( |
| 23:13 | <othermaciej> | roc: we might also add it there for ports where we can't change the font system, but on operating systems controlled by Apple the long-term goal would be to make it just another font format |
| 23:13 | <othermaciej> | the iPhone only supports SVG fonts as Web fonts, currently anyway |
| 23:14 | <Rik`> | othermaciej: do you know why ? |
| 23:14 | <roc> | that's unfortunate, since SVG fonts are pretty bad |
| 23:14 | <othermaciej> | Rik`: still evaluating security / bandwidth / perf impact of OpenType |
| 23:14 | <othermaciej> | it may change in the future, it may not, that is all I can say |
| 23:15 | <othermaciej> | interesting side note: some iTunes LPs and iTunes Extras use SVG fonts |
| 23:15 | <roc> | do you know why? |
| 23:15 | <othermaciej> | as a cheapass way to do subsetting |
| 23:15 | <roc> | weird |
| 23:18 | <Rik`> | why supporting OTF on the Mac if there is still a security evaluation on the iPhone ? |
| 23:22 | <TabAtkins> | At the upcoming CSS ftf, we're totally going to have to reintroduce display-role and display-model (though maybe as -outside and -inside, to be more intuitive). |
| 23:22 | <TabAtkins> | Otherwise, how will I ever make a table-cell also use Template Layout? |
| 23:23 | <roc> | I think I'd like that |
| 23:24 | TabAtkins | wants to use Template and Flexbox, or their spiritual successors, *so bad*. |
| 23:32 | <Philip`> | Rik`: Maybe security is stricter on the iPhone than on the Mac, because it needs to prevent users doing dastardly things such as choosing to run unauthorised programs |
| 23:32 | <Philip`> | (Or maybe there's more sensible reasons) |
