| 01:33 | <Hixie> | anyone have any input on the name of the doc="" attribute? |
| 01:33 | <Hixie> | body="" was suggested |
| 01:34 | <Hixie> | seems about as reasonable |
| 01:36 | <nessy> | I quite like using body - it raises the right expectations IMHO |
| 01:38 | <Hixie> | yeah |
| 01:38 | <Hixie> | was considering something like srcbody="" too |
| 01:45 | <nessy> | although … if it contains a full html file with header and all, body may be a bit too restrictive |
| 01:46 | <Hixie> | srcmarkup=""? |
| 01:46 | <Hixie> | srcdata=""? |
| 01:46 | <daedb> | contents="" ? |
| 01:46 | <Hixie> | hmm |
| 01:47 | <nessy> | it's either html or xhtml, right? |
| 01:47 | <Hixie> | it's likely to be whatever the document is |
| 01:47 | <Hixie> | so xml in xhtml, html in text/html |
| 01:48 | <nessy> | @webdoc ? @webpage ? |
| 01:48 | <Hixie> | question is, in xml, do we want to require the <html xmlns="..."><head><title/></head><body> ... </body></html> boilerplate? |
| 01:48 | <Hixie> | if we do, then it's going to be far less useful in xml |
| 01:48 | <Hixie> | it's already less useful because XML escaping rules are ridiculous |
| 01:48 | <Hixie> | (e.g. you must escape < in attribute values, iirc) |
| 01:49 | <daedb> | Could you theoretically put for instance SVG in there? |
| 01:49 | <Hixie> | (not to mention that a stray U+FFFF would kill the whole page, etc) |
| 01:49 | <Hixie> | i guess |
| 01:49 | <Hixie> | what would the use case be? |
| 01:49 | <daedb> | I don't know, I haven't really followed the discussion :) |
| 01:49 | <Hixie> | the main use case is for blog comments |
| 01:50 | <Hixie> | which would mostly expect text/html, possibly with embedded svg or mathml |
| 01:50 | <Hixie> | for text/html blogs anyway |
| 01:50 | <nessy> | so, if we allow the contents of a body element, only, would that be helpful in avoiding the xml/html choice? |
| 01:52 | <Hixie> | xml/html choice? |
| 01:52 | <Hixie> | it would affect what we call the attribute |
| 01:52 | <Hixie> | don't think it would affect any xml/html issue |
| 01:53 | <nessy> | I mean: if we can avoid the need to put the boilerplate in and thus deal with xhtml or html the same way - is that possible? |
| 01:53 | <Hixie> | xhtml and html are totally different |
| 01:54 | <Hixie> | you can't treat them the same way |
| 01:54 | <Hixie> | (however hard people insist on trying) |
| 01:54 | <Hixie> | so i don't think the boilerplate issue affects that per se |
| 01:55 | <Hixie> | what it affects is whether the attribute is really giving the contents of a document's <html:body>, or whether it's giving a full document |
| 01:55 | <nessy> | I see |
| 01:55 | <nessy> | so you would have a content-type attribute, too? |
| 01:56 | <Hixie> | no, it would just be html in text/html docs, and xml in xml docs |
| 01:56 | <nessy> | oh! now I get it. |
| 01:57 | <nessy> | in that case I would not expect to have to repeat the boilerplate |
| 01:57 | <Hixie> | (we don't want to require that non-web xhtml UAs have to include HTML parsers to be XHTML compliant) |
| 01:57 | <nessy> | just use @body , I'd say - it's an additional piece of body text to be displayed |
| 01:58 | <Hixie> | yeah, body and srcbody are the main candidates i think |
| 01:58 | <nessy> | in fact, ppl might get the boilerplate wrong if they are required to repeat it - so that would avoid an additional source of errors IMO |
| 01:58 | <Hixie> | (having "src" at the front is useful from a language usability point of view) |
| 01:58 | <nessy> | yeah, makes sense |
| 01:58 | <Hixie> | makes it long, though, and people might think it's a URL |
| 01:58 | <Hixie> | language design is hard :-P |
| 01:59 | <nessy> | yeah, I was just wondering about that |
| 01:59 | <Hixie> | so much easier to reverse engineer mistakes other people have already made :-P |
| 01:59 | <Hixie> | instead of having to make one's own |
| 01:59 | <nessy> | I know! Tell me about it! I've experimented with so many names for the time-aligned text stuff! |
| 01:59 | <Hixie> | yeah! exactly |
| 02:00 | <nessy> | why not put an email out with your current state of mind and proposing @body and @srcbody and see what ppl say? |
| 02:00 | <nessy> | at the same time propose to avoid the header boilerplate repetition |
| 02:01 | <Hixie> | e-mail threads about names are rarely if ever useful |
| 02:01 | <Hixie> | they just become big bikeshedding threads |
| 02:01 | <nessy> | they will happen anyway, I fear |
| 02:01 | <nessy> | better to direct it than to come back as a flame war ;) |
| 02:01 | <Hixie> | yeah but the more feedback you get on a name, the more people's opinions you eventually have to reject |
| 02:01 | <Hixie> | :-) |
| 02:02 | <nessy> | let others make the arguments on why to reject them ;) |
| 02:02 | <Hixie> | anyway we already had that thread last week |
| 02:02 | <Hixie> | that's where body="" came from |
| 02:02 | <Hixie> | i think i might just go with body="" |
| 02:03 | <nessy> | yeah, though a summary of the reasons and state of thinking is probably good to get everyone on board |
| 02:03 | <nessy> | but I agree: if you choose @body and propose that, it has the same effect |
| 02:19 | karlcow | is checking the code source of Nokia Forum http://www.forum.nokia.com/ xml namespaces and rdf in CDATA but text/html http://redbot.org/?uri=http%3A%2F%2Fwww.forum.nokia.com |
| 02:30 | <Hixie> | man describing the conformance criteria for <iframe body=""> is going to be interesting |
| 07:42 | <MikeSmithX> | hsivonen: so I've ported over George's jing issue-35 patch to the validator-nu branch, with some tweaks |
| 07:42 | <hsivonen> | MikeSmithX: awesome |
| 07:43 | <MikeSmithX> | I think I will have something ready to send you for review later today |
| 07:44 | <hsivonen> | ok |
| 07:44 | <MikeSmithX> | what I added was a way for it to distinguish between the case where a there is a choice among the missing attributes/elements, and the case where there's not |
| 07:44 | <MikeSmithX> | for the case where there's not, it emits a separate error message for each missing attribute/element |
| 07:45 | <MikeSmithX> | for the case where there's a choice, it emits, e.g., "Element object is missing one or more of the following attributes: data type." |
| 07:46 | <MikeSmithX> | I realize that for the case where there's only two attributes/elements in the choice, that doesn't make so much sense. |
| 07:47 | <MikeSmithX> | but I think there are other markup vocabs (DocBook, maybe) that have more complex choice cases than HTML does |
| 07:48 | <MikeSmithX> | as-is, what George's patch does is that it dumps out a text representation of the required content model |
| 07:48 | <MikeSmithX> | basically RNC syntax |
| 07:48 | <MikeSmithX> | but I think for most users that's probably not all that helpful |
| 07:49 | <hsivonen> | indeed |
| 07:50 | <MikeSmithX> | so I think the ambiguity of "missing one or more of" is an acceptable tradeoff vs. exposing end users to raw, potentially complex RNC content models |
| 07:50 | <hsivonen> | yeah |
| 07:50 | <MikeSmithX> | OK, anyway, I will try to get the patch wrapped up shortly |
| 07:51 | <MikeSmithX> | hsivonen: one thing I am not clear on is what the difference is in jing between the "required elements missing" case and what it calls the "unfinished element" case |
| 07:52 | <hsivonen> | IIRC, unfinished element is a special case of the former |
| 07:52 | <MikeSmithX> | but in the v.nu message-emitter, I can see that both cases basically cause the same message to be emitted |
| 07:52 | <MikeSmithX> | hsivonen: OK |
| 07:52 | <MikeSmithX> | for our purposes, it seems like the can be handled the same |
| 07:52 | <hsivonen> | MikeSmithX: I don't really know why Jing makes the distinction |
| 07:52 | <MikeSmithX> | OK |
| 07:55 | <hsivonen> | aaargh. Gecko's HTML serializer can wrap lines inside tags |
| 08:02 | <Hixie> | i blogged the next chapter of my saga with t-mobile |
| 08:03 | <Hixie> | in case anyone cares |
| 08:40 | <Lachy> | Hixie, clearly, you're not supposed to read or try to understand the bills from T-Mobile. You're just supposed to pay them whatever random amount they decide to charge you. |
| 08:43 | <zcorpan> | should doc="" be parsed as xml in xhtml5? |
| 08:45 | <hsivonen> | I hope not |
| 08:45 | <hsivonen> | HTMLness bit-dependent behavior for the lose |
| 08:46 | <zcorpan> | if not, then doc makes html parsing support required |
| 08:47 | <hsivonen> | zcorpan: theoretical purity or Real Problem? :-) |
| 08:47 | <zcorpan> | former |
| 08:47 | <zcorpan> | maybe the spec should require both html and xml support |
| 08:47 | <hsivonen> | zcorpan: fixable by making doc not required for XHTML5-only UAs |
| 08:48 | <Lachy> | hsivonen, why is the HTMLness bit-dependent behaviour bad for this? |
| 08:48 | <othermaciej> | how does innerHTML work in XHTML5 documents? (does it?) |
| 08:48 | <hsivonen> | othermaciej: depends on HTMLness bit |
| 08:48 | <hsivonen> | othermaciej: per spec and per Gecko and IIRC WebKit |
| 08:48 | <hsivonen> | othermaciej: Opera has nicer behavior but is in minority |
| 08:48 | <othermaciej> | I hate varying DOM APIs or markup meaning based on the HTMLness bit, but whether to use the text/html or XML syntax seems one of the cases where it is most justified |
| 08:49 | <othermaciej> | what I hate even more is varying APIs based on quirks mode :-/ |
| 08:49 | <zcorpan> | opera serializes innerHTML differently in xhtml |
| 08:49 | <hsivonen> | Lachy: the problem is that changing one layer of the software stack changes behavior elsewhere |
| 08:49 | <hsivonen> | zcorpan: oh. |
| 08:49 | <hsivonen> | zcorpan: but still parses as HTML on setter? |
| 08:49 | <zcorpan> | hsivonen: yes |
| 08:49 | <hsivonen> | not so nice, then |
| 08:49 | <zcorpan> | no, it's completely bogus |
| 08:50 | <hsivonen> | othermaciej: varying doc is essentially varying a DOM API upon setAttribute() |
| 08:51 | <Lachy> | I suppose if we do make doc HTMLness bit-dependant, then it would mean that scripts interacting with the attribute may have to vary their behaviour based on whether the document is HTML or XHTML. |
| 08:51 | <hsivonen> | my thinking is that text/html vs. application/xhtml+xml choice should affect the hop from server to DOM |
| 08:52 | <hsivonen> | but making various other things change behavior, too, doesn't maintain clean layering in theory and in practice makes it harder to change the hop from server to DOM |
| 08:52 | <othermaciej> | hsivonen: that is a plausible view - but there are DOM APIs that differ which we aren't really free to change, so it seems more valuable to me to keep markup syntax consistency within each serialization |
| 08:53 | <othermaciej> | hsivonen: I wish there were separate APIs for interacting via HTML and XML serializations, so you could pick one explicitly instead of it being based on your MIME type |
| 08:53 | <hsivonen> | othermaciej: IIRC, this was argued differently when I suggested cloning WebKit's HTMLness bit dependency in XMLSerializer into Gecko |
| 08:57 | <hsivonen> | http://msdn.microsoft.com/en-us/library/ms533897%28VS.85%29.aspx |
| 08:57 | <hsivonen> | Documentation mention defer in the context of innerHTML |
| 09:01 | <jgraham> | hsivonen: I think it would be rather confusing if parsing wasn't internally cnsistent within one document |
| 09:01 | <hsivonen> | jgraham: I think we should have html="..." and xml='...' and the author should use the one that matches the page in order to avoid self-confusion |
| 09:02 | <hsivonen> | jgraham: it sucks to change JS library behavior when changing how the DOM gets built |
| 09:02 | <hsivonen> | so JS libs could still use setAttribute("html", "...") on XHTML pages |
| 09:03 | <jgraham> | hsivonen: Apart from that being really ugly, I would expect people to cargo-cult @xml into html documents and get a world of pain out |
| 09:04 | <Dashiva> | It also seems to crash with being able to only support one of HTML and XHTML |
| 09:04 | <jgraham> | In general I don't think that XHTML is a significant enough use case that we should be designing more markup to make it work slightly better |
| 09:04 | <hsivonen> | jgraham: in that case, doc='' should parse as HTML also in XHTML docs |
| 09:05 | <hsivonen> | jgraham: if the party line is that XHTML isn't significant enough |
| 09:06 | <Dashiva> | XHTML should be done with proper serialization and stuff, so it seems very simple to use src="data:..." for that |
| 09:06 | <othermaciej> | hsivonen: I believe I said at the time that I would prefer to have separate APIs for getting XML and HTML serializations, instead of yet another switchy one |
| 09:07 | <othermaciej> | hsivonen: but I don't 100% recall |
| 09:07 | <hsivonen> | othermaciej: right. so wouldn't it be consistent to want explicitly flagged HTML vs. XML here, too, instead of making doc='...' depend on the HTMLness bit? |
| 09:07 | <othermaciej> | I think you wanted to add an explicit way to pick one serialization or the other that struck me as awkard to use and thus I suggested the alternative |
| 09:08 | <othermaciej> | hsivonen: the direct analogy would be to have both xmlDoc and htmlDoc |
| 09:09 | <hsivonen> | othermaciej: so that DOM properties would act differently from setAttribute? |
| 09:09 | <othermaciej> | hsivonen: I didn't imply any such difference |
| 09:09 | <hsivonen> | othermaciej: ah. xmlDoc and htmlDoc look like DOM properties. Did you imply there'd be xml-doc and html-doc content attributes? |
| 09:10 | <othermaciej> | oh sure, they could be spelled like that |
| 09:10 | <othermaciej> | (hard for me to remember what is the predominant convention in HTML) |
| 09:10 | <jgraham> | hsivonen: I also don't think it makes any sense to change the defacto behaviour of innerHTML for this rather similar case |
| 09:10 | <othermaciej> | I'm not saying it's necessarily the best solution |
| 09:10 | <othermaciej> | just that it's the most aligned with my past idea that you referenced |
| 09:11 | <hsivonen> | jgraham: why would we dig the hole deeper in this case if we didn't keep digging the hole deeper with XMLSerializer? |
| 09:14 | <jgraham> | hsivonen: I don't really know what happened with XMLSerializer so I can't defend that |
| 09:15 | <jgraham> | But I am more concerned with parsing being consisntent than serializing |
| 09:15 | <jgraham> | *consistent |
| 09:15 | <othermaciej> | I think there was a discussion of making it auto-switch serializations instead of always outputting XML, and hsivonen suggested a possible way to explicitly pick one or the other |
| 09:15 | <othermaciej> | for doc, it's definitely parsing that matters |
| 09:16 | <jgraham> | For serialiazing with a dedicated serializer API having a switch makes a lot of sense |
| 09:17 | <hsivonen> | I don't see how serializing is different from setAttribute("html", "...") when it comes to decoupling behavior from how the DOM tree got built |
| 09:17 | <hsivonen> | doh. setAttribute("doc", "...") |
| 09:17 | <othermaciej> | decoupling is not the sole relevant consideration here |
| 09:17 | <othermaciej> | that particular decoupling rather |
| 09:18 | <othermaciej> | it just seems odd that embedded inline markup in an XML document would be HTML |
| 09:18 | <Lachy> | I think we need to focus on author expectations for this issue, rather than ease of implementation. |
| 09:18 | <othermaciej> | if there were a way to choose explicitly, it might seem less weird that making the choice works in both serializations |
| 09:18 | <hsivonen> | othermaciej: depends on what your mental model is for the layering of things |
| 09:18 | <othermaciej> | thus, the fact that data: URIs don't switch doesn't seem weird |
| 09:19 | <othermaciej> | because they explicitly use a mime type |
| 09:19 | <hsivonen> | othermaciej: in my mental model, parsing attribute contents is on a different layer on top of parsing the document proper |
| 09:19 | <othermaciej> | thus, html-doc="" / xml-doc="" (or just html="" / xml="") would not strike me as even slightly odd |
| 09:19 | <Lachy> | maybe we could have a mode attribute to go along with doc, so authors could do <iframe doc="..." docmode="xml"> |
| 09:19 | <othermaciej> | hsivonen: yeah, but you actually know how the internals work |
| 09:20 | <othermaciej> | Lachy: or a type="" attribute... |
| 09:20 | <othermaciej> | Lachy: though I am not sure an open-ended set of types is needed |
| 09:20 | <Philip`> | Since lots of authors think they're writing XHTML even when they're actually writing text/html, they'd probably pick xml-doc, which would be bad because it's not really what they expect and it will be confusing |
| 09:20 | <Lachy> | though, maybe the default such an attribute would have to depend on the serialisation |
| 09:20 | jgraham | is not sure support for xml-inside-html is needed at all |
| 09:20 | <othermaciej> | I actually think html="..." might be more clear than doc="..." and doc="..." mode="html" seems unhelpfully more verbose |
| 09:21 | <hsivonen> | jgraham: Anne's blog is a potential use case :-) |
| 09:21 | <jgraham> | hsivonen: In what way? |
| 09:21 | <Lachy> | it might be needed if you wanted to embed SVG as XML within HTML in order to make use of XML-only features, like namespaces |
| 09:22 | <jgraham> | Lachy: If people are doing that we should fix the problem that their use cases cannot be met in the HTML serialization |
| 09:22 | <Lachy> | jgraham, I don't think a significant number of people should be doing that |
| 09:23 | <jgraham> | Lachy: OK so it's probably not a use case worth worrying about |
| 09:23 | <hsivonen> | jgraham: Anne's comment processing is XML. |
| 09:23 | <zcorpan> | anne's blog is a big hack |
| 09:23 | <hsivonen> | jgraham: so if he wanted to sandbox comments, he could emit the comments as XML even though Anne's own content is HTML |
| 09:24 | <hsivonen> | zcorpan: many parts of the Web are |
| 09:24 | <jgraham> | hsivonen: Why? I don't understand why one would choose to open oneself up to the pain of using XML just for user generated content |
| 09:24 | <Philip`> | People who want to do anything fancy with XML can use src="data:application/xhtml+xml,..." and serialise it properly (as Dashiva said) - the whole point of doc="..." is to make the common case more convenient for authors, and the common case is HTML-in-HTML, and it shouldn't be complexified to cope with edge cases that can already be handled with data: |
| 09:24 | <hsivonen> | jgraham: works as a bozo filter for Anne :-) |
| 09:24 | <jgraham> | Philip`++ |
| 09:25 | <hsivonen> | Philip`: I'm OK with that if doc in XHTML parses as HTML, too |
| 09:25 | <hsivonen> | Philip`: I'm OK with XHTML in XHTML people having to use data: |
| 09:25 | <hsivonen> | what I'm not OK with is doc depending on the HTMLness bit of the host DOM |
| 09:25 | <zcorpan> | i'm ok with doc always being parsed as html |
| 09:25 | <zcorpan> | i don't like having two attributes |
| 09:26 | Philip` | doesn't care what happens to it in XHTML because that's not the common case |
| 09:26 | <jgraham> | hsivonen: I don't really see how your objection is more than theoretical purity given that the htmlness bit already bleeds into innerHTML and it seems more likely to align with author expectations if all markup on a page is parsed in the same way |
| 09:26 | <Philip`> | (as long as what happens to it in XHTML doesn't cause the feature to become any more complex in text/html) |
| 09:27 | <zcorpan> | if you adoptNode an iframe, would doc change interpretation? |
| 09:28 | <hsivonen> | jgraham: is the author expectation that if they use XHTML, innerHTML setter in the bowels of a minified JS lib breaks? |
| 09:29 | <Philip`> | jgraham: I suppose it has a practical consequence for HTML-to-XHTML/XHTML-to-HTML conversion tools that don't support scripts |
| 09:29 | <Philip`> | jgraham: because it would (I think?) be the first non-scripted leaking of HTMLness |
| 09:29 | <jgraham> | Philip`: In that you would have to parse and reserialize the attribute? |
| 09:30 | <jgraham> | hsivonen: I guess library authors have to be careful to deal with that or just not support XHTML |
| 09:31 | <Philip`> | jgraham: Yes |
| 09:31 | <jgraham> | biab |
| 09:31 | <othermaciej> | it seems like case sensitivity is likely to bite them before innerHTML |
| 09:31 | <hsivonen> | othermaciej: .localName FTW! |
| 09:31 | <zcorpan> | no-one uses localName |
| 09:31 | <zcorpan> | and localName doesn't work in ie :) |
| 09:31 | <hsivonen> | well, once Opera makes their localName compliant, too |
| 09:32 | <zcorpan> | it's on our to-do list but not at the top |
| 09:32 | <othermaciej> | it might have been smarter in retrospect to add innerXML |
| 09:32 | <othermaciej> | or outerXML |
| 09:32 | hsivonen | wonders if IE9 has DOM Level 2 as part of the rumored SVG work |
| 09:32 | <othermaciej> | whichever makes sense, if any |
| 09:32 | <othermaciej> | instead of overloading innerHTML |
| 09:33 | <othermaciej> | hsivonen: maybe they'll get really excited and implement the SVG uDOM |
| 09:33 | <othermaciej> | complete with Traits! |
| 09:35 | hsivonen | doesn't know what Traits in uDOM is |
| 09:37 | <zcorpan> | don't forget SMIL :) |
| 09:38 | <zcorpan> | wow i now don't have any unread html-related emails |
| 09:38 | <hsivonen> | hmm. What's the point of Traits compared to the old HTML way of having real IDL properties for typed reflection of content attributes |
| 09:38 | <hsivonen> | NIH? |
| 09:39 | <gsnedders> | zcorpan: Yes, mark-all-as-read makes that quite easy. |
| 09:40 | <Hixie> | Lachy: i'd almost be happy with just paying them whatever random amount they charge me, the problem is they simultaneously charge me different amounts! |
| 09:42 | <zcorpan> | hsivonen: the HTML way was too simple and convenient |
| 09:43 | <hsivonen> | Hixie: is T-Mobile the only operator with a network that actually works? |
| 09:43 | <hsivonen> | Hixie: also, does the U.S. have virtual operators operating on top of concrete networks? |
| 09:43 | <Hixie> | no, but it's the only operator i know of with a no-contract unlimited data plan compatible with the nexus one currently |
| 09:43 | <Hixie> | i do not believe there are virtual operators |
| 09:43 | <hsivonen> | Hixie: that is, can you get on T-Mobile's network by dealing with someone else for billing |
| 09:44 | <hsivonen> | ok |
| 09:44 | <Hixie> | dsl has some |
| 09:44 | <Hixie> | i never understood the idea of virtual operators |
| 09:44 | <Hixie> | but anyway |
| 09:44 | <hsivonen> | looks like the U.S. has lots of telco regulation to add in order to catch up |
| 09:44 | <Lachy> | Hixie, the uncertainty principle seems to be applying here. The more you know about the details of the charges, the less you know about what the charges are. |
| 09:45 | <workmad3> | ah, the banking uncertainty principle :) |
| 09:45 | <Hixie> | Lachy: seems that way |
| 09:45 | <hsivonen> | Hixie: having virtual operators decouples competition on customer service from owning the cell towers |
| 09:45 | <Hixie> | hsivonen: doesn't seem to help much with the dsl operators as i understand it |
| 09:46 | <Hixie> | you just get more options to choose your crappy service from |
| 09:46 | <hsivonen> | and you get more points of failure |
| 09:46 | <Hixie> | yeah |
| 09:46 | <hsivonen> | I used to have DSL from an operator that didn't own the copper |
| 09:47 | <hsivonen> | when problems showed up, my realistic recourse was switching to a cable modem |
| 09:47 | Hixie | is pretty sure his t-mobile account is now correctly set up to have the proper "android data" plan, but the phone can still only get a walled garden TCP/IP network, not the Real Web |
| 09:47 | <hsivonen> | fortunately, a cable modem works instantly after signing the contract |
| 09:48 | <Hixie> | hahahahaha |
| 09:48 | <Hixie> | you clearly aren't familiar with US cable modems! |
| 09:49 | <Hixie> | cable modems here can even stop working randomly AFTER they were working! |
| 09:49 | <Hixie> | for no reason other than the cable operator's billing software randomly decides to cut you off without terminating the billing cycle! |
| 09:49 | <hsivonen> | hmm. what's up with the validator.nu DNS |
| 09:50 | <Dashiva> | I can't believe we're talking about poetry again |
| 09:51 | <Lachy> | We have many virtual operators in Australia. There have been problems with this model too, though, since for a long time, Telstra's wholesale division had a monopoly on much of the infrastructure. |
| 09:53 | <Lachy> | at least, that was the case with copper phone lines and the Cable and ADSL network points in the exchanges. Not so much with mobile towers. |
| 09:54 | <zcorpan> | oooh now we have next week in html |
| 09:54 | <zcorpan> | http://blog.whatwg.org/whats-next-in-html-episode-1 |
| 09:56 | <Dashiva> | From HTML+RDFa: "This mechanism should be double-checked against all of the RDFa Javascript implementations to ensure correctness." |
| 09:57 | <Dashiva> | Tail wagging the dog? |
| 09:57 | <zcorpan> | seems like a good idea to check against implementations |
| 09:59 | <hsivonen> | Dashiva: cool to see that RDFa is adopting the HTML5 way of implementations wagging the spec instead of the XHTML2 way of the dog and the tail being separate |
| 09:59 | <Dashiva> | Well, except there's no real legacy to be concerned with here |
| 10:00 | <Dashiva> | And the implementations aren't exactly time-tested either |
| 10:00 | <hsivonen> | Dashiva: both good points |
| 10:02 | <zcorpan> | Hixie: the whatwg spec should be called "HTML (director's cut)" |
| 10:02 | <zcorpan> | or maybe "HTML (editor's split)" |
| 10:03 | <hsivonen> | Editor's split seems more accurate, since the Director might cut it differently |
| 10:03 | <zcorpan> | the whatwg doesn't have a Director, does it? |
| 10:03 | <hsivonen> | good point |
| 10:04 | <Dashiva> | zcorpan: It is the editor's draft already :P |
| 10:04 | <Hixie> | i can't work out a good way to make <iframe body=""> work for the xml mode. All the options suck. Making it use text/html is bad because it means authors who want to use XML can't get away from text/html. Making it imply the boilerplate, effectively giving it a <body> context, is bad because it means you can't give style sheets, etc, in case you are trying to sandbox something more complicated than a blog comment. making it be just a straight xml doc is bad becaus |
| 10:04 | <hsivonen> | Hixie: you got cut off at "straight xml doc is bad becaus" |
| 10:05 | <zcorpan> | Hixie: your comment was cut off at " straight xml doc is bad becaus" |
| 10:05 | <zcorpan> | damn |
| 10:05 | <Dashiva> | What is the use case for @body? In HTML you can leave out all the boilerplate except doctype and title, and in XHTML you get the boilerplate for free from your serialization setup anyhow |
| 10:08 | <Hixie> | ...because it means the common case has oodles of boilerplate |
| 10:08 | <Dashiva> | The common case is HTML |
| 10:08 | <Hixie> | the common case supposing XHTML is being used |
| 10:08 | <Philip`> | Hixie: Authors who want XML can get away from text/html by not using <iframe doc> |
| 10:09 | <Philip`> | just like they'd not use <iframe src=data:text/html,...> |
| 10:09 | <Hixie> | if it's a feature text/html authors will want, why won't xml authors want it? |
| 10:09 | <Dashiva> | Because they have infrastructure to do it automatically? |
| 10:09 | <Hixie> | Dashiva: the use case is mainly CMSes including user-provided comments safely without filtering |
| 10:09 | <Hixie> | why would xml authors have the infrastructure but not html authors? |
| 10:09 | <hsivonen> | Hixie: because there are approximately 2 blogs that have comments and are served as XML |
| 10:09 | <Dashiva> | Because XML requires well-formedness |
| 10:09 | <Hixie> | hsivonen: sure, today |
| 10:10 | <Dashiva> | I'll turn it around: We shouldn't encourage people making XHTML without proper infrastructure |
| 10:12 | <Hixie> | that seems a bit arrogant |
| 10:14 | <Philip`> | Why is "oodles of boilerplate" a problem? |
| 10:15 | <Philip`> | It's only like <html xmlns="http://www.w3.org/1999/xhtml"><head><title/></head><body>...</body></html>; a single time in one of your template files |
| 10:15 | <Philip`> | and you'll already have that a zillion times in all your other template files |
| 10:16 | <Philip`> | and people using XHTML will want to put lots of extra namespace declarations on the <html> and will be unhappy and confused if they can't |
| 10:17 | <Philip`> | (and will want lang and xml:lang on <html> too) |
| 10:17 | <Philip`> | (They could wrap the content in a <div> and put attributes there but nobody ever does that) |
| 10:18 | <Philip`> | (so it'd be weird and confusing to expect them to do so) |
| 10:19 | Philip` | goes away |
| 10:19 | <Hixie> | seems kinda stupid to require that they write <iframe doc='<html xmlns="http://www.w3.org/1999/xhtml"><head><title/></head><body> |
| 10:19 | <Hixie> | just to get to the point where in text/html you would just write <iframe doc=" |
| 10:20 | <hsivonen> | it's generated by The Tooling! |
| 10:20 | <hsivonen> | XML is all about The Toolchain |
| 10:21 | <Dashiva> | The namespaces and other magic attributes are also a good point |
| 10:22 | <Hixie> | man, you guys are really against helping out xml authors |
| 10:23 | <Dashiva> | How is it help? |
| 10:23 | <hsivonen> | I'm not against helping them, but not giving them the stuff they usually like to hang NS decls on doesn't look like helping to me |
| 10:23 | <Hixie> | not all people who will one day use xml are TAG members |
| 10:23 | <Hixie> | some are realy web authors |
| 10:23 | <Dashiva> | Helping them generate non-wellformed content? |
| 10:23 | <Hixie> | s/y// |
| 10:27 | <jgraham> | Hixie: Well some are TAG members, some are HTMLWG chairs and some are high energy physicists |
| 10:29 | <othermaciej> | is anyone all three? |
| 10:29 | <Dashiva> | I don't think any of the chairs are physicists |
| 10:30 | <Dashiva> | (So we don't have to check the TAG) |
| 10:30 | <othermaciej> | then 2 would be the maximal overlap |
| 10:30 | <othermaciej> | but wait, should we count past and/or future chairs? |
| 10:31 | <Dashiva> | Future is a bit iffy |
| 10:45 | <Hixie> | i don't understand why the "applicable specifications" stuff is so hard for people to understand |
| 10:45 | <Hixie> | it's just a description of what has always been the case |
| 10:45 | <Hixie> | did people just not realise that's what was going on? |
| 10:46 | <jgraham> | People seem to think it is magic for some reason |
| 10:46 | <othermaciej> | most specs do not explicitly allow that other specs can modify them |
| 10:47 | <jgraham> | But all specs can effectively be modified by other specs |
| 10:47 | <othermaciej> | the people who are finicky about such things made Modularization |
| 10:47 | <othermaciej> | the people who are not just went ahead and defined ad-hoc extension specs without permission from the spec being extended |
| 10:48 | <Hixie> | HTTP isn't "modular" but people extended that and nobody seems to have a problem with the concept |
| 10:48 | <Dashiva> | They have a problem with the concept if you tell them about it |
| 10:49 | <Hixie> | it's like half the standards community is living in an orwellian "doublethink" world |
| 10:49 | <othermaciej> | I think it's explicitly acknowledging the potential for add-on extensions without formally defining an extension point as such that bothers people |
| 10:49 | <othermaciej> | though I'm not even sure it's fair to say that |
| 10:50 | <othermaciej> | I think there is this idea that either there needs to be a central authority declaring which specs are applicable, or an open-ended extension mechanism where some sort of distributed namespacing allows people to invent extensions with no coordination at all |
| 10:51 | <Hixie> | so why are things like WebDAV ok? |
| 10:51 | <othermaciej> | does the HTTP RFC say anything about other specs defining additional methods? |
| 10:51 | <Hixie> | not as far as i know |
| 10:51 | <othermaciej> | (I don't remember) |
| 10:52 | <othermaciej> | I don't know that it "bothers" anyone, I think some people are just confused |
| 10:52 | <othermaciej> | if a number of people are confused it might be a sign that the spec could be more clear |
| 10:53 | <Hixie> | wooo, my phone works finally |
| 10:53 | <Hixie> | i had to get it to rejoin the network to get t-mobile to consider what plans i had set up, i guess |
| 10:54 | <othermaciej> | I think what might be confusing is that "applicable specification" sounds like a standardese term of art for getting some sort of official blessing or jumping through some hoop, even though HTML5 itself says no such thing |
| 10:56 | <Hixie> | not much i can do if people aren't going to read the spec before getting confused |
| 11:02 | <Lachy> | was my explanation about applicable specifications good, or do you think it's just going to cause more confusion? |
| 11:03 | <Hixie> | seemed fine to me, but then i don't understand what the confusion is |
| 11:03 | <Lachy> | As I understood it, the confusion seemed to be about who or what gave any particular spec the blessing to be an applicable specification. |
| 11:04 | <Hixie> | nothing |
| 11:04 | <Lachy> | I know that. |
| 11:04 | <Lachy> | But there seemed to be an assumption that there would have to be. |
| 11:04 | <Hixie> | why? |
| 11:04 | <Lachy> | I don't know |
| 11:04 | <Lachy> | I'm not the one confused by it. I just tried to explain the situation to those who are. |
| 11:05 | <Hixie> | i don't get why it's not obvious, as it apparently has been with specs before |
| 11:07 | <othermaciej> | Hixie: I think with previous specs, if you wanted to validate against HTML + something else, you were obligated to make a DTD or similar that included some or all of HTML |
| 11:07 | <othermaciej> | at least, that was the expected model |
| 11:08 | <othermaciej> | but now someone could make an HTML5 + MathML 3.0 + SVG 1.1 + Microdata + ARIA validator without making a single schema or DTD including them all |
| 11:08 | <jgraham> | It seems pretty weird to tie the abstract notion of conformance to a particuar technology for assessing conformance |
| 11:08 | <Hixie> | didn't stop <canvas> from being added |
| 11:08 | <othermaciej> | they can just do it |
| 11:08 | <Hixie> | or ARIA |
| 11:08 | <othermaciej> | sure, and <canvas> didn't validate and no one cared |
| 11:09 | <Hixie> | or WF2 |
| 11:09 | <othermaciej> | for ARIA there was the whole detour of pretending to use XML and namespaces and such |
| 11:09 | <othermaciej> | anyway |
| 11:09 | <othermaciej> | you're preaching to the choir |
| 11:09 | <othermaciej> | I'm trying to explain why people might not fully grok the idea |
| 11:09 | <othermaciej> | or at least my best guess |
| 11:10 | <othermaciej> | telling me why they are wrong helps neither me nor them |
| 11:10 | <othermaciej> | though if you are merely rejecting my guesses as ill-founded, then I will concede your guess is as good as mine |
| 11:12 | <Hixie> | i'm just confused |
| 11:12 | <Hixie> | not trying to say anyone is wrong or anything |
| 11:30 | <Philip`> | jgraham: Maybe the difference is that you think conformance is an abstract notion, whereas other people think conformance is what a conformance checker tells you by applying the mechanistic conformance rules that the specification specifies |
| 11:30 | <hsivonen> | Philip`: ITYM s/specification/DTD/ |
| 11:31 | <Philip`> | and they don't accept a notion of conformance where you can't even tell whether a document conforms to HTML5 by looking at its bytes, never mind telling whether it conforms to a more complex set of specification documents |
| 11:31 | <Philip`> | hsivonen: I'm imagining those hypothetical people would accept any kind of schema language, not just DTD |
| 11:32 | <Philip`> | as long as it's one you can feed into a schema checker tool and get a boolean output |
| 11:32 | <Dashiva> | And these people are the ones who decided how an XML document is defined? |
| 11:34 | <Philip`> | They're not the same people who decided to hard-code DTDs into XML (or they're the same people but in the future, where they've realised other schema languages might be better) |
| 12:08 | <jre> | othermaciej, hixie: yes, RFC 2616 does allow wextension methods (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.5.1.1) |
| 12:08 | <Hixie> | how about response codes? |
| 12:15 | <jre> | Hixie, same thing (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.6.1.1) |
| 12:16 | <jre> | I mean, it's easy to check so I was confused about the confusion over here |
| 12:17 | <Hixie> | extension-code doesn't seem to have any semantic meaning defined anywhere |
| 12:17 | <Hixie> | or are you saying I could return HTTP/1.1 999 OK and it would be conforming? |
| 12:18 | <jre> | according to the ABNF yes |
| 12:18 | <jre> | according to the prose in 6.1.1 no |
| 12:18 | <Hixie> | so is it conforming or not? |
| 12:19 | <Hixie> | i can't see anything saying it isn't |
| 12:19 | <Hixie> | which seems suboptimal |
| 12:20 | <jre_> | "The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:" |
| 12:21 | <jre_> | ... |
| 12:21 | <Hixie> | so HTTP/1.1 199 OK is conforming? |
| 12:21 | <jre_> | yes |
| 12:21 | <Hixie> | that seems... bad? |
| 12:21 | <jre_> | why? |
| 12:21 | <Hixie> | what does it mean? |
| 12:21 | <jre_> | ask the status code registry |
| 12:22 | <jre_> | if the recipient doesn't understand it, treat it as 100 |
| 12:22 | <jre_> | "However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached." |
| 12:22 | <Hixie> | ah, ok, so http uses a registry-based centralised extensibility mechanism |
| 12:22 | <Hixie> | ok |
| 12:23 | <jre> | The question was: does HTTP allow extension methods or status codes, and the answer is "yes". How they are registered is orthogonal. |
| 12:23 | <Dashiva> | Does it allow new classes? E.g. 7xx codes |
| 12:23 | <Hixie> | i'm just trying to learn about the various extension mechanisms |
| 12:23 | <jre> | Dashiva, no |
| 12:23 | <Hixie> | maybe what html5 says is rarer than i thought |
| 12:24 | <Hixie> | (does anything actually require that extension-codes be registered before they are used?) |
| 12:24 | <jre> | not in RFC 2616, the status code registry was introduced later |
| 12:24 | <Hixie> | so what does 199 mean if it's not in the registry? |
| 12:25 | <jre> | http://greenbytes.de/tech/webdav/rfc2817.html#rfc.section.7.1 |
| 12:25 | <jre> | it means the same thing as 100 for recipients that don't understand it |
| 12:25 | <jre> | so a definition of 199 would need to be consistent with the generic status code 100 |
| 12:26 | <Hixie> | but no definition need exist before i start using it? |
| 12:26 | <Hixie> | per http? |
| 12:26 | <Lachy> | Leif's response seems confusing. She seems to be suggesting that putting extensions through the W3C process is good, while at the same time advocating methods for arbitrary extensions that bypass that. |
| 12:26 | <jre> | RFC 2817 updates RFC 2616 and requires you to register the code |
| 12:27 | <Hixie> | oh so the lack of requiring a registry was a bug? |
| 12:27 | <jre> | if you don't register you are on your own with respect to collisions, nothing new here |
| 12:27 | <Hixie> | (where does 2817 actually require that the codes be registered? i can't see that anywhere) |
| 12:28 | <jre> | there are extension points that don't even have a registry today, simply because nobody has asked for it yet |
| 12:28 | <jre> | I think range extensions fall into the category |
| 12:28 | <Hixie> | seems weird to have extension points that allow arbitrary values without needing them to be defined |
| 12:28 | <jre> | you can always write a standards track RFC which updates RFC 2616, and then you're safe (as long as the IESG pays attention) |
| 12:48 | <Lachy> | damn, these constant splits are annoying |
| 12:49 | <Lachy> | according to discussion in #freenode, it still seems to be a DDoS against the network |
| 12:49 | <Dashiva> | Isn't it always? |
| 12:51 | <Philip`> | Maybe it's sometimes a CDoS instead |
| 12:51 | <Lachy> | yeah, but this one is particularly bad against the freenode network cause their system hasn't been updated to prevent it yet. It's caused by some javascript in a web page that sends a POST to the irc.freenode.net:6667 network with dozens IRC commands designed to flood it |
| 12:52 | <Lachy> | so whenever anyone inadvertently visits the page, usually linked to by spam comments on slashdot or whatever, their browser basically becomes an IRC spam bot |
| 12:52 | <Philip`> | Why does an IRC server react to HTTP requests? |
| 12:52 | <Lachy> | it's what most likely caused Opera's Oslo office to be banned from the freenode network yesterday |
| 12:54 | <Philip`> | Opera employees spend all their time reading spam comments on Slashdot instead of working? |
| 12:54 | <hsivonen> | Lachy: what mechanism allows automated POST to port 6667 for a different origin? |
| 12:54 | <hsivonen> | Lachy: form.submit()? |
| 12:55 | <jgraham> | hsivonen: Tyhat should work |
| 12:55 | <jgraham> | *that |
| 12:55 | <Lachy> | hsivonen, yes. The script I was shown yesterday has now disappeared and I don't know where any other copies are being hosted. |
| 12:55 | <hsivonen> | does the Web depend on it working for ports other than the http and https defaults? |
| 12:56 | <Lachy> | it was basically <form action="http://irc.freenode.net:6667"; method="POST"> with a script that filled up a textarea with about a hundred IRC PRVMSG commands commands and submitted it |
| 12:57 | <Lachy> | er, I think that's PRIVMSG |
| 13:00 | <Philip`> | hsivonen: Yes |
| 13:00 | <Philip`> | http://samsung-sgh-i400-software.epocware.com/es/SlovoEd/Hebrew.html - <form name="login" action="http://g500.penreader.com:8080/paragon_mcd/ecare/index.jsp?submit"; method="post"> |
| 13:01 | <Philip`> | etc, assuming that's what you mean |
| 13:02 | <hsivonen> | Philip`: :-( |
| 13:03 | <Philip`> | Seems it'd be quite a violation of layering if HTML refused to accept URLs with certain TCP port numbers |
| 14:37 | <Philip`> | Is it intentional that the discussion about "drawfocus()" seems to be talking about something quite different to the spec's drawFocusRing()? |
| 14:38 | <Philip`> | since the latter is meant to be something you call for every element that you draw, regardless of whether it's focused or not, and it will only draw if the element is focused |
| 14:38 | <Philip`> | but people seem to be talking about some kind of method that you only call on focused elements, or on elements that you want to become focused |
| 14:39 | <hsivonen> | Philip`: point worth making on the list! |
| 14:40 | Philip` | didn't even realise the spec had a drawFocusRing method, until half an hour ago |
| 14:42 | hsivonen | didn't realize that a method named drawfoo wouldn't draw |
| 14:49 | <hsivonen> | if braille and tactile are distinct and speech and audio are distinct, should (fontified) text and image be distinct media? |
| 19:33 | <Pure> | Hmm, do we have a generic web design channel?# |
| 19:37 | <FireFly> | I think there's a #web |
| 19:45 | <Pure> | OOI, is html5 more of an upgrade to js, than to core html? |
| 19:46 | <Philip`> | It does both - there's lots of new/fixed stuff in the markup, and lots of new script APIs too |
| 19:46 | <Philip`> | (It doesn't change the JS language, though - that's for the ES5 people to do) |
| 20:30 | <rittyan> | hello, who can I ask about documentation of python module html5lib? it is not available on google code hosting |
| 20:41 | <rittyan> | specifically, why it returns <None> all the time, whatever html I feed into it |
| 20:50 | <rittyan> | ah, its repr is <None> for some reason |
| 20:54 | <Philip`> | rittyan: What treebuilder are you using? |
| 20:54 | <Philip`> | If it's something like lxml, I guess it's implemented as a native object and can't be repred |
| 20:54 | <rittyan> | simpletree, now switched to beatifulsoup, works fine |
| 20:55 | <Philip`> | BeautifulSoup is a bit broken and unrecommended |
| 20:55 | <rittyan> | what is recommended then? i have no legacy code yet |
| 20:56 | <Philip`> | lxml works best, as far as I'm aware |
| 20:56 | <rittyan> | hm, okay |
| 21:12 | <jgraham> | rittyan: Oh the <None> thing doesn't mean anything went wrong, it's just a relly bad representation for the document root node |
| 21:13 | <jgraham> | (but in general I would recommend not using simpletree for anything important) |
| 21:13 | <rittyan> | yes, weird repr |
| 21:13 | <rittyan> | jgraham: so, lxml? |
| 21:13 | <jgraham> | rittyan: That is what I typically use |
| 21:14 | <jgraham> | (so it is the bet tested, but also the most complex for various technical reasons) |
| 21:14 | <jgraham> | *best |
| 22:14 | <dimich> | The dataTransfer being 'Empty' on dragenter and dragover is a security feature. It doesn't even expose the set of mime types of dragged files. How can a page decide whether or not it can accept the drop? Is exposing of mime type a risk? |
| 22:41 | <Lachy> | Philip`, focus rings are not always ugly. |
| 22:42 | <Lachy> | Maybe on Linux and Windows they are. But on OS X, normal focus rings are actually quite well designed and look quite nice |
| 22:49 | <Philip`> | Lachy: OS-provided stylings are unlikely to fit well with all the random stylings people will use in their canvases, and the inconsistency will make it ugly (even if it'd look nice with the standard OS widget set and theme) |
| 22:51 | <Lachy> | if it's so bad, then authors can draw custom focus rings. |
| 22:53 | <Lachy> | Hixie, re: using HTTP URLs for Microdata itemtype, does it have to be a URL at all? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024770.html |
| 22:55 | <Lachy> | The problem I have with using URLs for this, and for namespaces in general, is that formats will most likely out-last the organisation that created them and assigned the namespace or itemtype URL |
| 23:06 | <virtuelv> | WTF is a focus ring in a web context |
| 23:06 | <virtuelv> | to me a focus ring is something on a camera lens |
| 23:06 | <gavin> | it's the dotted border thing that lets you know what you've tabbed to |
| 23:07 | <Philip`> | It's a ring around something that's focused, as far as I'm aware |
| 23:07 | <gavin> | (blue glow on mac) |
| 23:07 | Philip` | imagines it looking more like the thick blue border in Opera when you shift+arrow onto things, or the thick yellow one in Flash when you tab |
| 23:07 | <virtuelv> | focus outline |
| 23:08 | <virtuelv> | or focus highlight |
| 23:09 | <virtuelv> | somewhere we use the term spatnav highlight in Opera |
| 23:09 | <virtuelv> | (that's for shift-arrow) |
| 23:09 | <virtuelv> | either way, focus ring seems wrong |
| 23:12 | <Philip`> | https://wiki.mozilla.org/Firefox/Projects/Focus_Ring_Cleanup says focus ring so it doesn't seem an entirely novel term |
| 23:12 | <jgraham> | virtuelv: I think it is pretty normal |
| 23:12 | <jgraham> | I wish you could twist them to bring other parts of the screen into and out of focus though |
| 23:12 | <jgraham> | That would be cool :) |
| 23:12 | Philip` | kind of prefers it when his whole screen is in focus |
| 23:13 | <Philip`> | There's no point reproducing physical bugs like blurring into computers |
| 23:14 | <jgraham> | Well it would be more useful than half the effects that actually come with compiz |
| 23:14 | <jgraham> | You could use it to make non-focused areas less distracting |
| 23:14 | Philip` | only has one of those effects enabled |
| 23:15 | jgraham | should probably give up trying to justify such a clearly useless idea |
| 23:15 | <Philip`> | (the zooming one) |
| 23:15 | <Philip`> | and I almost never use it, and most of the time I can't use it anyway because OpenGL breaks after I suspend and resume |
| 23:15 | <jgraham> | You only have one of the effects enabled or you only have one thing enabled, total? |
| 23:16 | <jgraham> | (I mean presumably you must have other parts of compiz enabled for window management, right?) |
| 23:16 | <Philip`> | It's actually the KDE desktop effects thingy rather than Compiz |
| 23:16 | jgraham | likes the expose-like thing which is confusingly not the one with the expose-like name |
| 23:16 | <Philip`> | and I'm not sure how they relate, though they seem kind of similar |
| 23:17 | <jgraham> | Oh |
| 23:17 | jgraham | has no idea about KDE :) |
| 23:18 | <jgraham> | (although gnome's default compiz UI is rather useless so I have to install the hideously complicated UI instead, which makes me sad) |
| 23:19 | <virtuelv> | on that note, I just read an open letter to leica |
| 23:19 | <virtuelv> | it was long |
| 23:19 | <virtuelv> | and basically told leica to stop sucking and join this millenium |