| 00:00 | <jacobolus> | gotcha. I definitely agree then that anything that gets a DOM node should have Element.id/Element.className |
| 00:00 | <jacobolus> | and should work w/ getElementById, etc. |
| 00:01 | <zcorpan> | should we make all elements HTMLElements? :) |
| 00:02 | <jacobolus> | annevk: I seem to be able to use Element.id on SVG elements in Safari |
| 00:02 | <jacobolus> | and then fetch them w/ getElementById, etc. |
| 00:03 | <jacobolus> | but maybe that's browser-specific? |
| 00:03 | <annevk> | try with non-SVG, non-MathML, non-HTML elements |
| 00:04 | <jacobolus> | annevk: is there a page someplace w/ some of those? I'm not sure if I have a use for such... |
| 00:04 | <annevk> | also non-XBL, non-XUL if you happen to use some Gecko flavor |
| 00:04 | <zcorpan> | data:text/xml,<foo id="bar"/> |
| 00:04 | <zcorpan> | javascript:alert(document.documentElement.id) |
| 00:04 | <annevk> | zcorpan, one step at the time :) |
| 00:05 | <weinig> | jacobolus: SVGElement has an id attribute http://www.w3.org/TR/SVG/types.html#InterfaceSVGElement |
| 00:05 | <jacobolus> | weinig: gotcha |
| 00:06 | <jacobolus> | is the use of non-{HTML/SVG/MathML/XUL} elements common? |
| 00:08 | <jacobolus> | annevk: ISTM that anything that's going to be in the DOM should get an ID, so +1 from me (not that my opinion necessarily counts for anything) |
| 00:13 | <annevk> | it's not common, but it would simplify things and if we ever get more XML vocabularies the right answer is implied |
| 00:15 | <othermaciej> | XML should have just reserved id for an ID attribute instead of xml:id |
| 00:15 | <othermaciej> | sadly I think there are some obscure DTDs that use an attribute named "id" for a non-id purpose |
| 00:16 | <annevk> | there's one I think |
| 00:16 | <annevk> | ChemML or some such? |
| 00:16 | <jacobolus> | seems like something to put into http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-745549614 to me |
| 00:16 | <annevk> | but they don't have a DOM :) |
| 00:17 | <annevk> | jacobolus, it's http://www.w3.org/TR/domcore/ now |
| 00:17 | <annevk> | keep up ;p |
| 00:17 | <jacobolus> | okay, into http://www.w3.org/TR/domcore/#interface-element then |
| 00:17 | <annevk> | nn |
| 00:17 | <zcorpan> | nn |
| 00:18 | <jacobolus> | annevk: just take your red box there and make it part of the spec. sounds great :) |
| 01:52 | <gavin> | is irc.w3.org down? |
| 01:53 | <boogyman> | I'm unable to connect as well |
| 02:15 | <gavin> | looks like it's back now |
| 03:39 | <zaythan> | hi all :) |
| 05:13 | <AryehGregor> | annevk, seems accurate. In real life you'd probably use just <bdi>, though, not <bdi dir=rtl>, for that example (since it's probably auto-generated by an application that doesn't know the direction of the string). |
| 05:14 | <AryehGregor> | I haven't had a chance to look over the details of what Hixie did for dir=auto. |
| 06:38 | <hsivonen> | othermaciej: is http://www.w3.org/html/wg/tracker/issues/128 going to be put to poll soon? I'd like to have the Chairs' decision soonish considering that Firefox 4 is close to shipping |
| 07:51 | <MikeSmith> | hsivonen: I believe the chairs are still planning to ask for counter proposals for issue 128 before taking it to a poll |
| 07:53 | <MikeSmith> | hsivonen: so if you have some urgency around trying to get it resolved before Firefox 4 ships, I think that is a legitimate reason for asking the chairs to consider prioritizing it higher |
| 08:04 | <hsivonen> | MikeSmith: Hixie already filed a counter-CP |
| 08:04 | <hsivonen> | MikeSmith: it seems unlikely that someone would write a CP with a third way |
| 08:05 | <MikeSmith> | hsivonen: yeah, I'm not sure myself what else they are expecting |
| 08:06 | <MikeSmith> | but that is what I understand they are intending |
| 08:06 | <hsivonen> | I see |
| 08:06 | <hsivonen> | I wish the Decision cycle was faster in general |
| 08:07 | <MikeSmith> | yeah |
| 08:07 | <MikeSmith> | I think given the number of issues that LC is likely to generate, it's going to need to be faster |
| 08:08 | <MikeSmith> | about issue 128 in particular I can discuss it with the chairs on the HTML WG telcon this week |
| 08:08 | <MikeSmith> | tomorrow |
| 08:08 | <hsivonen> | MikeSmith: thanks |
| 08:08 | <MikeSmith> | if you are able to attend the call yourself, that would be helpful also |
| 08:13 | <hsivonen> | hmm. if the call starts at 18 Helsinki time, I'd miss the start of the call but might be able to make it to the second half |
| 08:14 | <hsivonen> | jgraham: ? |
| 08:15 | <jgraham> | Sorry, thought my connection had dropped |
| 08:15 | <MikeSmith> | hsivonen: there typically isn't a second half -- the calls don't often run more than 30 minutes these days |
| 08:15 | <MikeSmith> | hsivonen: so it's probably better for you not to try to rush to make the second half of the call |
| 08:17 | <MikeSmith> | if there's not likely to be one |
| 08:17 | <hsivonen> | MikeSmith: ok |
| 08:17 | <MikeSmith> | hmm, is anybody around yet who has admin access to the whatwg mailing list config/ |
| 08:18 | <MikeSmith> | seems like the spammer is going to be at it for a while |
| 08:18 | <MikeSmith> | oh man |
| 08:18 | <MikeSmith> | even more yet |
| 08:18 | <virtuelv> | jebus, the torrent of spam to the mailing list is annoying |
| 08:19 | <MikeSmith> | Гоннов is nice name at least |
| 09:01 | <Peter`> | The spam wasn't nice, but I don't think Alexandre replying to the guy is going to help |
| 09:09 | <zcorpan> | it helped the spammer since the links got in yet another message |
| 09:19 | <othermaciej> | hsivonen: probably fairly soonish, yes - we want to give anyone else with an interest in creating additional proposals the opportunity to speak up |
| 09:21 | <hsivonen> | othermaciej: oh is this the process step where the counter-proposal clock starts only after the initial proposal deadline has passed even when the counter-proposal has already been written? |
| 09:22 | <othermaciej> | hsivonen: we should probably short circuit it since we already have a proposal and counter-proposal, and odds of a third distinct proposal do not seem high |
| 09:23 | <hsivonen> | othermaciej: yeah |
| 10:37 | <zcorpan> | hsivonen: http://ukwebfocus.wordpress.com/2010/11/10/experiences-migrating-from-xhtml-1-to-html5/ (in case you want to comment with your validator hat on) |
| 10:49 | <hsivonen> | zcorpan: thanks |
| 10:52 | <david_carlisle> | zcorpan: should we make all elements HTMLElements? :) |
| 10:52 | <david_carlisle> | yes why not (it would simplify the mathml story if math elements inherited from that, and I can't see why other vocabularies wouldn't also benefit) |
| 10:55 | <zcorpan> | david_carlisle: i think it's better to more stuff to Element that we want to have everywhere |
| 10:55 | <hsivonen> | I think it should true that all elements in the HTML namespace and only those element implement HTMLElement |
| 10:56 | <hsivonen> | analogously for SVGElement and the SVG namespace |
| 10:56 | <hsivonen> | and if we want stuff on all elements, those things should be hoisted to Element |
| 10:57 | <zcorpan> | s/more/move/ |
| 10:58 | <othermaciej> | hsivonen: do you know if Mozilla has any plans to support XSLT 2.0 or XPath 2.0? |
| 10:59 | <david_carlisle> | that works for me, if Element (if used in a browser) really is the baseline for what's expected (innerHTML, id, ..) |
| 10:59 | <othermaciej> | (or do you know who might know, if you don't?) |
| 11:08 | <hsivonen> | the guardians of XSLT in Gecko are peterv and sicking |
| 11:09 | <othermaciej> | thanks |
| 11:09 | <nw> | I somehow first read that as "pervert" and "sickening." |
| 11:10 | <nw> | Says something about me, I guess... |
| 11:10 | <annevk> | heh |
| 11:12 | <othermaciej> | annevk: do you know if Opera has any plans to support XSLT 2.0 or XPath 2.0, or who to ask about it? |
| 11:12 | <annevk> | othermaciej, your issue-137 email points to 133 |
| 11:12 | <othermaciej> | oops |
| 11:13 | <annevk> | othermaciej, I'm pretty sure we have more useful things to implement |
| 11:14 | <annevk> | othermaciej, messaged you a name for a second opinion |
| 11:14 | <othermaciej> | thanks |
| 11:34 | <hsivonen> | I guess I should escalate the <u> bug into an ISSUE as a follow-up to the f2f meeting |
| 11:35 | <annevk> | more new elements yay |
| 11:35 | <hsivonen> | "new" |
| 11:35 | <boogyman> | has there been a resolution for 11254? |
| 11:35 | <annevk> | count is at 108 including <device> |
| 11:37 | <annevk> | boogyman, if there's no resolution in the bug, there's no resolution |
| 11:38 | <annevk> | othermaciej. so are you guys seriously considering taking it on? |
| 11:38 | <othermaciej> | annevk: a WebKit volunteer contributor wants to do it |
| 11:39 | <hsivonen> | othermaciej: will (s)he maintain it? |
| 11:40 | <othermaciej> | hsivonen: this same person did most of our MathML support, so it's plausible he/she could implement and maintain a large project |
| 11:40 | <hsivonen> | I see |
| 11:41 | <othermaciej> | however, I am worried about the compatibility breakage, the fact that other browser vendors do not seem super enthusiastic, and about the amount of code it would take |
| 11:41 | <annevk> | that XSLT and XPath are not backwards compatible is kind of a deal breaker |
| 11:42 | <annevk> | on top of that, they're hardly used |
| 11:42 | <jgraham> | I don't think the experience of XSLT 1 on the web suggests that it is a direction that is worth significant further investment |
| 11:42 | <annevk> | a few of my friends are heavily involved with an XML editor, but they are writing most things from scratch in ECMAScript |
| 11:42 | <jgraham> | For the platform |
| 11:42 | <othermaciej> | it's claimed by some that the compat breakage is unlikely to be a big deal in practice |
| 11:43 | <othermaciej> | I do not have the data to make a real assessment |
| 11:43 | <annevk> | then we should maybe just drop the feature |
| 11:43 | <jgraham> | I would much rather we applied the engineering effort to something that people are actually demanding |
| 11:43 | <othermaciej> | the lists of compat breakage in XSLT 2.0 and XPath 2.0 look pretty long |
| 11:43 | <webr3> | annevk, what platform? |
| 11:43 | <annevk> | if there's no breakage, the feature is vastly underimportant |
| 11:44 | <annevk> | webr3, ? |
| 11:44 | <othermaciej> | also as far as XPath API goes, I'm not sure how the XPath version would be determined |
| 11:44 | <david_carlisle> | the vast majority of actual xslt1 styesheets will work unchanged on a v2 engine |
| 11:44 | <othermaciej> | jgraham, there is a group of people who are vocally interested in XSLT 2.0/XPath 2.0, not clear how much that extends to mainstream web developers |
| 11:44 | <othermaciej> | how big is the minority that won't work? |
| 11:45 | <othermaciej> | 5%? 1%? .0001%? |
| 11:45 | <webr3> | annevk, ignore i strapped jgrahams "for the platform" on to the end of your sentence by mistake |
| 11:45 | <jgraham> | I think it would be more worthwhile use of time to spec out the IE XPath DOM API to replace all the document.evaluate nastiness |
| 11:45 | <david_carlisle> | how long is a piece of string? |
| 11:45 | <hsivonen> | Saxon doesn't do XSLT versioning |
| 11:45 | <jgraham> | And just keep XPath 1 but with an API that miught enougrage people to use it |
| 11:45 | <hsivonen> | it just treats XSLT 1.0 as XSLT 2.0 and emits a warning |
| 11:45 | <othermaciej> | david_carlisle, this is a question that, at least so far as deployed content goes, can be answered with data |
| 11:46 | <david_carlisle> | taht is the specified xslt2 behaviour, not a saxon thing |
| 11:46 | <webr3> | othermaciej - whatever percentage it is, it's likely to rise considerably as more people move to client side applications wth deployed xml-based server side stacks |
| 11:46 | <hsivonen> | when I was worried about this, I was lead to believe that there's no practical stuff to worry about, only theory |
| 11:46 | <othermaciej> | XSLT 2.0 is supposed to have a 1.0 compat mode |
| 11:46 | <othermaciej> | which is not 100% compatible, but less incompatible than full 2.0 mode |
| 11:46 | <hsivonen> | othermaciej: oh, maybe Saxon enabled that or something |
| 11:46 | <hsivonen> | othermaciej: in any case, it warned that it's not 100% compatible, I was worried and was told not to worry |
| 11:47 | <jgraham> | (fun fact; HTML5 has about the same number of elements as DocBook 1) |
| 11:47 | <hsivonen> | I have zero knowledge about what would actually break |
| 11:47 | <othermaciej> | hsivonen: I remember people saying the same thing about XHTML 2 |
| 11:48 | <jgraham> | othermaciej: I think there was a group of people who were vocally interested in XSLT 1.0 but it still has no real traction |
| 11:48 | <hsivonen> | my main worries about XSLT/XPath 2.0 are: getting dragged into implementing the optional schema-aware features and using up the finite attention of engineers who have rare knowledge that could be used better |
| 11:49 | <david_carlisle> | for my own stylesheets I had to change probably a few dozen lines out of a few tens of thousands of lines, so that;s a very small percentage, but on the other hand a rather larger percentage (I don't remember) of top level stylesheets did need a change, so it depends what you want to measure. |
| 11:49 | <david_carlisle> | hsivonen: don't touch the schema aware part:-) |
| 11:49 | <jgraham> | Having to change anything on the web is a big problem |
| 11:50 | <jgraham> | We can't just suddenly land some feature that breaks a bank or whatever and say "oh well you only have to change a little bit" |
| 11:50 | <othermaciej> | from the browser point of view, if we ship something that requires deployed XSLT stylesheets to be changed, it doesn't matter much how few lines need to be changed in each one |
| 11:50 | <hsivonen> | david_carlisle: well, if browsers say they are doing XSLT 2.0 and someone puts schema-awareness in an acid test and someone caves, we'd all be in trouble |
| 11:51 | <hsivonen> | othermaciej: I thought we had a rule on this channel that you aren't supposed to say "XSLT stylesheet" and are supposed to say "XSLT transformation" :-) |
| 11:51 | <david_carlisle> | the schema awareness is an explict extra conformance layer in the language, so it's just a matter of what you say is implemented. At with saxon, the free one is not schema aware the paid for one is, but that ism't a saxon split you can tell from the language spec these different layers |
| 11:51 | <othermaciej> | hsivonen: sorry for not being up to speed on the official terminology |
| 11:52 | <david_carlisle> | if web developers (and browser implementers) thought more about xslt and less about javascript they'ed be happier more well rounded people. |
| 11:52 | <david_carlisle> | and i always say stylesheet |
| 11:53 | jgraham | wouldn't like to bet on that claim :) |
| 11:53 | webr3 | nor i |
| 11:53 | <jgraham> | (that they would be happier, more well rounded people) |
| 11:54 | <david_carlisle> | or of course you could use lisp and be even happier |
| 11:54 | <othermaciej> | in my opinion, for any given web technology, the more you think about it, the greater the risk to your sanity |
| 11:55 | <hsivonen> | The HTML5 spec says "XSLT transform" or "XSLT transformation", because CSS is the one true style sheet language |
| 11:55 | <jgraham> | You can write lisp and compile it down to javascript :) |
| 11:55 | <jgraham> | And then replace your HTML with sexps |
| 11:57 | <david_carlisle> | well I would use lisp (dsssl) but round brackets went out of vogue so we started using angle ones to be trendy (xslt) but javascript uses curly brackets so is clearly all wrong. (in depth comparative language review over) |
| 11:57 | <hsivonen> | (more seriously: it seems incorrect to call a transformation to an HTML tree styling, so the HTML5 spec doesn't call it styling) |
| 11:57 | <asmodai> | crap |
| 11:57 | <asmodai> | what's eating cpu and memory this time :S |
| 11:59 | <david_carlisle> | hsivonen: that stylesheet/transform nonsense (presumably indicative of a committee disagreement) causes all sorts of confusion with people suggesting baroque rules of when to use which word, so I always just tell people to use stylesheet |
| 11:59 | <hsivonen> | david_carlisle: I try to say "transform", since it is correct and avoids suggesting that XSLT in browsers is an alternative to CSS |
| 12:00 | <david_carlisle> | whatever, just use the same word always and don't (as some have done) spend hours trying to classify some as one and some as the other. |
| 12:01 | <othermaciej> | the word "transform" seems fine for all purposes |
| 12:01 | <asmodai> | hsivonen: Managed to trip another CPU and memory guzzling problem in Firefox again. I sure am lucky eh? :) |
| 12:01 | <david_carlisle> | maybe browsers should have ditched there html/css engines, implemented xsl-fo, and then xslt would have been a replacement for css. Oops I said it, i'd better go now... |
| 12:01 | <othermaciej> | I don't really ever think of it as a stylesheet, I just use the word for historical reasons (e.g. the fact that the xml-stylesheet PI is used to invoke an XSLT trnasform) |
| 12:01 | <othermaciej> | funny use of the word "should"! |
| 12:02 | <annevk> | david_carlisle, CSS uses curly braces too |
| 12:02 | <david_carlisle> | quite |
| 12:02 | <annevk> | and given the popularity... |
| 12:02 | <david_carlisle> | good reason for replacing it with xslfo |
| 12:03 | <othermaciej> | angle brackets are clearly far superior to curly braces |
| 12:03 | <hsivonen> | asmodai: It's unfortunate that those things happen to you. bug filing time I guess. |
| 12:03 | <othermaciej> | the fact that xslt + xsl-fo has no reasonable story for styling a dynamically changing document makes it non-viable as a css replacement |
| 12:04 | <othermaciej> | (nor a story for changing the true "model" DOM client side instead of the transformed "presentation" DOM) |
| 12:05 | <othermaciej> | solve those problems, and it might be worthwhile to have a conversation |
| 12:06 | <othermaciej> | except not even then, because CSS is good enough |
| 12:06 | <david_carlisle> | True but there is a large class of documents that don't change in real time in the client, some of them last for thousands of years, and xslt really comes from that tradition |
| 12:06 | <jgraham> | You probably want a time machine too |
| 12:06 | <jgraham> | So that you can solve it before the legacy lock in |
| 12:06 | <othermaciej> | you can't "replace" the CSS layout engine with something that only handles a subset of Web use cases |
| 12:06 | <jgraham> | That is a surprisingly small class of web documents |
| 12:07 | <othermaciej> | you can't "replace |
| 12:07 | <othermaciej> | " it at all really |
| 12:07 | <othermaciej> | but there's more reasons than just compat why it would be bad |
| 12:07 | <david_carlisle> | Well yess that's why XSLt is used a lot more on the server (or before the document gets to the server) than on the client |
| 12:08 | <asmodai> | hsivonen: been trying to find out what page/page combination triggered it |
| 12:09 | <othermaciej> | so I hope you can understand why "maybe browsers should have ditched there html/css engines, implemented xsl-fo, and then xslt would have been a replacement for css" is not even a valid syllogism, let alone something that ever would have been likely to happen |
| 12:09 | <david_carlisle> | er yes |
| 12:10 | <david_carlisle> | Im now watching an internal presentation introduciing Fortran "the most advanced programming language available today2"filmed in 1958... must go |
| 12:11 | <othermaciej> | heh |
| 12:15 | <annevk> | yeah, on the server... |
| 12:15 | <annevk> | PHP is also used on the server |
| 12:15 | <annevk> | o_O |
| 12:17 | <asmodai> | hsivonen: Think I might have caught it, at least part of it. Seems the latest PageSpeed addin update is causing issues. keeping CPU at like >70% and growing memory with megabytes per second. At least with the pages I have open |
| 12:29 | <asmodai> | grrr, or maybe not, hate heidenbugs |
| 12:34 | <david_carlisle> | annevk: yeah, on the server... yes but there are many places where xslt on the client works well, content mathml to presentation for example (or presentation mathml to whatever html/css/javascript works on a system without mathml support) and in general (the original xml vision) of serving semantically richer markup and converting for display on the client is much easier in xslt than javascript and not totally without merit, even if it's not a |
| 12:34 | <david_carlisle> | topic with mass appeal. (but then I'm a pure mathematician, that doesn't have mass appeal either) |
| 12:44 | <annevk> | except that vision does not work |
| 12:45 | <annevk> | you need something like HTML; a language whose semantics are widely understood |
| 12:45 | <annevk> | not a language of which only you understand the semantics |
| 12:56 | <david_carlisle> | annevk; it depends. You need HTML that is widely understood, but you may also need some other source language that is not widely understood (which is why you are translating to html) but that you want to share with those that do understand it (which is why you don't just want to translate on the server) |
| 12:56 | <david_carlisle> | There are alsternatives to client side transform (justserve two files, or use conneg or something) but just because there are alternatives doesn't mean that it's a bad idea |
| 12:58 | <david_carlisle> | sorry I can't type and eat at the same time (actually I can't type even when im not eating) apply spelling correction to the above |
| 13:35 | <hsivonen> | asmodai: the extension might poke at stuff in a cross-compartment way or something |
| 13:38 | <hsivonen> | did sicking volunteer to write a fourth CP for ISSUE-27? |
| 13:39 | <asmodai> | hsivonen: No, it's not the extension |
| 13:39 | <asmodai> | hsivonen: disabled both ones that got updated. |
| 13:39 | <hsivonen> | asmodai: ok |
| 13:40 | <hsivonen> | othermaciej: according to the minutes, sicking volunteered to write a fourth CP for ISSUE-27 |
| 13:40 | <asmodai> | hsivonen: So far only managed to trace it, sort of, to www.speedtree.com and www.facefx.com being open at the same time |
| 13:41 | <hsivonen> | asmodai: I wonder if they share the ad provider or something of that nature |
| 13:42 | <annevk> | what change proposal would sicking write? |
| 13:42 | <hsivonen> | annevk: delegating rel registry to microformats.org |
| 13:43 | <asmodai> | hsivonen: Only symptom I noticed is that those open with the ones I already have open causes my dual core to show 20%-40% CPU utilization even if the tab is not focused on either of those two sites. |
| 13:43 | <asmodai> | hsivonen: The memory leaks apparently needs 4-5 extra pages open, which I had closed trying to nail this issue. :S |
| 13:43 | <asmodai> | hsivonen: I seriously dislike trying to come up with a repro case like this :( |
| 13:44 | <asmodai> | bloody heisenbugs |
| 13:45 | <annevk> | hsivonen, yeah, that is said in the minutes |
| 13:46 | <annevk> | with "new information" being experience with IANA |
| 13:46 | <annevk> | should we raise this on list? |
| 13:47 | <hsivonen> | annevk: probably worthwhile to mention on the list |
| 13:47 | <annevk> | i will |
| 13:48 | <hsivonen> | aside, I find it questionable that when I file a crash bug using the Ubuntu crash reporting tool, the command line I used that contains potentially private file names is posted to launchpad publicly |
| 13:48 | <hsivonen> | annevk: thanks |
| 13:48 | <hsivonen> | now everyone can tell the names of the patches I'm working on |
| 13:48 | <hsivonen> | though I'm disclosing that information usually anyway for non-security bugs |
| 13:51 | <asmodai> | hsivonen: ouchies |
| 13:52 | <nessy> | zcorpan: just a quick note that I think I got it now - but I don't see why not supporting percent would be a bug then... |
| 13:54 | <annevk> | nessy, UAs are required to process invalid content in the same way |
| 13:54 | <annevk> | nessy, otherwise sites start using width="50%" and expect it to be treated as width="50" for instance |
| 13:54 | <nessy> | so we distinguish between different kinds of invalid? |
| 13:55 | <annevk> | no |
| 13:55 | <nessy> | well, 50% is different invalid from 50px |
| 13:55 | <annevk> | we distinguish between authors and user agents |
| 13:55 | <annevk> | it's not different invalid |
| 13:55 | <annevk> | it has different behavior |
| 13:56 | <nessy> | so… it's invalid from a standard POV, but it's kinda valid for an author, because browsers show a defined behaviour? |
| 13:57 | <nessy> | (where "it" are both those examples ;-) |
| 14:00 | <annevk> | you are trying to draw lines that are not really there |
| 14:01 | <annevk> | it is as invalid as e.g. <style>body{background:green</style> |
| 14:01 | <nessy> | I'm trying to consolidate in my own mind how "invalid" and "defined behaviour" gel |
| 14:02 | <annevk> | well, the way we write specifications they are mostly orthogonal |
| 14:02 | <annevk> | in the sense that everything "works" and a subset of that is "valid" |
| 14:02 | <annevk> | (the subset that makes sense, ideally) |
| 14:03 | <nessy> | So - it's not just because sometimes markup is incomplete, it's also because people have expectations from things that used to work? |
| 14:03 | <nessy> | s/work/be valid/ |
| 14:05 | <zcorpan> | nessy: what authors need to know is what is valid |
| 14:06 | <zcorpan> | nessy: no need to say what browsers will do when they break the rules |
| 14:06 | <zcorpan> | imho :) |
| 14:06 | <zcorpan> | gotta go |
| 14:07 | <nessy> | well, for things that get typically done wrong, it makes sense to mention it IMHO |
| 14:07 | <nessy> | anyway :) |
| 14:36 | <MikeSmith> | hsivonen: so it seems like James is amenable to having functionality from the jing validator-nu branch ported back to the trunk |
| 14:37 | <MikeSmith> | though he mentions "Some of them may be hard to do in a general-purpose way" |
| 14:38 | <MikeSmith> | I would like to start with any low-hanging fruit |
| 14:38 | <MikeSmith> | if there is any |
| 14:39 | <MikeSmith> | that is, anything that I might be able to port back that doesn't have the problem of being hard to do in a general-purpose way |
| 14:58 | <karlcow> | Are there tests out there showing what Opera/Firefox/Safarire/IE/ returns for " " <- (non breaking space in innerHTML) |
| 14:59 | Ms2ger | wonders if "Safa-rire" was intentional |
| 15:00 | <karlcow> | Ms2ger: I'm so used of calling things with different names that I do not realize when I write them. unintentional but play of words I always do. Safa-rire and Caca-script among others |
| 15:02 | <karlcow> | I have noticed also that I do some typos in handwriting that I have acquired because of the keyboard mistyping. braiiiiins |
| 15:02 | <AryehGregor> | You mean, what they do when you set an element's innerHTML to a non-breaking space? |
| 15:03 | <AryehGregor> | Like in what way? |
| 15:04 | <karlcow> | a text area form: You type a non breaking space. What is sent to the server? Opera seems to send the correct unicode character, but firefox seems to send the entity (Not sure) |
| 15:05 | <AryehGregor> | Well, that's easy to test. |
| 15:06 | <karlcow> | yes I was wondering it had already been done. :) |
| 15:08 | <jgraham> | Isn't the innerHTML case just http://software.hixie.ch/utilities/js/live-dom-viewer/saved/699 ? |
| 15:11 | <AryehGregor> | Opera 10.something, Firefox 4, Chrome dev all seem to submit as %A0 in this test-case: <!doctype html><form><input name=foo value=" "><input type=submit></form> |
| 15:13 | <AryehGregor> | But for innerHTML, Firefox and Chrome change it to , Opera changes it to a literal. |
| 15:13 | <AryehGregor> | Opera sounds the most reasonable here. What does IE do? |
| 15:13 | <AryehGregor> | (And what does the spec say?) |
| 15:14 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#escapingString |
| 15:14 | <AryehGregor> | Gecko and WebKit are correct per spec, Opera is wrong. |
| 15:14 | <karlcow> | yep it seems |
| 15:15 | <karlcow> | I wonder about IE |
| 15:27 | <karlcow> | Thanks AryehGregor |
| 15:44 | <kennyluck> | I was horrified by the fact that the current spec has a predefined behavior for the 'top' fragment identifier -> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid |
| 15:45 | <kennyluck> | Is this implemented by IE or other browsers? It doesn't work on my Firefox 3.6 |
| 15:45 | <Ms2ger> | It probably is |
| 15:47 | <Lachy> | It was supported by IE. Not sure about other browsers. |
| 15:48 | <jgraham> | Works in Opera |
| 15:48 | <kennyluck> | wow. |
| 15:48 | <jgraham> | I agree it seems kinda silly |
| 15:49 | <Ms2ger> | Welcome to the web? |
| 15:49 | <kennyluck> | It would be silly if this is listed in the "HTML5 difference from HTML4" document as a new HTML5 feature |
| 15:50 | <annevk> | can't list everything |
| 15:50 | <Ms2ger> | Just as much a new HTML5 feature as innerHTML |
| 15:51 | <jgraham> | Yeah, but it can't really be needed that much for compat |
| 15:52 | <Ms2ger> | Perhaps you could drop it :) |
| 15:52 | <annevk> | we added it for compat |
| 15:52 | <annevk> | people use that stuff |
| 15:53 | <jgraham> | Seems weird that gecko gets away without it |
| 15:53 | <jgraham> | But whatever |
| 15:53 | <annevk> | and I don't really see what's wrong with it |
| 15:54 | <jgraham> | Magic global definitions are generally quite bad |
| 15:54 | <jgraham> | But it's not really worse than the acceptness badness of the platform |
| 15:54 | <jgraham> | *accepted |
| 16:10 | <erlehmann> | is there a listing for circumstances under which canvas cross origin restrictions are relaxed? i cannot seem to find one, but my bookmarklet seems to run in the context of the current origin. |
| 16:16 | <jgraham> | erlehmann: Bookmarklets are same-origin in general |
| 16:17 | <erlehmann> | jgraham, would you suggest i make a greasemonkey script then? |
| 16:17 | <erlehmann> | or is that same-origin too? |
| 16:17 | <Ms2ger> | I'd hope so |
| 16:21 | <jgraham> | Browser extensions might be a good bed |
| 16:21 | <jgraham> | *bet |
| 16:21 | <jgraham> | depending on just what you want to do and what APIs the browsers have |
| 16:22 | <erlehmann> | jgraham, filter every image on a page. just for fun, so i'll don't do anything to complicated. |
| 16:26 | <othermaciej> | hsivonen: he did - I am not sure if he still plans to |
| 16:44 | <jgraham> | Yay. Fixing rev 5666 seems like lots of fun! |
| 16:44 | <jgraham> | (that was sarcasm) |
| 16:50 | <gsnedders> | jgraham: Dr Graham using sarcasm? Well I never! |
| 16:58 | <Philip`> | AryehGregor: Re http://www.w3.org/Bugs/Public/show_bug.cgi?id=11011 : /abc (?idef)/ is a syntax error, it should be /abc (?i)def/ or /abc ((?i)def)/ |
| 17:27 | <annevk> | so the main problem with most current registries is that they encode only "REC" stuff |
| 17:27 | <annevk> | whereas the web consists of a lot of non-"REC" stuff |
| 17:30 | <annevk> | i.e. web registries need to accept the transient nature of the web |
| 17:33 | <othermaciej> | does MIME type regitration really happen only at REC stage? |
| 17:34 | <othermaciej> | it seems like, if we had provisional registration very early in the process, it would make it more likely that registry experts could give feedback before it's too late |
| 17:34 | <othermaciej> | by the time the spec gets to REC, it is almost certainly too late to materially change the registration |
| 17:34 | <annevk> | yeah, e.g. text/cache-manifest has had no MIME review so far |
| 17:35 | <annevk> | Opera currently has a few something/x-opera-... MIME types because people thought registering was too hard |
| 17:36 | <annevk> | I have a really hard time seeing what is wrong with a wiki, or a more structured form of that |
| 17:41 | <othermaciej> | I think if we go with the w3c xpointer-style registry for link relations, and if it works out well, then we should consider using it for the other registries in HTML5 |
| 17:41 | <annevk> | the worse cases are actually when there's no good media type, as with fonts |
| 17:42 | <othermaciej> | (meta name, meta http-equiv, maybe canvas contexts? can't remember what else) |
| 17:42 | <othermaciej> | is there any MIME type appropriate for TrueType fonts? |
| 17:42 | <othermaciej> | font/otf? |
| 17:42 | <othermaciej> | is font/* even a real MIME type namespace? |
| 17:42 | <annevk> | it's not |
| 17:43 | <annevk> | the idea was that it would be though, but it never happened and now it is too late |
| 17:43 | <annevk> | I think those are the registries HTML5 currently has, yes |
| 17:43 | <annevk> | if it works out I hope URL schemes etc. will move towards that too |
| 17:45 | Philip` | isn't sure there will ever be enough canvas contexts for there to be any value in a registry |
| 17:46 | <Philip`> | (I'm only aware of about three that exist) |
| 17:47 | <annevk> | yeah |
| 17:48 | <zcorpan> | jgraham: firefox supports #top in quirks mode |
| 17:49 | <tabatkins> | Philip`: The 2d, opera 2d, and webgl contexts, right? |
| 17:50 | <annevk> | we had opera-3d as well |
| 17:50 | <annevk> | but they are being phased out |
| 17:50 | <Philip`> | tabatkins: Yeah |
| 17:51 | <Philip`> | I don't think opera-3d was ever in a non-experimental build |
| 17:51 | <annevk> | that sounds likely |
| 17:54 | <zcorpan> | i don't understand why (?i) can't be added to javascript |
| 17:54 | <zcorpan> | if everyone agrees that it's the best solution, why not go for it? |
| 17:55 | <zcorpan> | Web ECMAScript already has stuff that ES5 sticks its head in the sand... and firefox also already supports a non-standard regexp flag |
| 17:56 | <annevk> | say it on the list |
| 17:59 | <othermaciej> | zcorpan: it might be that ES folks would be willing to add it |
| 18:00 | <othermaciej> | though I expect "/foobar/i" is a more familiar syntax than "(?i foobar)" |
| 18:00 | <othermaciej> | my suggestion was simply to allow the full ES regexp literal syntax in pattern="", as an alternative to the ES pattern syntax |
| 18:01 | <othermaciej> | so you could say pattern="/whatever/i" |
| 18:01 | <othermaciej> | this would avoid adding any attributes to HTML5, but would make the pattern microsyntax a hair more complicated |
| 18:01 | <Philip`> | Support both syntaxes at once? |
| 18:01 | <othermaciej> | yep |
| 18:01 | <Philip`> | That'd be somewhat ambiguous |
| 18:01 | <othermaciej> | just check for initial / to decide which to use |
| 18:02 | <othermaciej> | I suspect ES pattern syntax requires / to be escaped anyway, or regexp literals wouldn't work |
| 18:03 | <othermaciej> | anyway I also think it's fine to punt on it for now and return to the issue once we have a better handle on how pattern="" gets used |
| 18:03 | <Philip`> | / doesn't need to be escaped in e.g. new RegExp("/...") |
| 18:04 | <Philip`> | (where it's interpreted as matching a literal '/' character) |
| 18:06 | <TabAtkins_> | annevk: I'm not sure how to possibly resolve the ?HR issue without creating a new constructor(s). You even say that having .responseText and .responseXML would be confusing. If it's confusing, why not just take the solution that's *not* confusing? |
| 18:15 | <MikeSmith> | TabAtkins_: hey, do you have any updated info about plans from the Chrome team for the HTML5 context-menu feature? |
| 18:15 | <MikeSmith> | I remember we discussed is quite a while back |
| 18:15 | <TabAtkins_> | I talked to an engineer about it a few weeks back, and had an involved discussion about how things work. Havne't followed up on it. |
| 18:20 | <AryehGregor> | Philip`, oh, shows how much I've ever used that feature. I assumed it worked like (?:foo) to avoid capturing. |
| 18:22 | <Philip`> | AryehGregor: The syntax is not that consistent :-) |
| 18:35 | <JonathanNeal> | What is the proper way to label a group of radio inputs? |
| 18:37 | <TabAtkins_> | Labelling the group itself? A heading, usually. |
| 18:38 | <TabAtkins_> | Or a fieldset legend, if that's appropriate. |
| 18:41 | <JonathanNeal> | Thanks TabAtkins_, I find myself wanting a way to label a group the same way I label a control, perhaps a fieldset is appropriate, but I have a connotation in my head that a new fieldset means a subject change (when really I'm just trying to intelligently group some radios together) |
| 18:42 | <TabAtkins_> | As usual, the answer is to not stress about it. ^_^ |
| 18:42 | <JonathanNeal> | It's not to have you guys create a new html5 element? Oh, okay. :D |
| 18:43 | <TabAtkins_> | Another heading element? Zeus forbid... |
| 18:43 | gsnedders | would just get confused with another |
| 18:43 | gsnedders | is confused enough as is |
| 18:44 | <JonathanNeal> | <grouplabel> :P |
| 18:45 | <JonathanNeal> | and<group> naturally |
| 18:46 | <TabAtkins_> | Otherwise known as <h1> and <section>. |
| 18:46 | <TabAtkins_> | Or <legend> and <fieldset> |
| 18:46 | <TabAtkins_> | Or <label> and <select> |
| 18:51 | <JonathanNeal> | ia fielset a sectioning element? |
| 18:53 | <karlcow> | this "top" fragid… looks like a magic mushroom. Designed in Amsterdam? |
| 18:54 | <TabAtkins_> | JonathanNeal: Don't think so, no. |
| 18:54 | <Ms2ger> | karlcow, Redmond, I suppose |
| 20:15 | Hixie | finds and lols @ TabAtkins_'s WFM on a recent bug |
| 20:25 | <Ms2ger> | Node.document? I wonder who invented that... |
| 20:25 | <heycam> | Ms2ger, is that different from ownerDocument? |
| 20:25 | <Ms2ger> | No |
| 20:26 | <heycam> | it is shorter though :) |
| 20:26 | <Ms2ger> | They should have used Node.d :) |
| 20:27 | <Ms2ger> | And Opera++ |
| 20:36 | <TabAtkins_> | You're welcome, Hixie. ^_^ |
| 20:37 | <annevk> | a new constructor does not automatically make matters less confusing |
| 20:42 | <TabAtkins_> | annevk: A new constructor solves the issue of .responseText being potentially available when it doesnt' really do anything (or maybe throws on access). |
| 20:45 | <annevk> | I'm not really sure that is the issue |
| 20:45 | <annevk> | or a issue, for that matter |
| 20:50 | <TabAtkins_> | I thought that was basically the whole issue - whether or not they exist, what they do if they do exist, et. |
| 20:55 | <TabAtkins_> | annevk: Is there another issue you're aware of? |
| 20:56 | <annevk> | the main issue seems to be limited memory |
| 20:56 | <annevk> | and then there's various constraints |
| 20:56 | <annevk> | but I should really get some sleep |
| 20:56 | <TabAtkins_> | Quitter! |
| 20:57 | <annevk> | colleague of yours summed up some more negatives with new objects |
| 20:57 | <TabAtkins_> | Yeah, but I don't know how valid I think those are. |
| 20:58 | <annevk> | well, I think they're valid |
| 21:00 | <TabAtkins_> | Complaining about binding gunk is a *pure* impl concern, with no effect on authors or users (unlike memory usage). Rejecting something that may be simpler for authors just because the backend plumbing in the implementation might be a little bit heftier (not more complicated) seems like a bad move. |
| 21:01 | <jamesr_> | having nearly-duplicate bindings is a burden on authors |
| 21:02 | <annevk> | it complicates testing a lot, it requires authors to make informed decisions and for the foreseeable future to have different constructor codepaths, different prototype paths, etc. |
| 21:03 | <TabAtkins_> | jamesr_: It was precisely the non-duplicate part that seems to be the problem, though. |
| 21:04 | <annevk> | it's like |
| 21:05 | <Hixie> | ok i wrote a counter-CP for <link rel=noreferrer> |
| 21:05 | <annevk> | o i know, lets do Cookie2 |
| 21:05 | <jamesr_> | i don't really see any issues with putting responseType/response on the XHR object |
| 21:05 | <annevk> | now you have 2 problems |
| 21:05 | <annevk> | or in the XHR case, 4 |
| 21:05 | <jamesr_> | code that only wants to think about .responseText will work fine since it won't mutate responseType |
| 21:06 | <annevk> | Hixie, changing it to rel=anonymous would make some sense |
| 21:07 | <annevk> | Hixie, especially if we add a way to <img>, <script>, and <video>/<audio> to set it too |
| 21:07 | <annevk> | and <form>? |
| 21:07 | <TabAtkins_> | Sure. annevk, wasn't it you specifically that was complaining about it being potentially confusing that .responseText would still be available on a binary request? |
| 21:08 | <annevk> | Boris and I, yes |
| 21:08 | <TabAtkins_> | So... |
| 21:08 | <TabAtkins_> | I'm confused then. |
| 21:08 | <annevk> | binary logic does that to you ;p |
| 21:09 | <TabAtkins_> | Binary logic is 'murrican. |
| 21:09 | <annevk> | That I think it is confusing does not mean I want to go to the extreme of having more objects |
| 21:09 | <annevk> | It just means I will not get my way |
| 21:10 | <jamesr_> | the XHR interface is horrible and gross and confusing, but there's not very much we can do to fix that at this point |
| 21:10 | <jamesr_> | that work was mostly done a decade ago |
| 21:11 | <annevk> | maybe over a decade now |
| 21:11 | <annevk> | Mozilla added it in 2000, I believe |
| 21:11 | <TabAtkins_> | So the idea is just that we make .response always return the correct type, and leave .responseText and .responseXML for when the type is set to Text or whatever. |
| 21:11 | <TabAtkins_> | ? |
| 21:12 | <annevk> | something like that |
| 21:12 | <TabAtkins_> | That's fine with me, I just thought you'd want to address your objection, and I think new constructors is the only way to do that. ^_^ |
| 21:13 | <annevk> | I suspect something like "legacy" / "text" / "document" / "arraybuffer" / "blob" or some such would be it depending on impl strategies |
| 21:13 | <annevk> | addressing objections by compromise generally leads to poor design :( |
| 21:13 | <annevk> | (not that XHR is nicely designed or anything :) ) |
| 21:14 | <TabAtkins_> | Hmm, "legacy" seems pretty nice. Perhaps .response could contain nothing if the type was "legacy"? |
| 21:14 | <jamesr_> | i think jonas' suggestion was that empty string would be the default value and it would mean the old way |
| 21:15 | <annevk> | yeah ok |
| 21:15 | <TabAtkins_> | Ah, so you could test .responseType as a boolean and see if you're allowed to grab from .response or not? |
| 21:15 | <jamesr_> | i don't think anyone will actually set the 'legacy' value |
| 21:15 | <annevk> | haven't really thought out how the API should look... still don't like the name responseType |
| 21:18 | <jamesr_> | yeah i dunno about the name. i like the properties of it |
| 21:23 | <jamesr_> | i'd really prefer if we had separate APIs for interacting with the network and interpreting the results and good easy ways to chain them together |
| 21:23 | <TabAtkins_> | Yeah. |
| 21:24 | <jamesr_> | one thing people have mentioned is they want to download a chunk of data and interpret portions of it as (say) utf-8 text |
| 21:24 | <jamesr_> | but interpret another portion as an ArrayBuffer of floats or whatever |
| 21:25 | <Ms2ger> | You want good APIS on the web? |
| 21:25 | <jamesr_> | since the networking API is also the text decoding API there's no good way to do that now without base64ing the binary portion or something equally yucky |
| 21:25 | <Ms2ger> | Ha. Haha. Hahaha. |
| 21:26 | <TabAtkins_> | Right, but changing over to using .responseType='arraybuffer' lets you then interpret the bytes as anything you want. |
| 21:26 | <jamesr_> | yeah, that gets closer. we also need a way to pass a view into an arraybuffer to the browser and tell it to do text decoding |
| 21:28 | <TabAtkins_> | Right. |
| 21:28 | <TabAtkins_> | Luckily, that's orthogonal (as it should be). |
| 21:28 | <jamesr_> | yup. gettin' there |
| 21:29 | <jamesr_> | i think it'll take some work to get this to be a little less awkward |
| 21:31 | <virtuelv> | Hixie: I take it you also nuked the spam so it won't show up in the archives either? |
| 21:32 | <TabAtkins_> | Unless he wants to get the archives blacklisted by Google, I suspect he has. |
| 21:44 | <annevk> | really book + nap time now |
| 21:44 | <annevk> | nn |
| 22:09 | jgraham | would prefer a constant to a string for .response, assuming we go down that road, fwiw |
| 22:10 | <jgraham> | s/.response/.responseType/ |
| 22:10 | <TabAtkins_> | The only problem with constants is figuring out where to place them. A constant on XMLHTTPRequest would be *horrible* for typing. |
| 22:11 | <TabAtkins_> | XMLHttpRequest.responseType = XMLHttpRequest.RESPONSE_ARRAYBUFFER (or something) |
| 22:17 | <jgraham> | Still a bit better than strings I think |
| 22:17 | <TabAtkins_> | I violently disagree. |
| 22:17 | <jgraham> | Well even just using emacs and M+/ I can likely autocomplete the XMLHttpRequest part |
| 22:18 | <TabAtkins_> | A string value is best, with .responseType resetting to '' if it doesn't recognize the value (like input@type does). |
| 22:18 | <TabAtkins_> | I am deeply opposed to gratuitous verbosity. |
| 22:18 | <jgraham> | I am deeply opposed to using strings to indicate one of a finite number of choices where it can be avoided |
| 22:19 | <jgraham> | Although I have been known to do it occasionally |
| 22:19 | <jgraham> | I have always felt it was wrong |
| 22:19 | <TabAtkins_> | If the API object was actually named XHR instead of XMLHttpRequest, I'd be more inclined to accept constants. |
| 22:20 | <jgraham> | Given that this will all be abstracted away by libraries anyway a little verbosity doesn't seem like a big deal |
| 22:20 | <TabAtkins_> | I am violently opposed to that point of view. ^_^ |
| 22:21 | <jgraham> | Although I guess one could ask WWJD (jQuery) |
| 22:21 | <jgraham> | Well it is kind of a "tools will save us" argument |
| 22:21 | <TabAtkins_> | The web platform should be the API you program to by default. We shouldn't design for libraries, unless we are explicitly trying to design a low-level api (like indexeddb). |
| 22:21 | <jgraham> | But I have already given up hope on the DOM in general and XHR in particular being pretty |
| 22:21 | <jgraham> | (add commas) |
| 22:22 | <jgraham> | Well it *isn't* the API that people program by default |
| 22:22 | <TabAtkins_> | I'm surprised you didn't go with s//,/ |
| 22:22 | <jgraham> | would have been s//,/g |
| 22:22 | <TabAtkins_> | "It sucks" shouldn't be an argument to make it suck more. |
| 22:23 | <jgraham> | Yeah, which is why using strings is a bad idea :) |
| 22:23 | <TabAtkins_> | Strings are perfectly acceptable and familiar. What's your reason for hating them? |
| 22:23 | <jgraham> | Because there are only a few well defined options. |
| 22:24 | <jgraham> | Using strings makes that unclear and makes it easier to make mistakes |
| 22:24 | <jgraham> | Particularly in tooled-up dev environements that will autocomplete for you |
| 22:25 | <TabAtkins_> | I don't see how this would prevent auto-completion. |
| 22:26 | <Hixie> | virtuelv: i don't have any control over the archives |
| 22:26 | <jgraham> | It seems harder to build autocompletion that knows that the input foo.responseText = " should result in the right autocompletion options |
| 22:27 | <jgraham> | Argh |
| 22:27 | <jgraham> | Type |
| 22:27 | <TabAtkins_> | Heh. |
| 22:27 | <jgraham> | Compared to the constants case where XMLHttpRequest is a known global object and had known properties |
| 22:27 | <TabAtkins_> | (Unrelated: Ooh, json should be a responsetype too. I use the "json" type in jquery all the time.) |
| 22:28 | <jgraham> | Yes, it should |
| 22:28 | <TabAtkins_> | Harder, yeah. But not so much that it's unreasonable. |
| 22:29 | <jgraham> | I don't really use IDEs that do that sort of thing, but are they really clever enough to do the first autocompletion in javascript? |
| 22:29 | <jgraham> | It seems like it would be hugely difficult |
| 22:30 | <jgraham> | Or very prone to false positives |
| 22:30 | <jgraham> | Because you can't know the type of foo |
| 22:31 | <jgraham> | So you can't work out what foo.responseType refers to |
| 22:31 | <jgraham> | So at best you can guess that the rhs of an assignment to a property called response type should be one of the magic strings |
| 22:31 | <TabAtkins_> | I doubt the false positive rate for that would be too high. |
| 22:32 | <TabAtkins_> | Alternately: I don't really care about autocompletion, and don't use it anywhere. |
| 22:32 | <jgraham> | Maybe not for this specific case, but if you implemented that feature in general |
| 22:32 | <jgraham> | Well, like I say I mainly use the magic of M+/ |
| 22:32 | <jgraham> | But I don't think we should go out of our way to make this hard |
| 22:32 | <virtuelv> | Hixie: oh, I see - you actually seem to need raw access to the mbox files and delete them from there before regenerating it |
| 22:33 | <Hixie> | virtuelv: yeah, i don't have access to that at all, that's all done by dreamhost |
| 22:33 | <TabAtkins_> | Hixie: XSLT transformation. |
| 22:33 | <Hixie> | TabAtkins_: DOM model. |
| 22:34 | Hixie | guesses at the rules of this game |
| 22:34 | <TabAtkins_> | (Really, you can probably just ask Dreamhost to kill them for you.) |
| 22:34 | <Hixie> | probably |
| 22:34 | <TabAtkins_> | (The game is "what's the most ridiculous way Hixie could remove the child porn from the archives?".) |
| 22:34 | <Hixie> | aah |
| 22:34 | <Hixie> | wait, is there actual child porn? i thought it was just links |
| 22:35 | <TabAtkins_> | Yeah, sure. |
| 22:35 | <TabAtkins_> | I only looked at one because it had responses, and I only saw links. |
| 22:35 | <Hixie> | i have to admit that my filters actually caught everything so i wasn't aware of the problem until it was mentioned on irc |
| 22:35 | <Hixie> | and i can't say i looked at the mails themselves |
| 22:35 | <Hixie> | beyond the subject lines |
| 22:37 | <TabAtkins_> | I have my filters specifically set up to never auto-spam anything from whatwg, because otherwise emails from @google.com trigger false-positives and get spammed. |
| 22:40 | <Hixie> | heh |
| 22:42 | <jgraham> | Hmm, seems travis has a point about the load event for inline scripts. Where did that come from? |
| 22:51 | <TabAtkins_> | Is there anything fundamentally wrong with having an @rule without a space between the keyword and other information? Specifically, I'm wondering if it's okay to have an @this keyword for nesting selectors, and just make it the @this act like an element reference, so you can do @this:hover to specialize the selector for hover. |
| 22:52 | <Hixie> | i don't really understand the proposal |
| 22:52 | <Hixie> | btw, mac os x has really nice ui for rtl editing |
| 22:52 | <Hixie> | when you're between an ltr and an rtl span, the cursor splits in half! |
| 22:52 | <Hixie> | it's neat |
| 23:01 | <othermaciej> | I thought we copied the split cursor from Windows |
| 23:01 | <othermaciej> | (split caret really) |
| 23:02 | <Hixie> | ah |
| 23:02 | <Hixie> | haven't used windows in a while |
| 23:11 | <MikeSmith> | http://www.w3.org/2010/11/10-webperf-minutes.html |
| 23:11 | <MikeSmith> | "Moving forward with Private Domain definition of same origin, where hello.bar.com is the same private domain as foo.bar.com" |
| 23:12 | MikeSmith | tries to read through list mail to see what the use case is |
| 23:21 | robman | thinks MikeSmith needs a new hobby |
| 23:24 | <TabAtkins_> | Hixie: Okay, like, say you have a long complicated selector pointing to a button. You want to provide some styles, and additional style it in :hover, :active, :focus, etc. Maybe style it differently when it has .disabled too. |
| 23:24 | <MikeSmith> | robman: I tried cross-stitch but I never felt fully accepted in the cross-stitch community |
| 23:25 | <robman> | they're a bunch of pricks |
| 23:25 | <robman> | har har har (dad joke0 |
| 23:25 | <TabAtkins_> | Hixie: Writing out the long selector every time, like you do today, is both overly verbose and brittle, as any change to the base selector has to be reflected across all the instances. |
| 23:25 | <Hixie> | TabAtkins_: ah |
| 23:25 | <TabAtkins_> | So instead, something like "long > verbose > selector { prop: value; @this:hover { prop: value; }}" |
| 23:26 | <Hixie> | would you want to be able to use combinators in this featyre? |
| 23:26 | <Hixie> | feature |
| 23:26 | <TabAtkins_> | Yes. |
| 23:26 | <TabAtkins_> | long > verbose > selector { prop: value; @this + more > elems { prop: value; }} |
| 23:26 | <Hixie> | i.e. "my long selector" and "my long selector child"? |
| 23:26 | hober | would love such a feature |
| 23:26 | <Hixie> | hm |
| 23:26 | <Hixie> | @this seems like a really ugly way to do it, but i could see it making sense |
| 23:27 | <TabAtkins_> | @this is just the best name we've come up with so far. |
| 23:27 | <Hixie> | i'd recommend reusing whatever syntax we use to refer to the subject with :matches() |
| 23:27 | <Hixie> | which i think is currently "#" |
| 23:27 | <Hixie> | and then do: |
| 23:28 | <Hixie> | @group my long selector { # { color: black; } #:hover { color: red; } #:hover em { color: pink; } } |
| 23:28 | <TabAtkins_> | Ah, so within the top-level @group block, # has a special meanign? |
| 23:28 | <Hixie> | yeah |
| 23:28 | <Hixie> | you could even nest them |
| 23:28 | <TabAtkins_> | That's very possible too. |
| 23:29 | <Hixie> | @group .REC { @group # p { @group #.copyright { ... } ... } ... } |
| 23:29 | <Hixie> | would be a long-winded way of writing .REC p.copyright { ... } |
| 23:30 | <Hixie> | (but it'd be less long-winded if you started having more rules, obviously) |
| 23:30 | <TabAtkins_> | This sounds intriguing.\ |
| 23:30 | <Hixie> | :matches() uses '#' in a similar way |
| 23:30 | <aho> | <TabAtkins_> Hixie: Okay, like, say you have a long complicated selector pointing to a button. <- bad architecture. implies that the style is location specific, which should be avoided in first place :> |
| 23:31 | <TabAtkins_> | I'm also pretty excited about the potential optimization potential here, since this is an explicit indicator of scoping |
| 23:31 | <Hixie> | body > p:matches(# + footer) { ... } /* matches the <p> before <footer> where both a children of <body> */ |
| 23:31 | <aho> | i.e. a .whatever-button should look the same no matter where you place it |
| 23:31 | <Hixie> | generally i'd say using classes is bad architecture |
| 23:31 | <TabAtkins_> | aho: Not always. The long complicated part could be just jumping down into the article of a page structurally, rather than requiring the author to tag the article with an id. |
| 23:31 | <Hixie> | and location specific is good practice :-) |
| 23:32 | <aho> | location specific is f-ing awful :) |
| 23:32 | <aho> | it doesn't scale |
| 23:32 | <TabAtkins_> | "body > section > article button" is long enough to be annoying. |
| 23:32 | <Hixie> | scales fine |
| 23:32 | <Hixie> | especially if you have @group |
| 23:32 | <aho> | which you currently don't have anywhere .) |
| 23:32 | <Hixie> | .class is bad because it implies you're not using semantics well enough :-) |
| 23:33 | <aho> | the semantics aren't fine-grained enough |
| 23:33 | <Hixie> | they often are, if you're willing to make things context-aware in the style sheet |
| 23:33 | <aho> | you mean... location specific? :> |
| 23:34 | <Hixie> | sure |
| 23:34 | <Hixie> | whatever you call it :-) |
| 23:34 | <Hixie> | i tend to think of location as physical location, so i prefer the word context |
| 23:34 | <Hixie> | but either is fine |
| 23:34 | <aho> | i call it... bloaty, fragile, repetitive, specificity wars, etc ;) |
| 23:35 | <Hixie> | *shrug* |
| 23:35 | <aho> | or just... "more work" |
| 23:35 | <TabAtkins_> | I tend to use as few classes and ids as possible in my doc. I generally only scatter them around as scoping hooks so I can prefix a structural selector with them. |
| 23:37 | <aho> | http://www.slideshare.net/stubbornella |
| 23:37 | <aho> | css bloat & 5 mistakes of massive css |
| 23:38 | <robman> | aho - oocss rawks 8) |
| 23:38 | <aho> | i totally agree with her :> |
| 23:38 | <aho> | ye |
| 23:38 | <aho> | love the concept |
| 23:38 | <TabAtkins_> | I've written and mainted stylesheets for a middle-size company using mostly structural selectors. The sheets were neither fragile nor bloated. |
| 23:38 | <TabAtkins_> | Repetitive, yes, which is a problem I want to solve. |
| 23:39 | <aho> | i'm doing ecommerce thingies most of the time |
| 23:39 | <aho> | last 2 clients were toyota and audi for example... they want really complicated stuff |
| 23:39 | <Hixie> | i find if you use the semantics properly, and make good use of everything HTML provides, and use CSS features like pseudo-classes and attribute selectors, etc, that context-based selectors tend to be more reliable and simpler to maintain than using classes |
| 23:40 | <aho> | ie6 |
| 23:40 | <aho> | there |
| 23:40 | <aho> | i said it |
| 23:40 | <aho> | :f |
| 23:40 | <TabAtkins_> | Why should I care about IE6? |
| 23:40 | TabAtkins_ | stopped supporting that years ago. |
| 23:40 | <aho> | audi got like 60-70% ie6 internally |
| 23:40 | <Hixie> | i target standards-compliant browsers only, not deployed browsers, so my situation may be less representative :-) |
| 23:40 | <aho> | cant really skip ie6 there, can i? |
| 23:41 | <Hixie> | however, you didn't say that context-aware rules didn't work with deployed browsers, you said they were bloaty and fragile |
| 23:41 | <TabAtkins_> | No, but I don't care about audi in that case. I wouldn't accept a job with them, and wouldn't accept a contract without a hefy extra fee. |
| 23:41 | <aho> | well, the better term is unpredictable... perhaps |
| 23:41 | <aho> | like a h2 will look different depending on where you put it |
| 23:42 | <aho> | that's a bad thing |
| 23:42 | <TabAtkins_> | ...yes? |
| 23:42 | <TabAtkins_> | No, that's how things are supposed to work. |
| 23:42 | <TabAtkins_> | An <h2> in my <nav> should be different than one in my <article>. |
| 23:42 | <aho> | check nicole's talks |
| 23:42 | <TabAtkins_> | I've seen them before. I disagree. ^_^ |
| 23:42 | <aho> | but she's right |
| 23:42 | <TabAtkins_> | No...? |
| 23:43 | <aho> | (at a bigger scale you really have to do it that way) |
| 23:43 | <webr3> | annevk, around? |
| 23:43 | <aho> | unless you want to write 2-4 times as much css |
| 23:43 | <TabAtkins_> | Like I said, I've maintained decent-size websites using my techniques, and didn't have to write a ton of CSS. |
| 23:44 | <TabAtkins_> | More importantly, I didn't have to write a lot of HTML with classes and ids thrown around all over the place, nor did the other people responsible for editting the site who are much less HTML-savvy. |
| 23:44 | <aho> | i usually have to write crazy amounts of css because the layouts are really complicated and detailed |
| 23:44 | <TabAtkins_> | Write cleaner layouts. ^_^ |
| 23:45 | <aho> | i don't do the design... and in these cases we aren't involved in that step at all |
| 23:45 | <TabAtkins_> | I identify the break points in the page structure, where what's inside doesn't have much relevance to what's outside, and tag them. Then I hook structural selectors off of those tags. |
| 23:47 | <aho> | look, with a simple layout i can easily get away with very little extra markup and very little css :> |
| 23:47 | <TabAtkins_> | I assure you that I've gotten away with this with relatively complex layouts. I've been a webdev for years. ^_^ |
| 23:47 | <aho> | the problem are complex layouts which also need to work in crap browsers |
| 23:47 | <TabAtkins_> | Correct. |
| 23:48 | <aho> | cant do anything about either factor |
| 23:48 | <TabAtkins_> | Lowest-common-denominator means you have to write things very explicitly. That has nothing to do with best practice for modern browsers. |
| 23:48 | <aho> | well... d'oh :P |
| 23:48 | <TabAtkins_> | I mean, ffs, IE6 doesn't support the child selector. |
| 23:48 | <aho> | child combinator |
| 23:48 | <aho> | yea |
| 23:48 | <TabAtkins_> | s/selector/combinator/ |
| 23:48 | <aho> | big problem |
| 23:49 | <aho> | current project doesnt support ie6... it's a lot more fun |
| 23:49 | <aho> | <: |
| 23:49 | <TabAtkins_> | So *anything* you do for IE6 has *zero* applicability for other browsers. In fact, trying to apply IE6-inspired lessons is probably actively harmful, since you often want to avoid the descendant selector as much as possible. |
| 23:49 | <Hixie> | i agree that classes are probably the best way to do things if you target IE6 |
| 23:49 | <Hixie> | then again, if you target IE6 you're probably better off using <table>s for layout, too |
| 23:49 | <Hixie> | doesn't mean that it's the best way to do things in theory |
| 23:49 | <TabAtkins_> | Agreed. |
| 23:50 | <aho> | naaah... these concepts aren't about ie6 |
| 23:50 | <aho> | it's about doing things in reverse |
| 23:50 | <aho> | define structures, write css, create markup... and it looks right to begin with |
| 23:50 | <aho> | little tiny bricks which can be combined in arbitrary ways |
| 23:51 | <TabAtkins_> | I create markup then write CSS, and it looks right to begin with. |
| 23:51 | <aho> | then you create new markup |
| 23:51 | <aho> | and then you need to write more css |
| 23:51 | <aho> | :> |
| 23:51 | <aho> | it's all about excessive reuse |
| 23:51 | <TabAtkins_> | ...yes? It's new markup, which doesn't have any style rules yet. On the other hand, if it's just a new kind of existing content, then it's already covered. |
| 23:52 | <TabAtkins_> | That is, if I'm just making a new page within an existing site, I can probably get away with no CSS, or maybe just a handful of rules to cover that specific page. |
| 23:52 | <aho> | it's a new combination of existing building blocks |
| 23:52 | <aho> | top down vs bottom up, basically |
| 23:53 | <TabAtkins_> | If so, then I don't need any new CSS if I've done my job right from the beginning. |
| 23:53 | <TabAtkins_> | If I'm just resuing existing constructs but need new CSS for it, then I did something wrong in my initial coding. |
| 23:53 | <Hixie> | the best practice is to write the HTML first, without any CSS at all, no classes and IDs except those needed by script, and only then to write the CSS -- because you can then write multiple alternative style sheets without having to worry about changing the markup at all |
| 23:53 | <Hixie> | it just doesn't make sense to use classes in such a scenario |
| 23:54 | <aho> | well, apparently it's easier to do it right if you start with tiny pieces and create everything out of those things |
| 23:54 | <aho> | it's like lego :) |
| 23:55 | <TabAtkins_> | Building it from the bottom up means you have to be more explicit, which can be easier in some circumstances. I like the cleanliness and easy maintainabily of taking a more holistic view. |
| 23:56 | <aho> | there is no holistic view if there are hundrets of components which need to look correct and uniform |
| 23:56 | <TabAtkins_> | Actually, making everything look uniform is easier, I would think, by designing the rules top-down. |
| 23:56 | <aho> | our relatively simple shop system got over 200 different components for example |
| 23:57 | <TabAtkins_> | Rather than repeating for each component what a heading should look like. |
| 23:58 | <aho> | IM(hard earned)E it's a *lot* easier (and quicker and far more maintainable) with tiny legos |
| 23:58 | <TabAtkins_> | I don't think you can claim that such an approach is less bloaty, though. |
| 23:58 | <aho> | it also results in way smaller css files |
| 23:58 | <aho> | especially if there are several update cycles |
| 23:58 | <TabAtkins_> | A hundred ".component1 > h1", ".component2 > h1", ".component3 > h1" rules is quite a bit more verbose than a single consistent ".component > h1" rule. |
| 23:59 | <aho> | you can use multiple classes :> |