| 00:28 | <fantasai> | hsivonen? |
| 00:29 | <hsivonen> | fantasai? |
| 00:29 | <fantasai> | I'm going through your responses to my comments |
| 00:30 | <fantasai> | I still have some questions |
| 00:30 | <fantasai> | I'll send it to you in a few minutes |
| 00:31 | <hsivonen> | ok. |
| 00:45 | <hsivonen> | fantasai: reading your mail now. it is 02:49 in my timezone and I have a lunch meeting at noon, so my judgment may be bad and hasty |
| 00:45 | <fantasai> | k |
| 01:05 | <hsivonen> | fixes as per the first email should be live now. |
| 01:05 | <hsivonen> | I really have to go to bed now, so I'll reply to the rest later |
| 01:06 | <hsivonen> | thanks |
| 01:06 | <hsivonen> | nn |
| 01:09 | <fantasai> | g'night |
| 02:10 | Philip` | wonders if it's a known issue that '<span style="color:red"> One <p> Two </span> Three' parsed by html5lib can't match the mostly-interoperable rendering of IE6/FF2/O9 |
| 02:11 | <Philip`> | (because it creates a "Two Three" text node, whereas the browsers all do Two in red and Three in black) |
| 02:12 | <Hixie> | try it with <em> |
| 02:12 | <Hixie> | is it still different? |
| 02:12 | <Hixie> | if yes, then that's because we specifically avoided <span> because Safari said we didn't have to do it for <span> |
| 02:12 | <Hixie> | s/Safari/experience based on Safari's implementation/ |
| 02:12 | <Philip`> | html5lib parses that correctly (i.e. splitting into two <em>s) |
| 02:13 | <Hixie> | yeah |
| 02:13 | <Hixie> | in that case it's intentional |
| 02:13 | <Hixie> | we want to keep the number of "magic" elements to a minimum |
| 02:13 | <Philip`> | (span appears to be not mentioned in the parsing algorithm, so it's the same as any unrecognised element) |
| 02:13 | <Hixie> | yup |
| 02:13 | <Philip`> | Ah, okay then |
| 06:20 | <met_> | Someone doesn't undestand joke http://blog.whatwg.org/html6-plan#comment-3728 |
| 07:33 | <annevk> | Hixie, I was referring to his comments on the WHATWG |
| 07:34 | annevk | will try to write less one-liners |
| 12:52 | <hsivonen> | Hixie: it might be a practical move to give the <font> issue priority in your feedback queue |
| 12:53 | <annevk> | has there been new evidence? |
| 12:53 | <annevk> | apart from the fact that style= is prolly to be made conforming |
| 12:54 | <hsivonen> | annevk: I, for one, have weeks ago presented a technical (backwards compat) argument why <font> with a transparent content model is bad |
| 12:55 | <hsivonen> | annevk: and we all know that UAs will have to support style='' on every element anyway |
| 12:55 | <annevk> | oh, allowing <font> everywhere? |
| 12:55 | <annevk> | yeah, i wasn't talking about UAs |
| 12:56 | <hsivonen> | annevk: as for the popularity point of view, so far it looks like no one (except for Hixie and perhaps you) likes the way <font> is specced |
| 12:57 | <annevk> | i think some people want <font> in there at all |
| 12:57 | <hsivonen> | annevk: the current speccing is inferior compared to allowing style='' on every element for the compat/practical point of view and the current way of speccing is additionally massively unpopular |
| 12:58 | <annevk> | do you want the content model of <font> to change or simply making it non-conforming? |
| 12:58 | annevk | doesn't really care about <font> atm |
| 12:58 | <hsivonen> | annevk: moreover, repurposing <font> is a bad political move, because the new element doesn't behave like the old <font> but gets the negative reputation of the old <font> |
| 12:59 | <hsivonen> | annevk: I want to: |
| 12:59 | <hsivonen> | 1) Allow style='' on every element |
| 12:59 | <hsivonen> | 2) either |
| 12:59 | <hsivonen> | a) remove <font> |
| 12:59 | <hsivonen> | or |
| 12:59 | <hsivonen> | b) allow font as a strictly inline element that has the attribute color |
| 13:00 | <hsivonen> | I expect accessibility folk to shoot down b) |
| 13:00 | <hsivonen> | but 1) is my main point |
| 13:00 | <annevk> | that has not much to do with <font> then, i think :) |
| 13:01 | <hsivonen> | annevk: it has everything to do with how Hixie has specced <font> |
| 13:16 | <annevk> | fair enough |
| 13:17 | <annevk> | although I doubt people have read that |
| 13:41 | <annevk> | even entities can have public and external identifiers |
| 13:53 | <annevk> | XML is crazy |
| 13:54 | <annevk> | I especially like that entity declarations can contain XML subtrees and the like and therefore references to other entities |
| 13:54 | <annevk> | so you have to address looping of those entity references in some way |
| 13:55 | annevk | wonders if there's a blue pill somewhere |
| 14:05 | <Lachy_> | http://lists.w3.org/Archives/Public/public-html/2007May/0305.html - was that supposed to be a joke or something? I know what Groundhog day is, but I don't see the relevance. |
| 14:07 | <annevk> | i didn't understand it |
| 14:07 | <annevk> | also not after looking up Groundhog |
| 14:07 | <annevk> | I've sort of given up, I think |
| 14:07 | <Dashiva> | I think it maybe possibly might be another way of saying "Didn't you say that before, again and again and again?" |
| 14:07 | <annevk> | I'll be waiting until the chairs make some noise |
| 14:07 | <Dashiva> | But that's pure guesswork, not founded in reality |
| 14:07 | <annevk> | Which is unlikely to be soon given that DanC is going away Sunday or so |
| 14:08 | <annevk> | Dashiva, that sounds about right |
| 14:09 | annevk | repeated it lots of time in different ways hoping they'd just get it at some point |
| 14:09 | <annevk> | how naive |
| 14:09 | <Dashiva> | Don't worry, we'll be doing this for another 10 years, just lean back and enjoy the ride |
| 14:11 | <annevk> | i'm sort of hoping to get something done too |
| 14:12 | <annevk> | and i've the feeling that goal isn't shared |
| 14:12 | <annevk> | or maybe people don't understand the amount of work involved |
| 14:31 | <Lachy_> | heh, the guy in this video reminds me of the attitudes of some people on public-html (though he's slightly more extreme) :-) - http://www.youtube.com/watch?v=qYgZYkTYUaQ |
| 14:49 | <Lachy_> | this would be an awesome colour scheme for acid 3 http://img172.imageshack.us/img172/9812/colorsgq0.png :-) |
| 14:50 | <wilhelm> | (c: |
| 14:56 | <Lachy_> | here's one with the actual hex codes http://www.hd-dvd-tee.com/images/bubble.png |
| 14:57 | <zcorpan_> | there can't be any red when it passes :) |
| 14:58 | <Lachy_> | there already is in the current colour scheme |
| 14:58 | <Lachy_> | http://www.hixie.ch/tests/evil/acid/003/reference.html |
| 14:58 | <zcorpan_> | indeed, i think that's not so good |
| 14:59 | <zcorpan_> | test case with red == fail to me |
| 15:00 | <Lachy_> | zcorpan_, acid tests aren't traditional test cases, they're marketing material |
| 15:00 | <zcorpan_> | so? |
| 15:00 | <zcorpan_> | it will contain more red when it fails, no? |
| 15:00 | <Lachy_> | They have to look cool to the average author, not just be all green and say PASS, or whatever |
| 15:01 | <Lachy_> | doesn't look like it |
| 15:01 | <Philip`> | Maybe people would analogise with litmus paper and think red = acid therefore the acid test succeeded |
| 15:01 | <annevk> | would be awesome to have an Acid test that does just that :) |
| 15:01 | <zcorpan_> | i didn't suggest being all green, just don't contain red when it passes |
| 15:02 | <Lachy_> | I just don't see what problem you are trying to solve by elimiating red from the acid 3 test case. |
| 15:02 | <Lachy_> | :-) |
| 15:03 | <zcorpan_> | pehaps people will create their own test cases after seeing acid |
| 15:03 | <Dashiva> | Why not let people pick a color stylesheet, then? |
| 15:03 | <Lachy_> | yes, that's what they did with acid 2 |
| 15:04 | <annevk> | acid3-red |
| 15:04 | <zcorpan_> | acid2 contained red when it failed |
| 15:04 | <Lachy_> | the acid test isn't useful as is to implementers, except as a way to say "oh look, we have some bugs", but not any more specific without deconstructing it |
| 15:04 | <zcorpan_> | so people might think that acid3 fails if it contains red |
| 15:19 | <Philip`> | Acid2 had a happy face when it passed, but that doesn't mean people will think Acid3 hasn't passed just because it doesn't have a face |
| 15:20 | <Philip`> | Acid1 had red too |
| 15:21 | <zcorpan_> | indeed, it can contain pretty much anything when it passes |
| 15:21 | <zcorpan_> | it's just a fact that most tests contain red when they fail |
| 15:52 | <Lachy> | it is so confusing having 2 Philip Taylors on the list! I have to check the e-mail address just to see if it's the sensible one, or the other one. :-/ |
| 15:53 | <annevk> | they both use the suffic (Webmaster)? |
| 15:53 | <Lachy> | no, which is good |
| 15:53 | <annevk> | so you can just check that |
| 15:54 | <Lachy> | I just got confused at first, cause I thought he had just removed that from his name |
| 15:54 | <annevk> | whoa, already 5pm |
| 15:55 | <annevk> | I think tomorrow I'll do some implementing then of my xml5lib idea unless something important comes up |
| 16:03 | <Philip`> | Lachy: You could check punctuation too - one does /italics/ and double-spaces between sentences and spaces before colons and question marks, whereas the other doesn't :-) |
| 16:05 | <Lachy> | oh no, and I thought you were the sensible one. It's 2 spaces after a full stop! :-) |
| 16:06 | <othermaciej> | 2 spaces between sentences is incorrect when using a proportional font |
| 16:07 | <Lachy> | plain text emails use monospace fonts |
| 16:08 | <Lachy> | (well, actually, they use whatever font the user likes, but typically monospace) |
| 16:08 | <othermaciej> | plain text emails don't use any specific font; how they are displayed depends on the mail client |
| 16:08 | <gavin_> | hmm, really? I'd have thought it'd be incorrect to use it with monospace fonts |
| 16:08 | <gavin_> | but I know nothing about this! |
| 16:09 | <annevk> | apparently text/plain is displayed using <plaintext> in some UAs |
| 16:09 | <othermaciej> | Mail on Mac OS X displays them by default in a proportional font, for instance |
| 16:09 | <Lachy> | ascii art and code samples look better when viewed with monospace fonts |
| 16:09 | <annevk> | someone please call tag abuse! |
| 16:09 | <othermaciej> | annevk: it's just an example of how browsers hate standards |
| 16:09 | Lachy | doesn't like proportional fonts for emails, it just looks wrong |
| 16:10 | <annevk> | geek |
| 16:10 | annevk | uses monospace too though |
| 16:10 | <othermaciej> | proportional fonts look better to me unless someone went out of their way to make a point and align things in a way that requires a monospace font |
| 16:10 | <othermaciej> | when I have a part of my email that requires monospace display to read right, I ususally send an HTML email w/ an explicit font setting |
| 16:11 | <Lachy> | I just assumed most people would use monospace |
| 16:11 | <othermaciej> | so that I know my reader will get the right thing |
| 16:11 | <othermaciej> | I don't know how other mail clients are configured out of the box |
| 16:12 | <Lachy> | I never send HTML email |
| 16:12 | <othermaciej> | gmail doesn't use a monospace font by default |
| 16:12 | <othermaciej> | I don't think any other webmail client does |
| 16:12 | <Lachy> | yeah, gmail is broken |
| 16:12 | <othermaciej> | I'd be very surprised if Exchange does |
| 16:13 | <Lachy> | I don't think it does, but I think it offers the choice, IIRC |
| 16:13 | <othermaciej> | so probably most people use the default settings of popular mail clients |
| 16:13 | <Lachy> | default for Thunderbird is monospace |
| 16:13 | <mpt> | Next up from the WhatWG: RFC5822 |
| 16:14 | <Lachy> | LOL |
| 16:15 | <othermaciej> | the RFCs don't go that high yet, do they? |
| 16:15 | <Lachy> | they're up to 4xxx |
| 16:15 | <annevk> | otherwise we'd have 8225 |
| 16:17 | <Lachy> | We've got RFC5616, RFC5023 and RFC5854 to write first :-) |
| 16:18 | <annevk> | 3023 -> 5023? |
| 16:18 | <annevk> | right |
| 16:18 | <Lachy> | yes |
| 16:18 | annevk | will incorperate 3023 in XML5 |
| 16:18 | <annevk> | of course, that won't be done when I fnish my project, but some of it will be in |
| 16:18 | <Lachy> | 2854 (text/html) will be in HTML5 anwya |
| 16:18 | <Lachy> | *anyway |
| 16:19 | annevk | wonders how many people will appreciate XML5 |
| 16:19 | annevk | thinks it's a nice project for now |
| 16:19 | <Lachy> | I bet Philip Taylor (Webmaster) and Gareth Hays won't be happy |
| 16:19 | <mpt> | XML5? What's that? |
| 16:20 | <annevk> | superset of XML1 and XML1.1 with user friendly error handling |
| 16:20 | <Lachy> | non-draconian XML |
| 16:20 | <mpt> | oh boy |
| 16:21 | <annevk> | mpt, the idea or the mess in e-mail it might create? |
| 16:21 | <mpt> | I don't care about the mess in e-mail, I'm not subscribed to any w3.org lists |
| 16:21 | <mpt> | I'm just wondering whether XHTML5 would ever be an XML5 application |
| 16:21 | <annevk> | all things XML will be XML5 |
| 16:21 | <annevk> | it's like all things HTML are HTML5 |
| 16:21 | <mpt> | seeing as how HTML5's error recovery is so element-specific |
| 16:22 | <annevk> | oh |
| 16:22 | <annevk> | XHTML5 will use XML5 error handling which is not element-specific |
| 16:22 | <annevk> | if it's up to me |
| 16:22 | <Philip`> | But you couldn't write X(HT)ML5 documents and have them degrade gracefully in legacy user agents |
| 16:22 | <annevk> | XML would just stay a generic language |
| 16:22 | <mpt> | annevk, won't that break the Web? |
| 16:22 | <annevk> | mpt, XHTML isn't used |
| 16:22 | <Lachy> | the web is already broken, XML on teh web isn't well formed |
| 16:22 | <annevk> | mpt, and you'll only render more if you start "fixing" XML |
| 16:23 | annevk | isn't talking about XHTML as text/html, that's HTML5 |
| 16:23 | <mpt> | my head hurts |
| 16:23 | <annevk> | it's all about MIME types :) |
| 16:23 | <mpt> | My day-job is XHTML-as-text/html |
| 16:23 | <annevk> | XML MIME types -> XML5, text/html -> HTML5 |
| 16:24 | <annevk> | mpt, that would use the HTML5 parsing algorithm |
| 16:24 | <mpt> | ok, but then, the error recovery for HTML5-with-slashes will still be different from that in XHTML5 |
| 16:24 | <gsnedders> | yes |
| 16:24 | <gsnedders> | XHTML-as-text/html is currently parsed as malformed HTML. |
| 16:25 | <gsnedders> | (to the extent of which HTML can be malformed) |
| 16:25 | <mpt> | So XHTML5 will be how we escape to a world of predictable error handling? |
| 16:25 | <mpt> | (as in human-predictable) |
| 16:26 | <gsnedders> | both will be predictable if you know the rules :P |
| 16:26 | <mpt> | gsnedders, I'm assuming most humans won't memorize the HTML5 rules |
| 16:26 | <gsnedders> | mpt: most humans won't memorise XML5 rules either |
| 16:27 | <mpt> | Then make them simpler |
| 16:27 | <Philip`> | Doesn't that just depend on how complex the XML5 rules are? |
| 16:27 | <annevk> | XML5 rules are very simple in my head |
| 16:27 | <gsnedders> | mpt: most humans have bo reason to. |
| 16:28 | mpt | tries to figure out how to download Opera |
| 16:28 | <annevk> | "</test>" -> if <test> is in scope, close everything up to and including <test>, otherwise, ignore |
| 16:28 | <annevk> | "<test>" -> append a tag to the stack of open elements |
| 16:28 | <annevk> | that's about it |
| 16:28 | <mpt> | ok, that's simple enough |
| 16:28 | <annevk> | on popular request we might get </> -> pop an element from the stack of open elements |
| 16:29 | <mpt> | I guess the simplest counterexample would be <a><b><c><d> </c></b></a> |
| 16:29 | <mpt> | oh wait, no, that works too |
| 16:29 | <mpt> | up to and including |
| 16:29 | <mpt> | Nifty, I like it |
| 16:32 | <Lachy> | I don't think you should define new features that would be incompatible with XML 1.0 well-formedness constraints |
| 16:32 | <Lachy> | in other words, a conforming XML5 doc must be a well formed XML 1.0 doc |
| 16:33 | <annevk> | I don't want to restrict characters in element names for no good reason |
| 16:33 | <gsnedders> | any well formed XML 1.0 must be a well formed XML 5 document, mapping to the exact same DOM tree, IMO |
| 16:34 | <annevk> | yes |
| 16:34 | <annevk> | that's a requirement |
| 16:34 | <mpt> | annevk, how about not being able to see any error even after a validator points it out, because in an element's end tag you've accidentally used a Unicode character that looks extremely similar to the one you meant |
| 16:34 | <annevk> | I'd like to require the same for XML 1.1 |
| 16:34 | <annevk> | mpt, aren't you doing something with usability? :) |
| 16:35 | <mpt> | I don't fully understand that question |
| 16:35 | <annevk> | note that XML 1.1 allows way more characters in tag names |
| 16:35 | <annevk> | almost unrestricted |
| 16:36 | <annevk> | mpt, well, (1) the validator could go to extreme lengths and make sure those are clear, (2) if people are using such tag names they probably know what they're doing |
| 16:36 | <Lachy> | ah, good point |
| 16:36 | <mpt> | (1) "the tools will save us" |
| 16:36 | mpt | ducks |
| 16:37 | <annevk> | yeah, fair enough |
| 16:37 | <mpt> | (2) "accidentally" |
| 16:38 | annevk | blames it on XML 1.1 |
| 16:38 | <mpt> | but if XML 1.1 already allows non-Ascii characters, I guess that's lost |
| 16:39 | annevk | likes it when the obvious things (such as "allow unicode") have nasty flaws |
| 16:39 | <annevk> | (it also goes for "use XML" which is fricking complicated compared to say, JSON) |
| 16:40 | <mpt> | The AGM of the Law of Unintended Consequences Fan Club is now in session |
| 16:40 | <hsivonen> | mpt: XML 1.0 allows non-ASCII element names |
| 16:40 | <mpt> | Ooh, I know, make them non-conformant but define how they should be parsed |
| 16:41 | <hsivonen> | mpt: XML 1.1 is an unpragmatic excercise in markup *nationalization* (not *inter*nationalization) by allowing Khmer, etc. element names that XML 1.0 did not allow |
| 16:42 | <hsivonen> | mpt: XML 1.1 is about political correctness and causes harm to real world |
| 16:42 | <annevk> | no, XML 1.0 only allowed Unicode 2.0 characters |
| 16:42 | <annevk> | XML 1.1 allows all characters (with some restrictions) |
| 16:42 | <hsivonen> | annevk: right. which is why e.g. Khmer was not allowed |
| 16:43 | <hsivonen> | annevk: but most of e.g. Japanese was covered in XML 1.0 |
| 16:43 | <annevk> | mpt, that's an idea |
| 16:43 | annevk | wonders how that will fly |
| 16:44 | <mpt> | <＜﹤≲≳﹥＞></＜﹤≲≳﹥＞> |
| 16:45 | <hsivonen> | annevk: will your XML5 be resilient to Unicode normalization combining an combining solidus with >? |
| 16:47 | <annevk> | aah |
| 16:47 | <annevk> | no more Unicode today |
| 16:47 | <annevk> | it will do whatever experts tell is better |
| 16:48 | <annevk> | but hopefully I can stay mostly silent on the dark corners of character representation for a while |
| 17:05 | <zcorpan_> | Lachy: did you see the entry i wrote for the faq? |
| 17:06 | <Lachy> | no |
| 17:08 | <Lachy> | zcorpan_, where did you post it? |
| 17:09 | <zcorpan_> | in here... can't find it in the logs though |
| 17:13 | <Philip`> | Was it while Krijn was offline? |
| 17:14 | <zcorpan_> | could be |
| 17:15 | <zcorpan_> | seems i've lost it too |
| 17:15 | <Lachy> | what was it about? |
| 17:15 | <Lachy> | I have almost full logs, so if you can tell me what to search for... |
| 17:16 | <zcorpan_> | "why does html5 allow for deprecated elements or tag soup?" |
| 17:16 | <zcorpan_> | or something like that |
| 17:16 | <zcorpan_> | "actually it doesn't" |
| 17:17 | <Philip`> | Look for "this should be added to the faq" |
| 17:17 | <Lachy> | May 02 10:38:39 <zcorpan_> Lachy_: perhaps we should add something along the following lines to the faq... |
| 17:17 | <Lachy> | May 02 10:38:46 <zcorpan_> Why does HTML5 allow for deprecated markup or tag soup? |
| 17:17 | <Lachy> | May 02 10:38:46 <zcorpan_> Actually it doesn't. This is a misconception that comes from a fundamental misunderstanding of what the specification is saying. |
| 17:17 | <Lachy> | May 02 10:38:46 <zcorpan_> The HTML5 spec defines what UAs must do when they are confronted with invalid markup, as a way to achieve interoperability and reduce the need for reverse engineering other browsers. For instance, it is defined what to do with misnested tags. This does not imply that authors are allowed to misnest tags. |
| 17:17 | <Lachy> | May 02 10:38:46 <zcorpan_> The HTML5 spec also defines what authors must do in order to create conforming documents, as a way to promote the creation of accessible and device-independent documents. For instance, authors must not use the marquee element. This does not imply that UAs must ignore marquee elements. |
| 17:17 | <Lachy> | May 02 10:38:49 <zcorpan_> You have to be able to make the distinction between the rules that UAs have to follow to be conforming, and the rules authors have to follow to be conforming. They are completely orthogonal. |
| 17:17 | <zcorpan_> | yes, that |
| 17:17 | <Lachy> | I'll review it later |
| 17:17 | <zcorpan_> | ok |
| 17:17 | Lachy | -> bed! |
| 17:18 | <zcorpan_> | cya |
| 17:37 | <zcorpan_> | annevk: shouldn't you change http://annevankesteren.nl/img/logo to say "WEBLOG5"? :) |
| 17:37 | <zcorpan_> | or "WEBLOG42" |
| 17:58 | <mpt> | dbaron, where can I find an explanation of your quit message? |
| 17:59 | <dbaron> | it's just a message printed by a lisp implementation I was using |
| 17:59 | <dbaron> | it had a generational GC |
| 17:59 | <dbaron> | it should make sense if you look up generational garbage collection |
| 17:59 | <mpt> | ok, thanks |
| 17:59 | <mpt> | It's been bothering me for years |
| 17:59 | <dbaron> | I suppose the idea is sort of that I'm getting collected by the garbage collector and disappearing. :-) |
| 18:04 | <dbaron> | Hrm, I have a fixed bug report claiming we implemented http://www.whatwg.org/specs/web-apps/current-work/#alternate-style-sheets |
| 18:05 | <dbaron> | but that anchor doesn't work |
| 18:05 | <dbaron> | Hrm, I have a fixed bug report claiming we implemented http://www.whatwg.org/specs/web-apps/current-work/#alternate-style-sheets |
| 18:05 | <dbaron> | but that anchor doesn't work |
| 18:05 | <dbaron> | how would I find where that content is now? |
| 18:05 | <dbaron> | Did it move to some other spec? |
| 18:05 | <dbaron> | And if so, shouldn't the anchor stay, with a pointer? |
| 18:09 | <gavin_> | it's probably http://www.whatwg.org/specs/web-apps/current-work/#link-type |
| 18:10 | gavin_ | also finds https://bugzilla.mozilla.org/show_bug.cgi?id=200930#c96 :) |
| 18:10 | <Philip`> | It would be nice if the links didn't move, but the tools aren't set up to make that happen |
| 18:10 | <zcorpan> | http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.src.html?content-type=text/html;%20charset=utf-8 |
| 18:19 | <jruderman> | http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html#dynamically ? seems newer |
| 18:21 | <Philip`> | annevk: The list of acknowledgements in that CSSOM document isn't quite alphabetical ("Sj" before "Si") |
| 18:21 | <jruderman> | if a stylesheet has been in the document before and it's put back into the document, should it go through that algorithm to decide whether it's enabled or should it remember whether it was enabled? |
| 18:22 | <jruderman> | "If new style sheets with titles are added to the document" ... i guess it depends on what "new" means :( |
| 18:26 | <jruderman> | i guess i'll have to ask annevk |
| 18:31 | <Hixie> | dbaron: it's in the CSSOM spec now |
| 18:31 | <Hixie> | http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?rev=1.35&content-type=text/html;%20charset=utf-8 |
| 18:32 | <Hixie> | hsivonen: so, my requirements for the <font>/style="" thing is that style="" not be allowed everywhere, since that encourages media-specific markup. |
| 18:33 | <Hixie> | hsivonen: however, i acknowledge that we have to deal with WYSIWYG UAs that don't have any proven-usable way to encode author intent |
| 18:33 | <Hixie> | hsivonen: i'm open to suggestions, but putting style="" everywhere only deals with the use case of one of the camps involved in the discussion |
| 18:36 | zcorpan | thinks that disallowing style="" on any element results in not using any other element than <font>, thus resulting in even worse media independence |
| 18:37 | <zcorpan> | e.g. instead of <h1 style> wysiwyg tools would just emit <font style> |
| 18:42 | <Hixie> | wysiwyg tools can use the new embedded <style> and IDs or classes with <div>s and <p>s |
| 18:43 | <Hixie> | or we could provide them with style="" everywhere |
| 18:43 | <Hixie> | the thing is wysiwyg tools are a unique case, and what we allow for wysiwyg tools shouldn't apply to templates, hand-written content, etc |
| 18:43 | <Hixie> | imho |
| 18:44 | <jruderman> | how would you allow different things for wysiwyg than for templates? |
| 18:45 | <zcorpan> | Hixie: the result will be that those who hand-write templates will add the <meta> to claim that they are wysiwyg. so they can use style="" and pass validation |
| 18:45 | <zcorpan> | q.v. transitional doctype and target="" |
| 18:45 | <zcorpan> | *or* they will come up with uglier hacks |
| 18:45 | <zcorpan> | q.v. adding target="" with javascript |
| 18:48 | <zcorpan> | so if we find that we need to allow something for wysiwyg, it has to be conforming for anyone (yet we can discourage or say that authors SHOULD NOT do it or whatever, but trying to force them not to will lead to the same path as target="" situation today, i think) |
| 18:51 | <zcorpan> | or say that it isn't conforming but say that wysiwyg tools can emit it anyway |
| 18:52 | <zcorpan> | what i'm saying is that the wysiwyg meta tag is the new transitional doctype |
| 18:52 | <dbaron> | Hixie, but how do I learn that from the URL I gave above? |
| 18:53 | <zcorpan> | there should be a note in WA1 that has that id, saying that it has moved to cssom :) |
| 18:56 | <Hixie> | learn what? |
| 18:56 | <zcorpan> | that it has moved to cssom |
| 18:57 | <Hixie> | jruderman, zcorpan: i don't know, i don't have a good solution. if i did, we wouldn't be arguing about it. |
| 18:57 | <Hixie> | oh, i see |
| 18:57 | <Hixie> | (re the altss) |
| 18:57 | <Hixie> | i guess i can add a redirecty-like thing |
| 18:57 | <Hixie> | i might end up just merging it back in if anne doesn't get on with it :-) |
| 18:59 | <Hixie> | ok, added a link |
| 19:09 | <Hixie> | dbaron: i added a link to the spec |
| 19:10 | <dbaron> | thanks |
| 19:11 | <Hixie> | np |
| 19:14 | <othermaciej> | zcorpan: isolating the use of purely presentational inline markup seems to have some value |
| 19:14 | <othermaciej> | I'm not sure of the right way to do it myself |
| 19:14 | <othermaciej> | except that most of the extremist positions don't seem right to me |
| 19:16 | <othermaciej> | personally I'd just allow the style attribute on everything still, it seems like a useful shortcut for scoped <style> that also degrades gracefully in existing browsers |
| 19:16 | <othermaciej> | and it doesn't preclude including both aural and visual rules, say |
| 19:17 | <othermaciej> | it does rule out having separate print and screen rules, but that doesn't mean you can't use a scoped <style> if you want to do that |
| 19:17 | <Hixie> | the problem with style="" is that it encourages thinking in a media-specific way |
| 19:17 | <Hixie> | imho |
| 19:17 | <Hixie> | i mean we have inline <style> elements now |
| 19:17 | <Hixie> | that go almost anywhere |
| 19:17 | <Hixie> | and are scoped |
| 19:17 | <Hixie> | why use style=""? |
| 19:17 | <Hixie> | just to omit a selector? |
| 19:20 | <othermaciej> | to omit a selector, an id, and an extra element when you want to apply a style to exactly one element |
| 19:20 | <othermaciej> | or, to apply a scoped style that degrades gracefully to HTML4 UAs |
| 19:20 | <othermaciej> | these seem like practical reasons to me that override concerns about encouragement - seems like that is better addressed through providing scoped style for cases where multiple media must be styled differently |
| 19:20 | <zcorpan> | i'd be fine with dropping style="" altogether, but i don't think making it allowed based on a magic <meta> |
| 19:20 | <zcorpan> | ...is a good idea |
| 19:20 | <Hixie> | i agree that the magic <meta> thing sucks |
| 19:20 | <othermaciej> | do you have any data on how many style blocks or stylesheets have an @media rule or are media-scoped? |
| 19:20 | <Hixie> | no, but i don't imagine it's many at all |
| 19:20 | <othermaciej> | (i.e. through the media="" element) |
| 19:21 | <bewest> | what's the issue? |
| 19:21 | <othermaciej> | if it wasn't very many, that seems to be evidence against a theory that <style> better encourages thinking about multiple-media than style="" |
| 19:22 | <Hixie> | bewest: the issue is that we have several groups with contradictory requirements. we have people who don't want people to let people write presentational markup at all (and want style="" gone forever), we have wysiwyg editors who can only output presentational markup and so need style="", and we have everyone in between. |
| 19:23 | <bewest> | ok |
| 19:23 | <bewest> | yeah, I've been trying to follow along |
| 19:23 | <bewest> | thanks |
| 19:24 | <zcorpan> | currently i think the best outcome is to make style="" conforming on any element for anyone, but at the same time say that authors should not use it (and cite reasons why in the spec, and why it is conforming anyway) |
| 19:24 | <Hixie> | the idea of making style="" only apply to <font> was that we could attach the stigma of <font> to style="" |
| 19:24 | <bewest> | isn't the solution in these kinds of circumstances usually to remove some of the requirements until the issue is solveable? |
| 19:25 | <Hixie> | another possibility is to allow style="" on <font> and <div>, and allow them everywhere |
| 19:25 | <bewest> | zcorpan: that sounds like a good idea |
| 19:25 | <othermaciej> | at least some strict opponents of presentational markup would like to eliminate <b>, <i> and <font>, but have no problem with style="" |
| 19:25 | <Hixie> | (as in, remove the wysiwyg flag) |
| 19:26 | <othermaciej> | I'm not sure if they have clearly thought through their point of view though |
| 19:26 | <zcorpan> | Hixie: (yes) |
| 19:26 | <Hixie> | othermaciej: i'm trying to address their underlying requirements, not what they say they want, which is often stupid and illogical :-) |
| 19:26 | <bewest> | is anyone advocating wysiwyg POV or are we guessing? |
| 19:27 | <Hixie> | bewest: in this discussion, othermaciej and i both represent wysiwyg interests. |
| 19:27 | <othermaciej> | Hixie: I'm not sure removing style="", allowing it on <font> for WYSIWYG only, and adding scoped <style> addresses any actual requirements |
| 19:27 | <Hixie> | othermaciej: i agree |
| 19:27 | <Hixie> | othermaciej: the current spec is a failed experiment |
| 19:27 | <Hixie> | that much is clear |
| 19:28 | <Hixie> | what would the people here think of allowing style="" on certain elements, namely <font>, <div>, maybe <p>, maybe <section>? |
| 19:28 | <othermaciej> | ok, I'm caught up on public-html email for the first time in days, clearly time to unsubscribe |
| 19:28 | <Hixie> | i don't think it makes sense to make style="" apply to all elements (e.g. <head>) |
| 19:28 | <zcorpan> | Hixie: i don't see the benefit of allowing on only some elements |
| 19:29 | <Hixie> | the idea is to give the wysiwyg enough hooks to do what they want, but to still flag errors when mere mortals attempt to use style="" |
| 19:29 | <zcorpan> | contenteditable doesn't make sense on <head> either |
| 19:29 | <othermaciej> | putting style="" on <head> is silly mainly because the head is not normally displayed, not because it is intrinsically more bad |
| 19:29 | <othermaciej> | irrelevant also doesn't make sense on <head> |
| 19:30 | <bewest> | Hixie: yeah, I'm against more modality.. there's no harm in allowing style="" on head |
| 19:30 | <zcorpan> | Hixie: i think allowing style="" on only some elements will lead to authors only using those elements |
| 19:30 | <Hixie> | the argument is that there's harm merely in style="" existing |
| 19:31 | <bewest> | I think the idea that style="" is allowed on everything is currently in the mindshare of many authors, whether or not it's used |
| 19:31 | <Hixie> | i agree |
| 19:31 | Hixie | is hoping we can change that mindshare |
| 19:31 | <Hixie> | i shouldn't have mentioned <head> |
| 19:31 | <jruderman> | i'd love to have scoped style |
| 19:31 | <bewest> | my suggestion would be to wait for html6 for that |
| 19:32 | <Hixie> | what can we do to move towards that though? |
| 19:32 | <jruderman> | i don't see the point in breaking the style attribute |
| 19:32 | <bewest> | I like zcorpan's suggestion |
| 19:32 | <othermaciej> | I'm not sure what the harm is of style="" existing that isn't also created by scoped <style> existing |
| 19:32 | <Hixie> | if we don't do anything now, we have no reason to believe anything will change in the future |
| 19:32 | <bewest> | you are doing something: 1.) add an informative note that style="" can be harmful because of media assumptions and 2.) allow <style> anywhere |
| 19:33 | <Hixie> | hmm |
| 19:34 | <bewest> | then the next 10 years of useage can inform the next positive step :-) |
| 19:34 | <Hixie> | maybe we can add two levels of conformance, "five star conforming html5" and "four star conforming html5", where the presence of a style="" attribute causes the document to drop to four stars |
| 19:34 | <Hixie> | what do people think of that idea? |
| 19:34 | <bewest> | that's great |
| 19:34 | <othermaciej> | is that a serious suggestion? |
| 19:34 | <Hixie> | yes |
| 19:34 | <bewest> | kind of like yahoo's browser grades? |
| 19:34 | <bewest> | be careful of slipping down the rabbit hole though |
| 19:34 | <othermaciej> | sounds like a slippery slope |
| 19:35 | <bewest> | people will want graded conformance on other areas as well |
| 19:35 | <Hixie> | slippery slope to where? |
| 19:35 | <zcorpan> | it might still lead to ugly workarounds for people who want five stars but also want to use style="" |
| 19:35 | <othermaciej> | to having many conformance grades with all sorts of differences, not just style="" |
| 19:35 | <bewest> | right |
| 19:35 | <Hixie> | true |
| 19:35 | <othermaciej> | which to me seems like clearly a bad thing |
| 19:35 | <Hixie> | yeah |
| 19:35 | <Hixie> | hmmm |
| 19:35 | <othermaciej> | it would be like Strict/Transitional/Frameset DTDs all over again |
| 19:35 | <bewest> | erm not quite |
| 19:35 | <Hixie> | see, this is why i haven't addressed this issue yet |
| 19:36 | <Hixie> | nobody has come up with a solution that works for all sides |
| 19:36 | <bewest> | there is already different ability levels among authorship |
| 19:36 | <bewest> | it might make sense to capitalize on it |
| 19:37 | <bewest> | whether or not that causes too much work for speccing purposes is a different issue |
| 19:37 | <Hixie> | maybe the two conformance levels can be "valid html5" and "astrophy-approved! valid html5" |
| 19:37 | <bewest> | we have technology for doing feature detection... schematron, griddl, etc... |
| 19:38 | <zcorpan> | if allowing style="" anywhere for anyone is not acceptable, then the next best alternative as i see it is to make it non-conforming for everyone but allow wysiwyg-tools to emit it anyway |
| 19:38 | <Hixie> | zcorpan: unfortunately the flag to distinguish wysiwyg markup from non-wysiwyg markup is itself not acceptable to everyone |
| 19:39 | <zcorpan> | Hixie: without the flag |
| 19:39 | <Hixie> | well then what would the conformance checker say? yay on nay? |
| 19:39 | <zcorpan> | wysiwyg-documents that emit style="" would be non-conforming |
| 19:39 | <zcorpan> | nay |
| 19:39 | <Hixie> | editing tools would never accept that |
| 19:39 | <Hixie> | as in, editing tool representatives |
| 19:40 | <zcorpan> | those two options are the ones i see would prevent ugly workarounds we see today with the transitional/strict situation |
| 19:41 | <zcorpan> | one will not be accepted by semanticists. the other will not be accepted by wysiwyg tools that want to emit conforming content |
| 19:42 | <bewest> | I don't see how you can realistically ax style="" |
| 19:42 | <Hixie> | in continues to amaze me how the xforms advocates totally disbelieve that wf2 has actually managed to spec new features in backwards-compatible ways |
| 19:43 | <bewest> | the path forward would probably look like putting a note that says to avoid style if you can, along with something like "when useage of style="" drops below .5% useage, it will be considered deprecated" |
| 19:43 | <Hixie> | heh |
| 19:43 | <bewest> | and then in the subsequent version drop it :-) |
| 19:43 | <Hixie> | we shouldn't make this conforming if we believe they will one day be non-conforming |
| 19:43 | <othermaciej> | I honestly don't see how having both style="" and scoped <style> is worse than having just scoped <style> |
| 19:43 | <Hixie> | that's just silly |
| 19:43 | <othermaciej> | both allow you to make the same set of mistakes |
| 19:44 | <othermaciej> | and give you the same set of tools to avoid those mistakes |
| 19:44 | <zcorpan> | deprecated! :) |
| 19:44 | <Hixie> | i really thing that style="" encourages worse behaviour than <style>, but i have no evidence for that. |
| 19:44 | <Hixie> | so i can't really argue the case. |
| 19:44 | <bewest> | deprecate: express strong disapproval of; deplore |
| 19:44 | <zcorpan> | but being deprecated would still lead to ugly workarounds because authors don't want warnings |
| 19:45 | <bewest> | zcorpan: but you can't offer any evidence of that either |
| 19:46 | <bewest> | in fact I'm not sure the evidence supports that |
| 19:46 | <bewest> | most authors do author invalid content |
| 19:46 | <zcorpan> | no, i can't prove that it will happen, i have just seen it happen with target="" and strict/transitional |
| 19:46 | <zcorpan> | indeed, it would only be worked around by authors who want conforming documents but also want to use style="" |
| 19:47 | <bewest> | zcorpan: and if <style> was available, why wouldn't they use that? |
| 19:47 | <bewest> | zcorpan: especially if style="" is discouraged? |
| 19:47 | <bewest> | or, am I missing the problem with <style>? |
| 19:47 | <bewest> | what's wrong with <style> again? |
| 19:48 | <zcorpan> | hmm, good question. perhaps because it's more verbose |
| 19:48 | <zcorpan> | but that would be their simplest "workaround" |
| 19:48 | <zcorpan> | which isn't very ugly |
| 19:49 | <zcorpan> | instead of <section><h1 style=...> you would have <section><style scoped>h1{...}</style><h1> |
| 19:49 | <bewest> | meanwhile everyone can write the article entitled "style="" considered harmful" |
| 19:50 | <bewest> | zcorpan: who would? |
| 19:50 | <bewest> | zcorpan: wysiwyg editors or authors? |
| 19:50 | <zcorpan> | bewest: authors who want to pass conformance-checking |
| 19:50 | <bewest> | zcorpan: why would authors use that when there are better ways that are more familiar? |
| 19:51 | <zcorpan> | same reason they are using style="" today |
| 19:51 | <bewest> | hmmm |
| 19:51 | <zcorpan> | (this is if style="" would be made non-conforming) |
| 19:51 | <Philip`> | zcorpan: Wouldn't they want graceful degradation too? (which <style scoped> doesn't really give, unless they're sufficiently careful and test in both old and new browsers) |
| 19:52 | <bewest> | zcorpan: are most people using style=""? |
| 19:52 | <bewest> | isn't this two separate issues? |
| 19:52 | <zcorpan> | Philip`: yes, and then it would be even more verbose |
| 19:53 | <zcorpan> | bewest: no, most people are using tables and <font color> :) |
| 19:53 | <zcorpan> | my issue is, if style="" becomes non-conforming, then authors who use it today and want to pass conformance-checking will try to replace it with something else that does the same thing |
| 19:54 | <zcorpan> | if that something else is more verbose or bad in other ways then i don't see the win of making it non-conforming |
| 19:54 | <bewest> | zcorpan: so what is the preferred way, again? <link /> <style> in head or scoped style blocks? |
| 19:54 | <bewest> | zcorpan: and why do you believe they would opt for scoped style blocks over the other options? |
| 19:55 | <bewest> | zcorpan: you are specifically talking about authors who know that they want their documents to conform? |
| 19:55 | <zcorpan> | they will do what is simplest for them to do. if moving to an external style sheet is simpler than replacing with inline <style>s or something else then they will do that |
| 19:55 | <zcorpan> | bewest: yes (re your last q) |
| 19:56 | <zcorpan> | this is also why i want target="" to be conforming |
| 19:56 | <zcorpan> | (authors are already working around it not being conforming with scripting) |
| 19:57 | <zcorpan> | this is not a large group of people but their workarounds bother me |
| 19:57 | <bewest> | zcorpan: I'm not convinced that people would opt for the nasty workarounds |
| 19:58 | <zcorpan> | bewest: see e.g. http://www.sitepoint.com/print/standards-compliant-world |
| 19:58 | <zcorpan> | they already are |
| 19:58 | <bewest> | zcorpan: is fear of a workaround a good basis for reasoning about a feature? |
| 19:59 | <zcorpan> | not sure. wysiwyg tools could emit similar workarounds too, fwiw, if they want to emit conforming documents |
| 20:00 | <bewest> | I thought that's the use case we're trying to support, though |
| 20:00 | <bewest> | ooo lunch is here |
| 20:01 | <zcorpan> | yes, but why is e.g. scoped style better than equivalent style=""? |
| 20:01 | <zcorpan> | (i know scoped style is more powerful, but it's also more verbose) |
| 20:59 | <bewest> | zcorpan: scoped style allows decoupling of media-specific stuff |
| 21:00 | <zcorpan> | bewest: yes |
| 21:43 | <zcorpan> | how should i make it easy to contribute to http://simon.html5.org/temp/author-view-of-html5.css ? move it to google code? |
| 21:44 | <zcorpan> | the wiki? |
| 21:44 | <bewest> | google code is good |
| 21:45 | <bewest> | I've seen people serve files straight from google code svn |
| 21:45 | <zcorpan> | ok. perhaps it should be part of the html5 project at google code |
| 21:45 | <bewest> | svn seems to be the favorite tool these days |
| 21:46 | <zcorpan> | Hixie: how do i go about to add it to http://code.google.com/p/html5/ ? |
| 21:47 | <Hixie> | check out the subversion repository |
| 21:47 | <Hixie> | add a directory |
| 21:47 | <Hixie> | check it back in :-) |
| 21:48 | <zcorpan> | ok |
| 21:50 | <Philip`> | hsivonen: For the table at http://hsivonen.iki.fi/doctype/, in Konqueror 3.5.5 I see exactly the same behaviour as the "Moz & Safari" column, in case you want to update it |
| 21:50 | <Philip`> | (Or should I send email or something?) |
| 21:56 | <zcorpan> | http://html5.googlecode.com/svn/trunk/author-view-of-html5/ |
| 21:58 | <Philip`> | javascript:void(document.getElementsByTagName("head")[0].innerHTML+="<link rel=stylesheet href=http://simon.html5.org/temp/author-view-of-html5.css>";) looks like a shorter valid (I hope) alternative |
| 21:59 | <Philip`> | ...but that should probably point to the SVN URL in any case |
| 21:59 | <zcorpan> | Philip`: you're free to modify it :) |
| 21:59 | <zcorpan> | the svn url is text/plain |
| 22:01 | <Philip`> | I'd have to remember my password before modifying it :-) |
| 22:01 | <zcorpan> | http://code.google.com/hosting/settings |
| 22:02 | <Philip`> | text/plain: Ah, okay - that seems to make it work in Opera but not Firefox |
| 22:03 | <zcorpan> | it could perhaps be hosted somewhere at whatwg.org (as text/css) and the spec could include a <link> to that |
| 22:03 | <zcorpan> | either updated automatically or manually |
| 22:41 | <Hixie> | othermaciej: you need .value on the form control names in your examples, fyi |
| 22:41 | <Hixie> | as in onforminput="value = 'Hello, ' + firstname.value + ' ' + surname.value; ..." |
| 22:42 | <othermaciej> | Hixie: feel free to correct me - I'm pretty sure that the XForms version would still be much longer if not entirely impossible |
| 22:42 | <Hixie> | i don't think it needs corrections |
| 22:43 | <Hixie> | just thought you'd want to know :-) |
| 22:43 | <Hixie> | another thing is that in wf2 instead of onkeypress it's better to use oninput |
| 22:43 | <Hixie> | i love your autosuggest thing though |
| 22:43 | <Hixie> | that's awesome |
| 22:43 | <Hixie> | two lines! |
| 22:43 | <bewest> | ooOOo where? |
| 22:44 | <Hixie> | <input name="search" type="text" list="suggestions" onkeypress="list.data = '/suggest?prefix=' + value"> |
| 22:44 | <Hixie> | <datalist id="suggestions" data="/suggest"></datalist> |
| 22:44 | <Hixie> | (except s/keypress/input/) |
| 22:45 | <bewest> | this is in wf2 or xforms? |
| 22:45 | <gavin_> | wf2 |
| 22:45 | <Hixie> | wf2 |
| 22:45 | <Hixie> | should work in opera 9 today, even |
| 22:45 | <Philip`> | The lack of ugly namespace prefixes should make it obvious :-) |
| 22:46 | <bewest> | ah that's a nice improvement over the acrobatics required to do it today |
| 22:46 | <Hixie> | yeah |
| 22:47 | <bewest> | I assume the suggestions are stylable via css? |
| 22:48 | <Hixie> | that may or may not be a good assumption |
| 22:48 | <Hixie> | not sure |
| 22:49 | <othermaciej> | Hixie: the one thing it doesn't do well is it lacks hysteresis |
| 22:49 | <othermaciej> | Hixie: that could be added w/ a bit of script |
| 22:50 | <othermaciej> | bewest: they are given as <option> elements, so depends on whether your UA respects styles on <option> |
| 22:50 | <Hixie> | othermaciej: the waiting for the user to stop typing? |
| 22:50 | <othermaciej> | yeah |
| 22:50 | <Hixie> | othermaciej: that's why you should use oninput="" |
| 22:50 | <Hixie> | it's defined to fire "when the UA thinks the user has stopped inputting" or some such |
| 22:50 | <othermaciej> | Hixie: if oninput has that behavior then it totally wins :-) |
| 22:50 | <Hixie> | :-) |
| 22:51 | <Hixie> | you sure you want me to write those examples? |
| 22:51 | Hixie | is tempted to not bother yet and instead just work on html5 |
| 22:52 | <othermaciej> | well, I don't know that it would persuade John Boyer, but it could be informative to others |
| 22:52 | <Dashiva> | Wow |
| 22:52 | <Hixie> | i guess i'll do that tomorrow |
| 22:52 | <Dashiva> | Chris isn't top-posting. It's a miracle! |
| 22:52 | <Hixie> | bbiab |
| 22:53 | <othermaciej> | Hixie: I actually didn't think it would be that easy to do that in WF2 (the Ajax combo box thing), I was pleasantly surprised |
| 22:53 | <bewest> | othermaciej: I think you really stuck a bee in his bonnet... |
| 22:53 | <othermaciej> | but Mark Birbeck brought up Ajax libraries |
| 23:04 | <zcorpan> | <?php header("Content-Type: text/css"); include("http://html5.googlecode.com/svn/trunk/author-view-of-html5/author-view-of-html5.css";); ?> |
| 23:04 | <zcorpan> | shouldn't that work? |
| 23:04 | <zcorpan> | http://simon.html5.org/temp/author-view-of-html5.css |
| 23:06 | <Dashiva> | Many systems block crossdomain includes |
| 23:07 | <Philip`> | "URL file-access is disabled in the server configuration" - seemingly not |
| 23:07 | <hasather> | yea, for security reasons |
| 23:07 | <Philip`> | PHP server configuration sounds like fun |
| 23:07 | zcorpan | ponders |
| 23:07 | <Dashiva> | There is A Way (tm) around it |
| 23:08 | <Philip`> | Use Perl? ;-) |
| 23:08 | <zcorpan> | or python |
| 23:08 | <Philip`> | You could write an Apache module in C |
| 23:09 | <zcorpan> | how does one include in python? |
| 23:11 | <Dashiva> | I would try fopen, and if that fails too, fsockopen |
| 23:11 | zcorpan | finds http://www.diveintopython.org/http_web_services/review.html |
| 23:12 | <Philip`> | import urllib; print urllib.urlopen("http://google.com").read() |
| 23:12 | <Philip`> | perhaps |
| 23:12 | <zcorpan> | yeah |
| 23:13 | <Philip`> | Ah |
| 23:26 | <bewest> | <?php header("Content-Type: text/css"); echo file_get_contents("$url"); ?> |
| 23:26 | <bewest> | not include |
| 23:27 | <Dashiva> | Isn't file_get_contents blocked by the same setting as include? |
| 23:27 | <bewest> | no |
| 23:27 | <bewest> | include means execute as php code |
| 23:27 | <bewest> | it's like using eval |
| 23:27 | <bewest> | which is why it's dangerous to use with URLs |
| 23:27 | <bewest> | file_get_contents just reads a file-like object stream |
| 23:28 | <Dashiva> | "You can use a URL as a filename with this function if the fopen wrappers have been enabled." |
| 23:28 | <Dashiva> | If "URL fopen wrappers" are enabled in PHP (...), you can specify the file to be included using a URL |
| 23:28 | <Dashiva> | Seems like the same to me |
| 23:28 | <zcorpan> | "URL file-access is disabled in the server configuration" |
| 23:29 | <zcorpan> | my attempt to do it with python only resulted in 500 internal error |
| 23:29 | <hasather> | zcorpan: is the file executable? |
| 23:29 | <zcorpan> | hasather: yes |
| 23:29 | <bewest> | include is not the same |
| 23:29 | <bewest> | include is like import |
| 23:29 | <bewest> | in python |
| 23:29 | <hasather> | zcorpan: do you have the shebang? |
| 23:29 | <bewest> | or use in perl |
| 23:29 | <Dashiva> | The functionality doesn't matter, the fact is they're blocked by the same setting |
| 23:30 | <zcorpan> | hasather: what shebang? |
| 23:30 | <hasather> | zcorpan: #!/usr/bin/env python |
| 23:30 | <zcorpan> | hasather: yes |
| 23:30 | <hasather> | hmm, ok |
| 23:30 | <zcorpan> | and SetHandler cgi-script |
| 23:30 | <Dashiva> | zcorpan: What if you only do the import and not the print/urlopen call? |
| 23:31 | <zcorpan> | Dashiva: i commented out everything and still got 500 |
| 23:31 | <Philip`> | Are you just doing 'print "Content-Type: text/css\r\n\r\n"' in Python? |
| 23:31 | <zcorpan> | oh, perhaps need that |
| 23:31 | <zcorpan> | forgot |
| 23:35 | <zcorpan> | nope |
| 23:38 | <zcorpan> | <Files author-view-of-html5.css> |
| 23:38 | <zcorpan> | ForceType text/plain |
| 23:38 | <zcorpan> | SetHandler cgi-script |
| 23:38 | <zcorpan> | </Files> |
| 23:39 | <zcorpan> | ah! |
| 23:40 | <zcorpan> | #!/usr/bin/python works |
| 23:41 | <zcorpan> | success! |
| 23:48 | <Dashiva> | Good, because using fsockopen requires you to write and parse HTTP manually |
