| 00:12 | <yuhong> | "Authors must not use the lang attribute in the XML namespace on HTML elements in HTML documents. To ease migration to and from XHTML, authors may specify an attribute in no namespace with no prefix and with the literal localname "xml:lang" on HTML elements in HTML documents, but such attributes must only be specified if a lang attribute in no namespace is also specified, and both attributes... |
| 00:12 | <yuhong> | ...must have the same value when compared in an ASCII case-insensitive manner." |
| 00:12 | <yuhong> | Unfortunately, XHTML 1.1 can now be served as text/html and that does not allow lang to be used. |
| 00:12 | <yuhong> | http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/ |
| 00:13 | <AryehGregor> | Huh? XHTML 1.1 allows lang to be used. |
| 00:14 | <AryehGregor> | Oh, 1.1. |
| 00:14 | <AryehGregor> | Who uses 1.1? |
| 00:14 | <AryehGregor> | I doubt HTML5 aims for compatibility with XHTML 1.1. |
| 00:14 | <yuhong> | Nobody so far, but that is partly because before it can't be served as text/html. |
| 00:14 | <AryehGregor> | 1.0, yes, more or less. |
| 00:14 | <yuhong> | Now it can. |
| 00:14 | <yuhong> | Thanks to the second edition. |
| 00:15 | <AryehGregor> | Okay, so is there a problem here? |
| 00:15 | <AryehGregor> | Serve it as XHTML 1.1 and use xml:lang, or as HTML5 and use lang. |
| 00:15 | <AryehGregor> | The XHTML 1.1 doctype isn't allowed by HTML5 either. |
| 00:15 | <AryehGregor> | So you can't serve the same document for both. |
| 00:15 | <AryehGregor> | Not to mention that if you tried that you couldn't use all the new HTML5 features like <canvas> and <video> and so forth. |
| 00:15 | <AryehGregor> | (in which case, why bother with HTML5 at all?) |
| 00:17 | <AryehGregor> | Would you like the spec to say "To ease migration to and from XHTML 1.0, . . ." instead? |
| 00:28 | <MikeSmith> | that Wikipedia article is indeed suspicious |
| 00:28 | <MikeSmith> | from the title, you'd expect there to be something about hash in there |
| 00:29 | <MikeSmith> | but you read it and instead it's all about mathematical formulas or some damn thing |
| 00:30 | <MikeSmith> | this article about this subject is much more straightforward: |
| 00:30 | <MikeSmith> | http://en.wikipedia.org/wiki/Hashish |
| 00:30 | <MikeSmith> | it gets to the point right away |
| 00:31 | <nimbupani> | i had a print of a 1973 poster from a katmandu shop |
| 00:31 | <nimbupani> | with a goddess who has a marijuana in her hand |
| 00:31 | <nimbupani> | and the slogan |
| 00:32 | <nimbupani> | "We Take You Higher" |
| 00:32 | <nimbupani> | a marijuana leaf* |
| 00:33 | <MikeSmith> | heh |
| 00:36 | <paul_irish> | relatedly: thx to MikeSmith i got a tshirt that says. "HTML. So High! Too much love." |
| 00:36 | <MikeSmith> | yeah, there's lots more where that one came from |
| 00:37 | <nimbupani> | too bad they dont do CSS |
| 00:37 | <nimbupani> | or SVG |
| 00:37 | <nimbupani> | i bet W3C will get lots of money if they start creating such t-shirts :D |
| 00:37 | <paul_irish> | fundraiser whaat! |
| 00:37 | <cardona507> | i need an html so high! shirt |
| 00:37 | <paul_irish> | boom. |
| 00:37 | <cardona507> | we need a screenshot of sir tim wearing one of those shirts |
| 00:37 | <cardona507> | that would be hot |
| 00:38 | <nimbupani> | i think we have a biz plan right here MikeSmith |
| 00:39 | <MikeSmith> | yeah, we need to execute on this |
| 00:39 | <MikeSmith> | it's interesting that the words HTML and THC both have the letter H in them… there's no way that could just be a simple coincidence |
| 00:39 | <MikeSmith> | I think we should rename XBL2 to THC |
| 00:46 | <MikeSmith> | JonathanNeal: did you get any feedback yet on that bug you filed? |
| 00:46 | <JonathanNeal> | none that I know of, let's check. |
| 00:47 | <MikeSmith> | what's the bug number? |
| 00:49 | <JonathanNeal> | https://bugs.webkit.org/show_bug.cgi?id=50006 |
| 00:49 | <JonathanNeal> | UNCONFIRMED |
| 00:52 | <MikeSmith> | ah, it's cool you added the red |
| 00:52 | <MikeSmith> | in the test page |
| 00:52 | <MikeSmith> | makes it a lot easier to see |
| 00:57 | <JonathanNeal> | Yea, that was based on your initial reaction. |
| 00:58 | <JonathanNeal> | When I have free time I'd be interested in seeing how Firefox handles the spread, like, where it distributes the leftover pixels. |
| 01:01 | <JonathanNeal> | okay, time to bring pie to the gf's fam and then home for more coding. see you guys a little later (if you're on) |
| 01:01 | <MikeSmith> | cheers |
| 01:54 | <yuhong> | Sorry, I found out later actually XHTML 1.1 second edition did add the lang attribute, so there is no incompatibility anyway. |
| 01:54 | <yuhong> | Look at the beginning of http://www.w3.org/TR/xhtml11/. |
| 03:59 | <MikeSmith> | in C++ program, if I have an int, is there any way I can determine how many digits there in it? |
| 04:30 | <heycam> | MikeSmith, without repeatedly dividing by 10? |
| 04:31 | <MikeSmith> | heycam: yeah, preferably |
| 04:32 | <MikeSmith> | but I have since realized it's not going to help me to know it anyway |
| 04:32 | <heycam> | aha i knew there would be a bit twiddling hack for it |
| 04:32 | <heycam> | http://graphics.stanford.edu/~seander/bithacks.html#IntegerLog10 |
| 04:33 | MikeSmith | looks |
| 04:33 | <MikeSmith> | wow |
| 04:34 | <heycam> | that page is full of awesome |
| 04:34 | <MikeSmith> | see, I knew there was some obvious way to do it :) |
| 04:34 | <MikeSmith> | yeah |
| 04:34 | <heycam> | heh |
| 04:34 | <MikeSmith> | that page is indeed great |
| 04:35 | <MikeSmith> | my C++ programming skills are the complete opposite of awesome |
| 04:35 | <MikeSmith> | but I did just manage to find and fix another bug in the V8 date-parsing code |
| 04:35 | <MikeSmith> | despite my caveman-level programming chops |
| 04:36 | <MikeSmith> | and no thanks to gdb |
| 04:36 | <heycam> | maybe you can pick up a monetary reward for that |
| 04:37 | <MikeSmith> | I would be happy with a new skateboard |
| 04:38 | <MikeSmith> | or a new deck at least |
| 04:41 | <MikeSmith> | anyway, I have decided that debuggers are overkill |
| 04:41 | <MikeSmith> | printf and the like are the best debugging tool ever |
| 04:42 | <heycam> | totally |
| 04:42 | MikeSmith | is listening to "Cadaverous / Ultraviolent Junglist" by Venetian Snares on WFMU on HotRod's show from WFMU - Freeform Radio the Way it Oughta Be (✮✮✮✮✮) |
| 04:46 | <MikeSmith> | I'm also convinced that listening to breakcore helps me thinks better |
| 04:46 | <MikeSmith> | or faster at least |
| 06:57 | <MikeSmith> | kennyluck: http://blog.jclark.com/2010/11/xml-vs-web_24.html |
| 10:04 | <zcorpan> | xhtml2 wg is still alive... http://www.w3.org/News/2010.html#entry-8962 |
| 10:07 | <jgraham> | I like how the top item on their homepage is "XHTML 2 Working Group Expected to Stop Work End of 2009". No one expects the… well you see where I am going. Maybe it's not that surprising, since Steven Pemberton was involved with ABC which was the precursor to Python |
| 10:52 | <jgraham> | david_carlisle: I think the answer to your question about testsuites is something like "use common sense", i.e. if you make a test that is known to fail in some UA for a reason unrelated to what it purports to test, that is probably bad |
| 10:53 | <jgraham> | and the less interoperable the features you use in your test, the more likely that is to happen |
| 10:53 | jgraham | should write something like that to the list |
| 10:54 | <annevk> | david_carlisle, if that innerHTML issue gets resolved I suspect it will be out of scope for the HTML WG test suite |
| 10:54 | <annevk> | david_carlisle, we could still add it I suppose, but HTML5 would not place the requirements |
| 11:02 | <david_carlisle> | jgraham: but I haven't any javascript common sense (no natural feel for the language). Now if the test suite was in xslt it would be so much easier... |
| 11:09 | <jgraham> | Yeah, because you would be the only contributer :p |
| 11:11 | <david_carlisle> | annevk: if it's out of scope to test for innerHTML on math, then why $ grep innerHTML approved/foreigncontent/foreign_content_009.html |
| 11:11 | <david_carlisle> | for example |
| 11:14 | <david_carlisle> | jgraham: on interoperability, I checked the thing worked as expected in webkit/opera/ff/ie is that "interoperable enough" in practice. there are mathml systems that don't do javascript at all, which would no doubt have serious problems with the test harness, so it wasn't clear to me what was likely to be acceptable. |
| 11:16 | <annevk> | david_carlisle, is that testing innerHTML on an HTML or MathML element? |
| 11:16 | <jgraham> | Neither, it is using innerHTML to set the results, afaict |
| 11:24 | <david_carlisle> | annevk: its on svg not mathml, but whatever its testing if innerHTML didn't work on svg the test would fall over |
| 11:25 | <david_carlisle> | sorry, i need to move wifi only stays up for a minute at a time here |
| 11:25 | <jgraham> | david_carlisle: It only uses .innerHTML on a HTMLElement afaict |
| 11:27 | <david_carlisle> | does it, oops must look harder next time:-0 |
| 11:38 | <david_carlisle> | annevk: i still don't really see why it's out of scope for html5, .innerHTML works on math in html in pre-html5 parsers eg opera. It's just the html5 spec as currently written that says it shouldn't work. |
| 11:42 | <jgraham> | david_carlisle: Surely it is in scope for the Math WG to put whatever they like on the interface implemented by MathML elements. But I guess annevk means it will become part of Web DOM Core |
| 11:42 | <jgraham> | No reason not to test it in HTML5 testsuite if it does |
| 11:43 | <jgraham> | But not strictly in scope |
| 11:44 | <annevk> | david_carlisle, HTML5 can say what happens on HTML elements, not what happens on non-HTML elements |
| 11:45 | <annevk> | david_carlisle, that is how we have scoped it from the beginning anyway |
| 11:45 | <annevk> | david_carlisle, and the current proposal for generalizing innerHTML is outside HTML5 |
| 11:46 | <annevk> | david_carlisle, it is this specification: http://html5.org/specs/dom-parsing.html |
| 11:47 | <david_carlisle> | jgraham: but basically the browser manufacturers told us they didn't want a mathml specific dom as it was work for not much gain (and it was hard to disagree) so we currently don't have anywhere to specify a mathml specific interface, we assumed that in a browser context it would just do the right thing using a generaic interface (ie one more like HTMLElement than Element) |
| 11:47 | <david_carlisle> | annevk: it is the html5 spec that has said what to do with math, if it haddnt said that it would be unknown html element and these methods would be available |
| 11:47 | <david_carlisle> | as they are in FF3 or opera, or IE9 |
| 11:49 | <jgraham> | david_carlisle: It seems like it should be rather easy to say that all elements in MathML implement HTMLElement rather than Element |
| 11:49 | <david_carlisle> | yes please! |
| 11:50 | <david_carlisle> | curently as far as dom scripting support goes mathml elemnts get less functionality than <wibble-foo-bar> which can't be right |
| 11:52 | <jgraham> | david_carlisle: Well, strictly speaking it is for the Math WG to say, not HTML. But I suggest sending an email to public-html |
| 11:54 | <david_carlisle> | jgraham; As I say we have essentially retired the mathml dom spec (chapter 8 of mathml2 has no equiv in mathml3) but if necessary we would see if we could get ourself chartered to make a new rec trac document that said the one line MathMLElement inherits from HTMLElement in a DOM that supports HTMLElement |
| 11:55 | <annevk> | david_carlisle, HTML5 cannot say what interface elements in a non-HTML namespace implement |
| 11:56 | <jgraham> | annevk: Presumably HTML can say anything that we can get along the Rec. track |
| 11:57 | <annevk> | jgraham, I guess, but I would not agree to this approach |
| 11:58 | <jgraham> | What, saying that MathMLElement inherits HTMLElement? |
| 11:58 | <jgraham> | Or saying that without rechartering the MathML WG? |
| 11:58 | <jgraham> | That is, is your issue technical or procedural? |
| 11:58 | <annevk> | either |
| 11:58 | <annevk> | I think innerHTML should move to Element |
| 12:00 | <jgraham> | annevk: It seems like there is a lot of other stuff on HTMLElement that I would want on all elements in a text/html document |
| 12:01 | <david_carlisle> | jgraham: yes innerHTML is just one aspect that happened to bite first. |
| 12:01 | <annevk> | and not in a text/xml document? |
| 12:01 | <annevk> | and not for SVG elements? |
| 12:01 | <jgraham> | I don't care about XML documents |
| 12:01 | <jgraham> | Also for SVG, yes |
| 12:02 | <jgraham> | But that is more complex as SVG has a non-trivial DOM of its own |
| 12:02 | <annevk> | well, DOM consistency is important |
| 12:02 | <david_carlisle> | annevk: In doms that support HTMLElement, in a pure XML world thinsg are different but mathml in html should behave like an html element and mathml in xhtml should behave like an xhtml one |
| 12:03 | <annevk> | I'm not sure what you mean with a pure XML world. From a browser's perspective there's hardly any difference. |
| 12:03 | <annevk> | And there's also hardly any difference between HTML and XHTML. |
| 12:03 | <david_carlisle> | annevk: I mean if you are not in a browser |
| 12:04 | <annevk> | Even then the same considerations would apply I hope... |
| 12:05 | <david_carlisle> | annevk: sorry you lost me. i just want someone to say that if a DOM implements HTMLElement then MathML elements should inherit from that, and if the DOM doesn't implement HTMLElement then they inherit from Element |
| 12:06 | <jgraham> | That sounds… odd |
| 12:06 | <annevk> | yeah... |
| 12:06 | <jgraham> | (I think you just want to inherit from HTMLElement, always) |
| 12:07 | <slartsa> | aaaagh the firefly song is going through my head again! |
| 12:07 | <FireFly> | ._. |
| 12:07 | jgraham | repeats himself |
| 12:07 | <Philip`> | Just make Element inherit from HTMLElement |
| 12:07 | <jgraham> | (I think you just want to inherit from HTMLElement, always) |
| 12:08 | <david_carlisle> | jgraham: it's consistent with the way xhtml works in practice. If you use a browser DOM it has HTML specific support, but if you just treat it as generic XML in an XML DOM then it's Element, isn't it? |
| 12:13 | <david_carlisle> | jgraham: "I think you just want to inherit from HTMLElement, always", I want that if HTMLElement is defined, but I don't want to say you can't use MathML without implementing HTML, The exact best way to say that in terms of dom inheritance I'd be happy to leave to someone who knows what they are talking about, |
| 12:15 | <hsivonen> | jgraham: I believe the sane invariants should be that a node implements HTMLElement if and only if its namespace is the HTML namespace (and analogously for SVG) |
| 12:16 | <hsivonen> | there's something weird in Gecko that makes this not always hold for SVG |
| 12:16 | <hsivonen> | might be some SVG spec badness that got implemented carefully |
| 12:16 | <annevk> | SVG said only known SVG elements implement SVGElement |
| 12:17 | <david_carlisle> | hsvionen: Is there a way (in IDL) to say MathMLElement is same as HTMLElement without saying it inherits from it, or are yiu saying we need to textually copy th espec of HTMLElement and then do s/HTML/MathML/g |
| 12:18 | <david_carlisle> | hsivonen: because if we really have to do the latter we'd do it |
| 12:19 | <hsivonen> | david_carlisle: I don't know, but I expect that IDL does not have such a feature |
| 12:19 | <hsivonen> | annevk: can we change the SVG spec say that all elements in the SVG namespace implement SVGElement? |
| 12:20 | <david_carlisle> | hsivonen: and is inheriting from HTMLElement really bad? |
| 12:21 | <annevk> | hsivonen, yeah, I think that is the plan anyway |
| 12:21 | <annevk> | david_carlisle, it makes no sense? |
| 12:22 | <david_carlisle> | annevk: what makes no sense? |
| 12:22 | <annevk> | to have Math elements inherit from HTML elements |
| 12:23 | <david_carlisle> | annevk: why in 50 years time should anyone care that in an html/svg/mathml document that different elements got defined in different bits of the w3c? |
| 12:24 | <hsivonen> | david_carlisle: in Gecko, it's nice to know that if a node is in one of the main namespaces, it can be unconditionally cast into certain interfaces/classes |
| 12:24 | <david_carlisle> | annevk: a math fragment is just a natural part of the sentence structure, all interaction and scripting should just work naturally across the tree |
| 12:25 | <hsivonen> | david_carlisle: I'm not sure of the implications of MathML elements inheriting from HTMLElement |
| 12:25 | <david_carlisle> | hsivonen: yes exactly i want th einterfaces that you'd give to unknown html elemnts, not just get dropped on the floor with no support |
| 12:26 | <hsivonen> | david_carlisle: Boris Zbarsky is likely to have a better idea of the consequences of such a change |
| 12:27 | <david_carlisle> | maybe the discussion should be in bugzilla rather than here, but it's been fun chatting, got some xslt to attend to in the day job, better go (or at least stop watching) |
| 12:31 | <annevk> | david_carlisle, that is a good question -- I do not think that necessarily leads to what you think is the obvious answer though |
| 12:53 | <kling> | reni: ping |
| 12:53 | <reni> | kling: and here |
| 13:39 | <openstandards> | Hi there, has anyone suggest a widget for developers to use that just selects a folder instead of a file |
| 13:44 | <karlcow> | Why You Guys Taking So Much Time for HTML5.... -- http://www.w3.org/Bugs/Public/show_bug.cgi?id=11405 |
| 13:44 | <karlcow> | that was useful… |
| 13:45 | <openstandards> | :( |
| 13:45 | <karlcow> | I'm tempted to reply to the guy "because you haven't pedal fast enough" |
| 13:46 | <karlcow> | openstandards: what is the question? |
| 13:46 | <openstandards> | you should do, thats annoying... people will moan if theres problems with the spec if things aren't done properly |
| 13:47 | <karlcow> | I do not parse the " a widget for developers to use that just selects a folder instead of a file" |
| 13:47 | <openstandards> | karlcow, has anything been purposed for selecting a download folder I know theres input=file but then the user will have to select a file for the widget to close |
| 13:47 | <karlcow> | for FileAPI you mean? |
| 13:48 | <annevk> | there's no such thing |
| 13:48 | <openstandards> | damn thats annoying :( |
| 13:48 | <annevk> | <input type=file multiple> is what is closest |
| 13:49 | <openstandards> | has this issue been mentioned before? |
| 13:50 | <Rik`> | webkit has an implementation of a dir selection, can't remember the attribute |
| 13:51 | <annevk> | openstandards, yes |
| 13:52 | <annevk> | openstandards, some consider it a UI issue |
| 13:54 | <hsivonen> | Hixie: I started implementing the approach that puts the insertion mode onto the stack |
| 13:54 | <openstandards> | I do thats partly why i asked i looked into the input types but didn't see anything, I saw someone mentioned input="directory" for uploads but wasn't sure if this talks has been carried on |
| 13:54 | <hsivonen> | Hixie: then I figured it was too much trouble and reverted |
| 13:55 | <hsivonen> | Hixie: however, I implemented the idea of getting rid of the "in foreign content" insertion mode and instead checking the namespace of the current element |
| 13:55 | <hsivonen> | Hixie: I'm pleased with the result |
| 14:22 | <hsivonen> | jgraham: I don't understand why some of your frameset-ok tests are in plain-text-unsafe.dat |
| 14:25 | <jgraham> | I think some of them might have been me noticing the open buffer had <frameset> tests, but not noticing that it was plaintext-unsafe |
| 14:25 | <hsivonen> | jgraham: I see |
| 14:26 | <hsivonen> | jgraham: btw, you had also removed LF from the end of file in both plain-text-unsafe files |
| 14:26 | <hsivonen> | I put them back in a hex editor and will push to hg |
| 14:26 | <jgraham> | Thanks |
| 14:27 | <hsivonen> | I guess html5lib's test harness is less picky about LF at end of file |
| 14:28 | <hsivonen> | I wonder if U+FFFD for U+0000 is a safe substitution in text/plain |
| 14:29 | <hsivonen> | for reasons I fail to recall, I've made Gecko throw away U+0000 in <plaintext> |
| 14:29 | <hsivonen> | and now the test cases want U+FFFD there |
| 14:30 | <jgraham> | The spec specifically requires that and it also required a change in html5lib |
| 14:30 | <jgraham> | Kinsd of silly really |
| 14:31 | <hsivonen> | Chrome 9 sniffs http://hsivonen.iki.fi/test/moz/null-crlf.txt as a file that gets downloaded instead of viewed as plain text |
| 14:35 | <jgraham> | hsivonen: The html5lib harness gets upset if there are >1 newlines at the end of a file |
| 14:36 | <jgraham> | But it is fine with 0 or 1 |
| 14:37 | <hsivonen> | jgraham: my harness wants 1 newline at the end of file |
| 14:37 | <jgraham> | hsivonen: I will try to make sure that happens |
| 14:38 | <hsivonen> | jgraham: thanks |
| 14:39 | <hsivonen> | Firefox 3.6 and Opera don't throw away U+0000 in text/plain, so I guess I'm OK with what the new spec text / test cases |
| 14:42 | <hsivonen> | so why doesn't the 'plaintext' start tag token put the tree builder into the 'text' insertion mode? |
| 14:47 | <jgraham> | What difference would it make? |
| 14:47 | <hsivonen> | dunno |
| 14:48 | <hsivonen> | no difference that the test suite could catch provided that original mode is set also |
| 14:49 | <jgraham> | Why would it matter if the original mode is set? You could only end up in the "a character token" branch |
| 14:49 | <jgraham> | Oh, wait I think it would make a difference |
| 14:50 | <jgraham> | It wouldn't e.g. reconstruct active formatting elements |
| 14:50 | <hsivonen> | in what situation? |
| 14:51 | <jgraham> | <p><a><b><plaintext>c |
| 14:52 | <hsivonen> | jgraham: that's an evil test that needs to be in the test suite! |
| 14:52 | <hsivonen> | do we really want to reconstruct the active formatting elements in that case? |
| 14:53 | <jgraham> | hsivonen: Yeah. Although in all honestly zcorpan gets the credit for it |
| 14:53 | <jgraham> | I have no opinion what we do here because I think eorrying about interoperability of <plaintext> is rather silly |
| 14:54 | <jgraham> | Well interoperability is nice |
| 14:54 | <jgraham> | but worrying about the exact behaviour is quite silly |
| 14:54 | <hsivonen> | well, if it ends up in the test suite, everyone needs to worry about it |
| 14:55 | <jgraham> | Right. I think we should be interoperable. I am entirely unconcerned with what behaviour we interoperate on |
| 14:55 | <jgraham> | s/on/with/ |
| 14:55 | <jgraham> | e.g. I don't care if we reconstruct or not |
| 14:56 | <hsivonen> | the old WebKit behavior differs from the spec, FWIW |
| 14:56 | <jgraham> | Seeming that Chrome and Firefox 4 already reconstruct it implies that changing now would be a bad idea |
| 14:58 | <hsivonen> | jgraham: well, not necessarily, since it looks like I'm going to change code around this area in the next few minutes anyhow |
| 14:59 | <jgraham> | hsivonen: So I should land that test now? :p |
| 14:59 | <hsivonen> | jgraham: I haven't yet decided what I want |
| 14:59 | <hsivonen> | I'm a bit annoyed at having to think about this |
| 14:59 | <hsivonen> | IE9 agrees with old WebKit, FWIW |
| 15:01 | <jgraham> | I think that it is a silly change but an entirely harmless one. I wonder if we could just have dropped <plaintext> |
| 15:02 | <hsivonen> | jgraham: I guess it's OK to land the test in any case |
| 15:03 | <hsivonen> | even if the test expectation ends up changing later |
| 15:03 | <hsivonen> | maybe I should just implement what the spec says to avoid the spec change process |
| 15:03 | <hsivonen> | though I think it would make more sense to use the 'text' mode inside <plaintext> and to make <plaintext> not close p implicitly |
| 15:03 | <Philip`> | jgraham: It's only been deprecated for 17 years, you can't drop it yet |
| 15:04 | <hsivonen> | Philip`: s/deprecated/obsolete/ |
| 15:04 | <Philip`> | jgraham: and it fulfils important use cases, like emulating HTML5 parsing behaviour in old browsers |
| 15:05 | <hsivonen> | ha! <plaintext> doesn't close <p> in any legacy browser. It's a new Hixie-ism. |
| 15:06 | <hsivonen> | spec bug filing time |
| 15:07 | <annevk> | does in Safari? |
| 15:08 | <hsivonen> | annevk: nope |
| 15:08 | <annevk> | oh, Safari 5.0.3 has an updated parser then? |
| 15:10 | <hsivonen> | hmm. |
| 15:10 | hsivonen | rechecks |
| 15:11 | <hsivonen> | annevk: oh, you are right |
| 15:12 | jgraham | has pushed the test for the current spec |
| 15:13 | jgraham | wonders if Hixie is away |
| 15:17 | <hsivonen> | oh well, I guess I'll just implement the spec |
| 15:21 | <hsivonen> | this resulted in one more special-case method :-( |
| 15:23 | <hsivonen> | I think it's somehow distasteful that <plaintext> can get element children inserted by the parser |
| 15:25 | <zcorpan> | should we special-case <plaintext> so that it doesn't reconstruct? |
| 15:27 | <zcorpan> | <p><b><xmp>x\0 |
| 15:27 | <zcorpan> | is that also an issue? |
| 15:28 | <hsivonen> | zcorpan: we could make <plaintext> not implicitly close <p> and then use the 'text' insertion mode |
| 15:28 | <hsivonen> | that would match IE8, Opera and Firefox 3.6 |
| 15:28 | <hsivonen> | clearly, IE9 has very carefully cloned old WebKit here |
| 15:28 | <hsivonen> | I wonder what possessed them to clone old WebKit instead of implementing the spec |
| 15:33 | <jgraham> | Maybe they think that you can be sure to get web compatibility from cloning web-compatible implementations and that people who write specs are by-and-large idealistic hippies who can't be relied on to do the right thing |
| 15:36 | <hsivonen> | zcorpan: looks like xmp in the spec behaves like plaintext in Safari... |
| 15:36 | <hsivonen> | consistency? what consistency? |
| 15:40 | <zcorpan> | jgraham: not entirely unreasonable :) |
| 16:32 | <webr3> | what HTMLElement can I use to embed content of a different type in the document.. something like |
| 16:32 | <webr3> | <embed type="text/something"> content-inline-here </embed> |
| 16:36 | <Philip`> | webr3: <script> |
| 16:37 | <Philip`> | webr3: See e.g. the <script type="text/x-game-map"> in http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html |
| 16:39 | <webr3> | yeah that's what I am using, but I want the script to be human viewable too, on the page |
| 16:41 | <Philip`> | If it should be visible as plain text, maybe just use <pre>? |
| 16:47 | <webr3> | aye, basically can see a use case where it's both, for instance with examples |
| 16:47 | <webr3> | <script type="text/custom" showaspre="true"> for example </script> |
| 16:48 | <webr3> | like script+pre merged |
| 16:50 | <Philip`> | <script style="display:block; white-space:pre"> should do that |
| 16:50 | <Philip`> | though it's probably not great semantically |
| 16:51 | <Philip`> | A simple <pre> seems more appropriate when you want to display text, and you can have scripts that extract the textContent and process it if you want |
| 16:51 | <webr3> | yes that's it! awesome |
| 16:53 | <webr3> | you can wrap a script in pre! |
| 16:53 | <webr3> | <pre><script ... etc - awesome |
| 16:58 | <annevk> | o_O |
| 17:06 | <webr3> | http://webr3.org/apps/play/embeds/javascript |
| 17:06 | <webr3> | and now i can embed RDF and make it human viewable too, nice http://webr3.org/apps/play/embeds/turtle |
| 17:06 | <webr3> | Philip`, ty :) |
| 17:09 | <Philip`> | Putting it in <script> will probably stop search engines from indexing it, which may not be what you want |
| 17:10 | <webr3> | indeed, but I'm fine w/ that and linked data crawlers can start to use it - have always got RDFa as well which is deployed and stable, this is for a different use case |
| 17:11 | <jgraham> | <plaintext>! |
| 17:11 | <Philip`> | <xmp>! |
| 17:13 | <webr3> | meh script does what i need, no stupid encoding, backwards comaptible expected functionality, and can make normal js libs to "do things" w/ the data - I'm quite happy as is |
| 17:14 | <webr3> | just drop in a css rule to toggle displaying it, why would i want or need or need any more? |
| 17:15 | <webr3> | and it's got the content @type and @charset encoding which I need too.. |
| 17:20 | <annevk> | charset is illegal for inline data |
| 17:26 | <webr3> | charset isn't on script..? |
| 17:27 | <webr3> | or you can't displauy:block a <script>? |
| 18:42 | <annevk> | no tab? |
| 18:42 | <annevk> | fwiw, Opera devs agreed with Philip` and remarked that we support rgba() in SVG |
| 18:42 | <annevk> | re gradient thread |
| 18:43 | <Philip`> | Will someone post to that thread? |
| 18:44 | <annevk> | timj is busy with other things and the other relevant people are not on the WHATWG list |
| 18:44 | <annevk> | as I understand it |
| 18:44 | <annevk> | I thought of posting, but I wasn't sure whether it would be worth it just noting that |
| 18:47 | <Philip`> | Might be worthwhile since otherwise people may assume there's consensus among the browser developers |
| 18:53 | <annevk> | done |
| 18:59 | <Philip`> | Thanks |
| 19:30 | <webr3> | what's the easiest way to get at the original DOM, pre-javascript-manipulation? |
| 19:31 | <webr3> | for instance if one has an extension which reads microformats/rdfa out of the dom, and a js manipulates the dom first, then this could cause significant problems |
| 19:47 | <hober> | webr3: what sorts of problems? |
| 20:32 | <webr3> | hober, well malicous scripts can manipulate the dom to add new data and "say" things that are incorrect |
| 20:33 | <webr3> | like.. <a href="http://spammy-company.com"; rel="tag" |
| 20:33 | <webr3> | and a parser running over the DOM will pull that info out and "believe" it, even though bad.js injected it in to the DOM |
| 20:39 | <Philip`> | The web security model is that scripts that run on a page are as trusted as the page itself (because the page chose to run them) |
| 20:40 | <Philip`> | so the raw HTML read over the wire before any JS execution is no more trustworthy than what you'll get after running its scripts |
| 20:42 | <Philip`> | Parsing and script execution are entangled anyway, because of document.write - neither can happen entirely before the other |
| 20:51 | <webr3> | good points Philip` - however to some degree I'd suggest that the HTML source document sent over the wire is "purer" and more trustworthy in some senses, because there's much less room for manipulation by scripts, trusted, untrusted or simply hijacked |
| 21:23 | <jgraham> | webr3: wget? |
| 21:23 | <jgraham> | I mean there isn't any way in a typical browser |
| 21:23 | <jgraham> | Although sometimes it is preserved for view-source |
| 21:50 | <karlcow> | webr3: another issue is that… servers send different content depending on the user agents or features. |
| 21:50 | <karlcow> | so for example when you play with let say, curl -A "here your favorite useragent string" URI |
| 21:51 | <karlcow> | you get different results. |
| 21:54 | <webr3> | I wonder if there should be a way to get doc/dom prior to any manipulation |