| 00:00 | <jamesr> | Lachy: copy-paste it into a JS string, query the codepoint? |
| 00:01 | <dglazkov> | Lachy: it's painted straight up: http://google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderDetailsMarker.cpp&l=190 |
| 00:01 | <jamesr> | ah it's not a glyph |
| 00:01 | <dglazkov> | Lachy: the details/summary implementation is a total hack at this point |
| 00:01 | <dglazkov> | Lachy: please don't feel encouraged to use it as an example :) |
| 00:02 | <Lachy> | dglazkov, oh, trust me, we've been having fun breaking it. We know how bad it is |
| 00:02 | <dglazkov> | Lachy: follow this bug https://bugs.webkit.org/show_bug.cgi?id=56967 |
| 00:04 | <Lachy> | thanks |
| 00:05 | <Lachy> | dglazkov, we want to use a character glyph, so we can do the styles with display: list-item; (as discussed in the mail I sent yesterday to whatwg) |
| 00:06 | <dglazkov> | Lachy: that seems like a path to fail. Why? |
| 00:06 | <Lachy> | because of all the options, it's the only one that actually works and meets all the requirements we had |
| 00:06 | <TabAtkins> | dglazkov: I think it's the best solution, as the disclosure widget acts exactly like ::marker |
| 00:06 | <Lachy> | dglazkov, read that mail I sent. It explains everything |
| 00:06 | <dglazkov> | Lachy: ok |
| 00:07 | <dglazkov> | can I have a 1-minute summary why it can't be a div? |
| 00:07 | <dglazkov> | :) |
| 00:08 | <dglazkov> | I'd rather have a nice block to play with |
| 00:08 | <TabAtkins> | Becasue the disclosure triangle acts exactly like a ::marker. |
| 00:09 | <Lachy> | the shadow dom approach that inserts block elemtns around the summary and content interferes too much with styles. |
| 00:09 | <Lachy> | if you try to position the disclosure triangle box with negative margins, then it interferes with :the :before pseudo-element. |
| 00:10 | <Lachy> | if authors apply display: inline; to summary and details when they contain block boxes in the shadow dom, then it doesn't work. |
| 00:11 | <Lachy> | If they have <details><summary>Test</summary><div>Content</div></details> with the styles details { display: table; } summary, div { display: table-cell; }, it doesn't work because of the way the layout table-* boxes are generated |
| 00:13 | <dglazkov> | Lachy: why do we worry about letting the authors shoot themselves in the foot? :) |
| 00:13 | <Lachy> | dglazkov, we don't want to end up with the same situation we have with fieldset and legend, where restyling is troublesome |
| 00:14 | <Lachy> | plus, display: list-item; lets authors use list-style-type and list-style-image to render custom icons, or to remove it entirely. |
| 00:15 | <Lachy> | if you try to do it with bindings, then you have to create a new special pseudo-element to handle it |
| 00:15 | <dglazkov> | I fully intend to introduce a new pseudo-element for details marker, and probably the box around |
| 00:16 | <erlehmann> | for great justice! |
| 00:16 | <Lachy> | trust me, we tried that, and it won't work. It's far too fragile. |
| 00:16 | <erlehmann> | fieldset and legend is awful. :< |
| 00:16 | <TabAtkins> | Problem: making the triangle manually as a pseudo-element doesn't seem possible, as it should act like a child of summary. We don't have any way with XBL2 or Components to insert a shadow into a light node. |
| 00:17 | <Lachy> | TabAtkins, what are these Components you're referring to? |
| 00:17 | <TabAtkins> | The "Web Component Model" thing dglazkov brought up on webapps a few weeks ago - our attempt to tweak XBL2 to be better. |
| 00:17 | <Lachy> | and what do you mean by a "light node"? |
| 00:18 | <TabAtkins> | light node = normal dom node |
| 00:18 | <TabAtkins> | (as opposed to shadow nodes, which live in the shadow tree) |
| 00:19 | <dglazkov> | Lachy: fragile, like freedom starts with an f |
| 00:20 | <dglazkov> | :P |
| 00:21 | <TabAtkins> | The structure you want is <details><summary><::shadow(disclosure) />[summary contents]</summary><::shadow(content)>[other contents]</::shadow(content)></details> |
| 00:21 | <dglazkov> | TabAtkins: see bug, I have a diagram there |
| 00:22 | <dglazkov> | Lachy: with component model arriving soon, the notion of encapsulated DOM with hooks (pseudo-elements) to tweak it is something I hope will become commonplace |
| 00:22 | <Lachy> | TabAtkins, that breaks the ::before case |
| 00:22 | <TabAtkins> | No, that's not the structure you want. That structure means that styles that target "summary" don't hit what you want. |
| 00:23 | <TabAtkins> | At least, I assume that you want the disclosure to appear to be inside the <summary>. |
| 00:25 | <TabAtkins> | Such that if I do "summary { border: 1px solid black; }", the border encloses the triangle too. |
| 00:26 | <dglazkov> | TabAtkins: ah, so summary has a shadow that contains the marker. Sure.. |
| 00:26 | <TabAtkins> | Oh, hm. Yeah, defining <summary> as having a shadow itself would work, I guess. |
| 00:27 | <TabAtkins> | Assuming we get the right behavior with ::before. |
| 00:27 | <dglazkov> | TabAtkins: except we'll have to make sure it doesn't show up on a free-standing or the summary that isn't in the right slot |
| 00:28 | <TabAtkins> | That shouldn't be hard, I guess - you can target things like "details > summary:not(:first-of-type)::disclosure { display: none; }" |
| 00:28 | <Lachy> | TabAtkins, I had an experiment using <summary><::disclosure></::dislosure><::before></::before>[summary text]</summary>, where the disclosure was positioned with negative margin and compensating padding added to the summary element. |
| 00:29 | <dglazkov> | TabAtkins: sounds good |
| 00:29 | <Lachy> | but that caused an unexpected problem when the page has a space at the beginning of the summary text. i.e. <summary>Example</summary> vs. <summary> Example</summary> |
| 00:29 | dglazkov | imagines the world where new interactive tags are spec'd as component model implementations. |
| 00:29 | <TabAtkins> | Lachy: Hm, what was the problem? |
| 00:30 | <Lachy> | The first would render like: ▸Example, the latter would render with a space like "▸ Example" |
| 00:30 | <Lachy> | In fact, try that in Chrome's implementation. It has the same problem now |
| 00:30 | <Lachy> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdetails%3E%3Csummary%3EExample%3C%2Fsummary%3E%3C%2Fdetails%3E%0A%3Cdetails%3E%3Csummary%3E%20Example%3C%2Fsummary%3E%3C%2Fdetails%3E%0A |
| 00:31 | <TabAtkins> | Hm, why doesn't that cause a similar problem with display:list-item? The white-space collapsing should be identical, right? |
| 00:31 | <Lachy> | that problem doesn't occur with the list-item ::marker, which is has list-style-position: outside; |
| 00:35 | <TabAtkins> | What part of that causes the different whitespace behavior? |
| 00:35 | <Lachy> | actually, it doesn't occur with ::marker even list-style-position: inside;. But I don't know any way to achieve that when you're using DOM nodes to indirectly create layout boxes |
| 00:36 | <Lachy> | TabAtkins, because it's exactly like this http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3Ep%3A%3Abefore%20%7B%20content%3A%20%22x%22%3B%20%7D%3C%2Fstyle%3E%0D%0A%3Cp%3ETest%3Cp%3E%20Test |
| 00:37 | <Lachy> | ::marker has special handling here |
| 00:38 | <Lachy> | or, rather, it would have to if it were implemented by anyone. |
| 00:38 | <TabAtkins> | Damn, I didn't realize it did. Well, when l-s-p is 'outside' or 'hanging', it's abspos, so the problem doesn't occur. Only 'inside' needs the special behavior, which I now need to go figure out and spec, dammit. |
| 00:39 | <Lachy> | :-) |
| 00:39 | TabAtkins | files an issue on the spec. |
| 00:50 | <Lachy> | TabAtkins, are you really defining the handling of 'hanging' and 'outside' in terms of absolute positioning? How does that work, without having the li element set to position: relative; to establish a containing block? |
| 00:50 | <TabAtkins> | Since I control the spec, I can control the static position, and set it appropriately so you don't need the list-item to be a positioning container. |
| 00:51 | <TabAtkins> | As long as top/r/b/l are all 'auto', it works just fine. |
| 00:51 | <Lachy> | 'auto' on which element? |
| 00:51 | <TabAtkins> | The ::marker |
| 00:51 | <Lachy> | oh |
| 00:52 | <TabAtkins> | Normally the static position of an abspos is the position of its placeholder (the 0x0 inline box left behind in its original box-tree position), but l-s-p alters that static position for ::marker. |
| 00:53 | <Lachy> | ok |
| 00:53 | <Lachy> | what do the terms '"end" edge', '"start" edge' and '"over" edge' mean? They're not defined |
| 00:54 | <TabAtkins> | writing-dependent box-model terms, defined in Writing Modes. |
| 00:55 | <TabAtkins> | I'll link them properly at some point, but haven't bothered to do so yet. |
| 01:00 | <Lachy> | TabAtkins, it would be nice to have an illustration showing the difference between hanging and outside. I just don't get it. The definitions are confusing |
| 01:02 | <TabAtkins> | There's a good diagram on the mailing list, which I'll include. Basically, 'hanging' attaches the marker to the text (respecting text-align, rtl, etc), while 'outside' attaches it to the list-item's box instead. |
| 01:02 | <TabAtkins> | The main distinction is just that, in a list with mixed-direction items (that is, some items are ltr and some are rtl), 'outside' will keep all the markers on a consistent side. |
| 01:03 | <TabAtkins> | (determined by the parent's directionality, rather than the list item's) |
| 01:03 | <Lachy> | link to the diagram? |
| 01:03 | <TabAtkins> | Sure, one sec. |
| 01:05 | <TabAtkins> | http://lists.w3.org/Archives/Public/www-style/2011Feb/0522.html |
| 01:08 | <Lachy> | oh, it looks like Firefox's implementation of 'outside' is more like 'hanging' Chrome and Opera agree with the diagram, I think. |
| 01:09 | <TabAtkins> | Yes, FF does what I define as 'hanging'. And I thought that one other browser did, too. |
| 01:09 | <TabAtkins> | I know that IE does what I define as 'outside'. |
| 01:09 | <TabAtkins> | I was pretty sure the rendering engines were split 2 and 2. |
| 01:10 | <Lachy> | ok, then I assume there's no compat problems with defining it that way. |
| 01:10 | <TabAtkins> | Yeah. |
| 01:10 | <TabAtkins> | At least, in general. It's possible (/likely) my precise definitions aren't quite compatible yet. |
| 02:49 | <Hixie> | dglazkov|away: the <template>, if it's like XBL |
| 02:49 | <Hixie> | nessy: friday or early next week (had to take the week off for family reasons unfortunately) |
| 07:34 | <hsivonen> | It's quite sad how the HTML.next wiki page doesn't include use cases |
| 08:24 | <kennyluck> | What is the story behind that page? |
| 08:41 | <MikeSmith> | kennyluck: which page? |
| 08:41 | <kennyluck> | The HTML.next wiki page. |
| 08:42 | <MikeSmith> | http://www.w3.org/html/wg/wiki/index.php?title=HTML.next&action=history |
| 08:44 | <kennyluck> | lol. I mean, what makes people suddenly interested in working on this page? A WG decision? |
| 08:46 | <krijnh> | -_- |
| 08:47 | <Lachy> | kennyluck, I think the idea is to get a list of features to include in the new charter for the HTMLWG. |
| 08:48 | <kennyluck> | Lachy, I see. |
| 08:48 | <Lachy> | it's a process thing. I guess, since the group is only chartered to work on HTML5. After it goes to last call, they can technically only maintain that and realted specs and can't start on HTML6. |
| 08:49 | <othermaciej> | the actual benefit of writing down ideas is: |
| 08:49 | <othermaciej> | (a) medium-term, it will help us ensure that the right things are in our next charter |
| 08:49 | <othermaciej> | (b) short-term, the AC is interested in hearing what we might be up to next |
| 08:55 | <hsivonen> | that the AC is involved in deciding on the next features sounds suspicious |
| 08:57 | <MikeSmith> | fwiw, I just took the list of specs I had at http://www.w3.org/wiki/Testing/Specs and moved it to http://www.w3.org/wiki/BrowserTechnologies |
| 09:02 | <MikeSmith> | looks like I may be going to Perth at the end of July for a couple days |
| 09:02 | <MikeSmith> | so would be great to plan to meet up with any #whatwg folk who might be there |
| 09:03 | <jgraham> | MikeSmith: Hark at the globetrotting lifestyle |
| 09:04 | <MikeSmith> | more like globetottering |
| 09:04 | <MikeSmith> | in my case |
| 09:04 | <MikeSmith> | globestumbling |
| 09:06 | <gsnedders> | hsivonen: does the charter not normally "suggest" or "encourage" certain features to be looked at? Surely the AC doing that is nothing unusual? |
| 09:08 | <hsivonen> | gsnedders: charters tend to be higher level than individual features |
| 09:09 | <MikeSmith> | jgraham: so were are at the point in discussions about the common testing framework where scope creep has started to in appear |
| 09:09 | <MikeSmith> | in that the way I attempted to scope it was relatively well-bounded |
| 09:09 | <gsnedders> | hsivonen: "The HTML WG is encouraged to provide a mechanism to permit independently developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and RDFa to be mixed into HTML documents." — is that not particuarly specific? |
| 09:10 | <MikeSmith> | jgraham: a common framework for testing features/technologies in browsers |
| 09:10 | <MikeSmith> | I am now getting feedback about that being too restrictive |
| 09:11 | <MikeSmith> | and that the scope needs to include testing authoring tools, media players, "evaluation tools", and AT |
| 09:11 | <hsivonen> | gsnedders: not as specific as most things on the HTML.next page |
| 09:12 | <hsivonen> | gsnedders: note that those points name broad sets of features (or syntax, rather) developed in other WGs |
| 09:12 | <MikeSmith> | jgraham: how were are supposed to come up with a common framework for testing an unbounded set of applications, I don't know |
| 09:12 | <hsivonen> | as opposed to individual potential HTML features like marking up semantic for foo |
| 09:12 | <MikeSmith> | *unbounded set of completely disparate classes of applications |
| 09:13 | <hsivonen> | gsnedders: in general, it seems that the W3C chartering process doesn't really fit the model of writing up specs as stuff that multiple implementors want to implement comes up |
| 09:16 | <hsivonen> | gsnedders: also, the previous process managing to put RDFa and ITS in the charter counts as suspicious to me |
| 09:17 | <jgraham> | MikeSmith: That isn't going to happen |
| 09:17 | <gsnedders> | hsivonen: Is that not an inevitable consquence of the W3C trying to cope with what all members want, not just members who want to directly implement a spec? |
| 09:17 | <jgraham> | MikeSmith: Those things need to be tested, but there will be specific requirments for testing them |
| 09:17 | <MikeSmith> | right |
| 09:18 | <hsivonen> | gsnedders: probably |
| 09:18 | <MikeSmith> | jgraham: a good example I can think of that maybe I already mentioned to you is the case of testing Web Nofications |
| 09:18 | <MikeSmith> | we really can't test what the platform behavior outside of the browser is |
| 09:19 | <MikeSmith> | at least not in an automated way |
| 09:19 | <jgraham> | Indeed |
| 09:19 | <jgraham> | AT is an even better example |
| 09:19 | <gsnedders> | hsivonen: Arguably what we (as browser vendors) should have done is push our opinions on other specs that we aren't interested implementing, and play the same game |
| 09:20 | <MikeSmith> | for notifications, all that we can really test is that the notification object gets created and the show event gets fired at it |
| 09:20 | <jgraham> | At least there is no way I know to interrogate AT about what they are doing |
| 09:20 | <MikeSmith> | jgraham: yeah |
| 09:21 | <jgraham> | Yeah, notifications allow you to test the API but not that a notification is ever shown |
| 09:21 | <jgraham> | Except manually |
| 09:21 | <MikeSmith> | yeah, but you can't even really test that |
| 09:21 | <MikeSmith> | because that part is unspecified |
| 09:21 | <MikeSmith> | by design |
| 09:22 | <MikeSmith> | it is implementation-specific |
| 09:22 | <jgraham> | Hmm, is it not specified that a browser that implements the API has to notify the user in some way? |
| 09:22 | <MikeSmith> | sure |
| 09:22 | <MikeSmith> | but "in some way" is not something that can be tested very rigorously… |
| 09:22 | <jgraham> | Right, so you can write a test that says "you shopuld be notified that 'the test has PASSed'" |
| 09:22 | <jgraham> | or something |
| 09:23 | <jgraham> | That's the kind of test we have for browser features that can't be tested in an automated way |
| 09:23 | <jgraham> | and it really sucks |
| 09:23 | <jgraham> | (so we always try to increase the scope of what can be automated) |
| 09:23 | <MikeSmith> | yeah, I'm just saying that there can be gray areas where it's hard to know if it's if the notification is actually being shown "properly" or whatever |
| 09:24 | <MikeSmith> | because it's not measurable |
| 09:24 | <jgraham> | Indeed, this type of test sucks |
| 09:24 | <MikeSmith> | and what is proper/expected depends on the platform/environment |
| 09:25 | <jgraham> | Yeah, like I said it sucks. It's not that uncommon though |
| 09:27 | <jgraham> | Anyway I agree with your original point. The scope creep is unhelpful because it leaves an unworkable set of requirments |
| 09:27 | <jgraham> | I am all in favour of testing AT and so on, but that needs a dedicated effort |
| 09:37 | <MikeSmith> | I think the way to deal with this is to concede to scope the overall "common testing effort" a bit more broadly, but then have smaller units within that |
| 09:38 | <MikeSmith> | and make one of those a "browser testing" unit |
| 09:38 | <MikeSmith> | and then we work on that part just as we have been |
| 09:39 | <MikeSmith> | and whatever units of the rest of it then along however else others involved with those care to take them |
| 09:39 | <jgraham> | Yeah, that sounds like a viable way to solve the problem |
| 09:39 | <MikeSmith> | so I will pitch that to plh |
| 09:39 | <MikeSmith> | so much depends on plh |
| 09:40 | <MikeSmith> | he is like a red wheelbarrow glazed with rain water |
| 09:47 | <jgraham> | You are going to need to explain that simile |
| 09:49 | <othermaciej> | hsivonen: I don't think they necessarily want to be involved - they just want to be informed (at this point); that being said, the charter has to be approved by the AC |
| 09:49 | <othermaciej> | you are right that the HTML.next page is not at charter-like granularity right now |
| 09:53 | <othermaciej> | for charter purposes, I'm sure there will be interest in enhancing and extending all the existing new features, though I doubt people know exactly how at this point |
| 09:58 | <jgraham> | The main problem with the wiki page (apart from the underlyting notion of a versioned approacch to a continuously evolving technology) seems to be that it is a bizzare mix of the low-level and the high level |
| 10:00 | <MikeSmith> | it's a wiki… |
| 10:01 | <othermaciej> | level mixing is fine for a brainstorming exercise |
| 10:01 | <jgraham> | MikeSmith: Right, but I assume removing other people's contributions on the basis that they are micro-suggestions won't go down well |
| 10:01 | <othermaciej> | ideas that are too small to be worth calling out may turn out to coalesce into themes |
| 10:01 | <othermaciej> | or it would even be fine to predict the theme and make a category for, e.g., "further form control enhancements" |
| 10:01 | <othermaciej> | or "additional semantic markup elements" |
| 10:03 | <othermaciej> | deleting lines from com.apple.WebProcess.sb makes me feel like a good person |
| 10:04 | <othermaciej> | (I guess that is off-topic for this channel) |
| 10:05 | <MikeSmith> | jgraham: yeah, but moving them / reorganizing in a way to un-mix them is usually OK |
| 10:05 | <jgraham> | othermaciej: not really, see /topic |
| 10:08 | <MikeSmith> | what is the current cutting edge in CSS? |
| 10:09 | <MikeSmith> | I know about gradients, animations, and transitions |
| 10:09 | <MikeSmith> | and variables |
| 10:09 | <MikeSmith> | and regions? |
| 10:09 | <Workshiva> | inline-block |
| 10:09 | <kennyluck> | and mixins, I guess. Not yet adopted by CSS WG, though. |
| 10:09 | <MikeSmith> | ah |
| 10:10 | <MikeSmith> | Workshiva, kennyluck - thanks |
| 10:10 | <Workshiva> | I guess flex-box is starting to live? |
| 10:11 | <hsivonen> | I wonder where Opera and Microsoft are at as far as flexbox impl goes |
| 10:11 | hsivonen | is eager to get cross-browser flexbox |
| 10:11 | <Workshiva> | I want to be excited about it, but I feel like I'd be setting myself up for disappointment |
| 10:11 | <Workshiva> | :) |
| 10:16 | <jgraham> | I am English and therefore crave disappointment |
| 10:17 | <Workshiva> | That certainly explains the biscuits |
| 10:26 | <MikeSmith> | Workshiva: were you joking about inline-block? |
| 10:27 | <Workshiva> | Yes |
| 10:27 | <MikeSmith> | oh |
| 10:27 | <MikeSmith> | shows how much I know about CSS… |
| 10:33 | <kennyluck> | Well, the fact that <i> <b> are in HTML5 made me think I know nothing about HTML5 too. |
| 10:38 | <zcorpan> | welcome jeppson |
| 10:38 | <gsnedders> | Oh noes, not jeppson :o |
| 10:42 | <hsivonen> | what are the use cases for http://dev.w3.org/2009/dap/system-info/ ? |
| 10:43 | <othermaciej> | that URL has /dap/ in it, so I'm not sure why you'd ask such a naive question :-) |
| 10:44 | MikeSmith | wonders where things currently stand as far as getting agreement about the "Disallowing modal dialogs during unload events" case |
| 10:54 | <jgraham> | jeppson: (FWIW your email to whatwg basically reads "+1", which is somewhat discouraged) |
| 11:04 | <Lachy> | given the markup <details>before<summary>summary</summary></details> with the style details::first-letter { color: blue; }, with the way the layout boxes are re-ordered, am I right in believing that the 's' in the summary should be blue, not the 'b'? |
| 11:05 | <Lachy> | TabAtkins, dglazkov|away, ^ (btw, that's another case that chromium fails to handle) |
| 11:58 | <jeppson> | jgraham: ok... thanks - didn't know that |
| 14:45 | <erlehmann> | for <details>, the character U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE will only be used in LTR settings, amiright? |
| 14:45 | <erlehmann> | RTL settings, sorry. still sleepy. |
| 14:45 | <jgraham> | Yes |
| 14:45 | <erlehmann> | thx |
| 16:16 | hsivonen | needs a worse server config for testing |
| 16:17 | <TabAtkins> | Lachy: Pretty sure the answer is yes. |
| 16:18 | <Lachy> | TabAtkins, yeah, thought so. That's what I told our developer, who's having trouble with the issue. |
| 16:18 | <hsivonen> | actually, I need a better server config |
| 16:18 | <Lachy> | it seems we're going to have a known bug where ::first-letter will style the wrong letter in that case |
| 16:18 | hsivonen | is unhappy about Ubuntu's Apache defaults |
| 16:18 | <Lachy> | but it's an edge case with an invalid document, so not too concerning |
| 16:19 | <Lachy> | hsivonen, what's wrong with them? |
| 16:19 | <hsivonen> | my AddType application/xml xml isn't taking effect |
| 16:19 | <hsivonen> | there has to be another AddType somewhere saying that xml is text/xml; charset=UTF-8 |
| 16:20 | <Lachy> | does it work for other file extensions? |
| 16:20 | <MikeSmith> | hsivonen: ForceType, maybe |
| 16:20 | <Lachy> | and are you doing that in .htaccess? |
| 16:20 | <hsivonen> | Lachy: it seems to |
| 16:20 | <hsivonen> | I'm doing it in a config file for the virtual host |
| 16:22 | <hsivonen> | well, *this* is odd |
| 16:22 | <hsivonen> | the default config seems to say application/xml, too |
| 16:23 | <hsivonen> | oh. great. I have an ancient .htaccess file that I had forgotten about |
| 16:24 | <bfrohs> | And here you are ganging up on poor, little Ubuntu when it hadn't even done anything :P |
| 16:26 | hsivonen | wonders where the X-Pad: avoid browser bug header comes from |
| 16:27 | <hsivonen> | "Apache send this header to deal with a bug with Netscape versions 2 through 4.0b2." |
| 16:27 | <hsivonen> | great |
| 16:27 | <zewt> | haha |
| 16:28 | <zewt> | there's legacy compatibility and then there's legacy compatibility |
| 16:28 | <wilhelm_> | Beautiful. |
| 16:29 | <hsivonen> | "it only shows up if there's a chance the 256th or 257th byte of a response is a newline." |
| 16:30 | <erlehmann> | the web is a mess. and we just need to fix it! |
| 16:30 | <erlehmann> | (cue dr. horrible theme song) |
| 16:31 | <hsivonen> | well, looks like even Roy's project does works around bugs at the other end of the HTTP pipe |
| 16:35 | <wilhelm_> | I suppose that can be considered payback. |
| 16:37 | <Lachy> | what possible bug could Netscape have had the only showed up with a new line as the 256/257th character? |
| 16:37 | <TabAtkins> | Assuming end of response, probably. |
| 16:38 | <Lachy> | yeah, but that seems very odd |
| 16:38 | <TabAtkins> | That's bugs for ya'. |
| 16:38 | <Lachy> | I'm not even sure you one could make such a specific mistake by accident |
| 16:38 | <hsivonen> | Lachy: 256 is a natural buffer length |
| 16:38 | <zewt> | reading some of the webgl spec, at least in the "diff vs. opengl" version, one thing I like about it: it gives rationale for things |
| 16:39 | <erlehmann> | >All media elements have an autoplaying flag, which must begin in the true state |
| 16:39 | <erlehmann> | What was the rationale for that? |
| 16:42 | <erlehmann> | hue hue hue https://twitter.com/timpritlove/statuses/56016662058631168 |
| 16:42 | <TabAtkins> | Wait, @autoplay is a binary attribute. How do you turn it off if it's on by default? I can't omit the tag any harder! |
| 16:43 | <Lachy> | TabAtkins, it's not on by default. You omit the attribute and it won't autoplay |
| 16:43 | <TabAtkins> | Hm, then. I need the context around erlehmann's quote, then. |
| 16:44 | <Lachy> | I'm not sure what bug that tweet might be referring to, nor whcih browser |
| 16:44 | <Lachy> | https://twitter.com/timpritlove/status/56018111463301120 |
| 16:44 | <Lachy> | that makes more sense |
| 16:45 | <zewt> | autoplaying flag != autoplay attribute, presumably |
| 16:45 | <erlehmann> | TabAtkins, i only found it at the beginning of media.load() in the spec. |
| 16:45 | <Lachy> | zewt, see the other tweet. He meant preload |
| 16:45 | <TabAtkins> | Oh, yeah, that makes much more sense. The answer is obvious, too - preloading is user-friendly, obviously. |
| 16:46 | <erlehmann> | timpritlove is an admitted apple fanboy, so i'd suggest osx/ios safari? |
| 16:46 | <erlehmann> | better ask him. i'm not on the twitter. |
| 16:46 | <erlehmann> | zewt, thx. |
| 16:46 | <erlehmann> | oh, Lachy cleared it up. |
| 16:46 | <erlehmann> | everything is fine :) |
| 16:51 | <Lachy> | TabAtkins, if you file a bug on gecko about that list-item quirk, CC me on it |
| 16:53 | <TabAtkins> | Will do. |
| 16:55 | <Philip`> | "old pages won't use <details>, and new pages shouldn't use quirks mode" |
| 16:55 | <Philip`> | Is there any evidence that new pages won't use quirks mode in roughly the same proportion as old pages? |
| 16:56 | <TabAtkins> | No, but then they're quirky. Shrug. |
| 16:56 | <Philip`> | (where "old" means after the HTML4/XHTML1 doctypes became ubiquitous so people didn't have the excuse of never having heard of a doctype) |
| 16:56 | <TabAtkins> | Wait, yes, possibly - the very fact that the doctype is so much harder to get wrong than before. |
| 16:59 | <nimbupani> | hey everyone I have a question, Opera currently only does constraint validation on elements are used to construct the form data set. |
| 17:00 | <nimbupani> | but gecko and webkit do not do this check to do constraint validation, which would be the correct behaviour? |
| 17:00 | <nimbupani> | http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-disabled on the surface seems to suggest gecko/webkit |
| 17:00 | <smaug____> | volkmar_: ^^^ |
| 17:00 | <nimbupani> | but http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#barred-from-constraint-validation seems to lead to a maze of word puzzles. |
| 17:02 | <TabAtkins> | jgraham: What was the tag you suggested for subheadings? |
| 17:04 | <jgraham> | TabAtkins: <subhead> |
| 17:04 | <jgraham> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11731 |
| 17:07 | <Lachy> | jgraham, is that the one you suggested to nest inside the <h1>? |
| 17:08 | <jgraham> | Lachy: Yes |
| 17:10 | <Lachy> | right. I didn't like that suggestion. It overly complicates the markup, and links the two elements together in unfortunate ways |
| 17:10 | <Lachy> | e.g. for applying backgrounds or borders or whatever to the h1, which aren't intended to apply to the subheading |
| 17:11 | <Lachy> | even for colors, it creates the problem that authors have to explicitly undo the applied styles |
| 17:29 | <TabAtkins> | Damn Dr. Olaf and his trolling! I'll be strong and not respond, but it's *so hard*. |
| 17:30 | <Lachy> | TabAtkins, which list? |
| 17:30 | <TabAtkins> | www-style, on the Lengths thread. |
| 17:38 | <jgraham> | Hmm, so there is a difference between <script></script> and <script> </script> if I append data to the script? |
| 17:38 | <Lachy> | TabAtkins, in which spec does it define the px to be 0.75pt? |
| 17:38 | <TabAtkins> | Values and Units |
| 17:38 | <Lachy> | this one? http://dev.w3.org/csswg/css3-values/ |
| 17:39 | <TabAtkins> | Yes. |
| 17:39 | <Lachy> | does it define it indirectly somehow? it looks like it's still defining it in terms of angular measurement |
| 17:41 | <TabAtkins> | Ah, sorry, V&U hasnt' been properly updated. 2.1 has the right deffinition. |
| 17:41 | <TabAtkins> | http://www.w3.org/TR/CSS21/syndata.html#length-units , scroll down a bit |
| 17:42 | <Lachy> | oh, I see. CSS3 hasn't been updated to match yet |
| 17:42 | <volkmar_> | nimbupani: what do you mean exactly? |
| 17:42 | <volkmar_> | i mean, disabled elemnets shouldn't be validated nor elemnets barred from constrant validation |
| 17:43 | <nimbupani> | volkmar_: http://jsfiddle.net/nimbu/P7Fa8/2/ does validation in gecko and webkit but not on opera. |
| 17:44 | <nimbupani> | mainly coz Opera considers input elements without name attr as not "submittable" element. |
| 17:44 | <nimbupani> | and no form validation is done on elements that are not "submittable" |
| 17:46 | <volkmar_> | oh... |
| 17:46 | <volkmar_> | nimbupani: Opera's behavior might make sense but as far as I know, it's not following the current spces |
| 17:46 | <nimbupani> | volkmar_: internally the view is that it*is* following specs |
| 17:47 | <nimbupani> | because of some convoluted wording in constraint validation docs |
| 17:47 | <volkmar_> | nimbupani: see 4.10.21.2: you should run constraint validation check onall submittable elements |
| 17:48 | <volkmar_> | and submittable doesn't mean that is submit but that has a type that allow submission |
| 17:49 | <nimbupani> | yeah thats what i thought too, but annevk suggested it meant it had to submit. |
| 17:49 | <nimbupani> | but he is now in South America, so probably I can safely pretend he didnt say it. |
| 17:50 | <volkmar_> | nimbupani: gotta run out of wifi |
| 17:50 | <nimbupani> | kay. thanks volkmar_ |
| 18:46 | <Hixie> | heh, Lachy suggested display:transparent |
| 18:52 | <Lachy> | yes, I did. |
| 18:52 | <Lachy> | has that been suggested before? It seemed vaguely familiar when I thought of it, but can't remember anything specific |
| 19:01 | <Hixie> | Lachy: yeah, several times. It's definitely needed. |
| 19:01 | <Hixie> | Lachy: like many things that have been proposed and gone nowhere fast in that wg |
| 19:02 | <zewt> | (transparent to do what?) |
| 19:02 | <othermaciej> | what's the purpose of display:transparent? |
| 19:02 | <othermaciej> | would that act like visibility:hidden? |
| 19:03 | <zewt> | (that was my first thought) |
| 19:04 | <Lachy> | othermaciej, no. It means that there is no layout box generated for the element, and all it's descendants are rendered as though they were descendants of its parent element |
| 19:04 | <Hixie> | 'transparent' may not be the best keyword, dunno what would be better |
| 19:05 | <othermaciej> | I see |
| 19:05 | <othermaciej> | that seems useful, but it definitely did make me think of visual transparency |
| 19:06 | <Lachy> | so, e.g. <div><div style="display: transparent"><p>x</p></div></div> renders exactly the same as would <div><p>x</p></div> |
| 19:06 | <zewt> | so basically, it acts as a grouping mechanism for DOM nodes, without the rendering side-effects? |
| 19:06 | <Lachy> | maybe display: no-box; would be better |
| 19:06 | <Lachy> | zewt, yes |
| 19:07 | <Lachy> | it only affects layout. Other inherited properies, like colours, etc. are inherited. Borders and backgrounds would not apply to the element though |
| 19:08 | <AryehGregor> | What are the use-cases? |
| 19:08 | <Lachy> | AryehGregor, read the mail |
| 19:09 | <AryehGregor> | Which list? |
| 19:09 | <AryehGregor> | Oh, the huge one to whatwg about details? |
| 19:09 | <Lachy> | yeah, that one, or the more recent one on www-style |
| 19:09 | <Lachy> | www-style is shorter |
| 19:10 | <Lachy> | but in the whatwg one, you can skip down to where it says "== Proposed Solutions ==" and find the subsection about hiding and showing content |
| 19:10 | <zewt> | i assume things like :first-child would be unaffected? |
| 19:10 | <zewt> | (that is, do the same as any other display mode) |
| 19:10 | <Lachy> | yes |
| 19:10 | <Lachy> | hmm, perhaps ::first-letter might be affected |
| 19:11 | <Lachy> | in fact, I don't think any pseudo-elements would work on it |
| 19:11 | <Lachy> | I must go though. back later tonight |
| 19:13 | <othermaciej> | display: child-nodes; |
| 19:13 | <othermaciej> | (ok, enough bike shedding) |
| 19:13 | <zewt> | heh |
| 19:14 | <zewt> | well, getting the proposed name right is a shortcut past a lot of what-does-it-do |
| 19:16 | <Lachy> | othermaciej, please bikeshet on the list where it is more appreciated :-) |
| 19:16 | <Lachy> | bikeshed |
| 21:09 | <MikeSmith> | Lachy: I think you just came close to coining a new term |