| 00:13 | <yuhong> | AFAIK "DOM0" as most commonly used refers most closely to what was implemented in Netscape 3.0. |
| 00:16 | <yuhong> | in late 1996 |
| 00:16 | <yuhong> | document.images, document.anchors, etc... |
| 00:18 | <yuhong> | After that, Netscape and IE went off in different directions (document.all, document.layers) leading the W3C to create DOM level 1. |
| 09:20 | <annevk> | wow, encodeURI deals with surrogates, sweet |
| 09:38 | <zcorpan> | Hixie: yeah, i expect in-band tracks might need some tweaks when someone gets around to implement that |
| 09:39 | <annevk> | would it make sense to have <input type=number suffix="%"> or <input type=number prefix="$"> |
| 09:39 | <annevk> | ? |
| 09:40 | <zcorpan> | Hixie: about tracks without a media parent, there are already several checks in place that trigger loading; src URL changes, mode changes. why is it hard to also check the parent? |
| 09:40 | <zcorpan> | annevk: what's wrong with $<input> ? |
| 09:41 | <annevk> | zcorpan: ugly |
| 09:41 | <annevk> | e.g. if you have up and down buttons and %, you don't want % to render after those buttons |
| 09:41 | <annevk> | and it's kinda part of the content, without it the input does not make sense |
| 09:43 | <zcorpan> | i guess that makes sense |
| 09:44 | <zcorpan> | Hixie: it does not seem necessary to kill a <track> when it loses its media parent, though i haven't thought about that case much |
| 09:49 | <annevk> | bah, why is tokenizing authority so annoying |
| 09:55 | <annevk> | I guess authority is an appropriate name, it does not like to be broken down |
| 09:55 | <annevk> | at least not in a single pass |
| 14:35 | mpt | is surprised to discover that <input list> doesn't look like a combo box in either Gecko or WebKit |
| 14:36 | <mpt> | ... Just a text field that shows a menu if you happen to know that you're supposed to double-click on it |
| 14:45 | <annevk> | mpt: yeah, that's kinda broken |
| 14:45 | <annevk> | same in Opera iirc :/ |
| 15:36 | <dglazkov> | good morning, Whatwg! |
| 18:14 | <Hixie> | i like how the htmlwg changed the language code of the spec, without actually changing what language the spec uses :-) |
| 18:37 | <Stevef_> | hixie: the lang code hasn't been changed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18816 |
| 18:38 | <Stevef_> | they rejected my suggestion <html lang="en-US-x-hober-ginger-erika-travis"> |
| 18:43 | <Hixie> | Stevef_: as they should, there's no spec for that code |
| 19:00 | <Hixie> | Stevef_: (but for what it's worth, i was actually talking about https://github.com/w3c/html/commit/04cee206fd88d2d8f938b31e92b19fc91d356eb7) |
| 19:07 | <Stevef_> | hixie: righto |
| 19:25 | <annevk> | Hixie: as you long as you keep that x- in there no specification is required I think |
| 20:12 | <annevk> | http://lists.w3.org/Archives/Public/www-archive/2012Sep/0004.html backdoor lobbying appears to work in the HTML WG |
| 20:12 | <annevk> | what the hell |
| 20:13 | <annevk> | backroom* |
| 20:18 | <TabAtkins> | I was about to say, I didn't think Sam was quite that, um, liberated. |
| 20:23 | <annevk> | TabAtkins: haha |
| 21:03 | <Hixie> | annevk: oh i know, but i'm saying what does that language even mean? At least en-us-x-hixie has a spec. |
| 21:04 | <jgraham> | en-us doesn't have a spec |
| 21:05 | <Hixie> | yeah but it has lots of documentation |
| 21:05 | <jgraham> | and I strongly doubt the x-hixie consistently conforms to its purported spec |
| 21:05 | <Hixie> | if you find any mistakes i can fix them :-) |
| 21:05 | <Hixie> | which is more than we could say for the other one |
| 21:05 | <Hixie> | which is my point :-) |
| 21:06 | <jgraham> | Hixie: en-us haslots of conflicting documentation :) |
| 21:07 | <jgraham> | (and because it is vaugely on-topic: http://stroppyeditor.wordpress.com/2012/09/04/the-very-model-of-an-amateur-grammarian/ ) |
| 21:08 | <TabAtkins> | Hm. Which WG should I be talking in about embedding HTML directly into SVG, without an intervening <foreignContent> and namespace crap? |
| 21:09 | <TabAtkins> | I mean, there's some CSS work, but I'm on top of that. |
| 21:09 | <Hixie> | TabAtkins: i wouldn't talk about it anywhere :-P |
| 21:09 | <TabAtkins> | Too bad, it's gonna happen. |
| 21:10 | <TabAtkins> | Apparently SVG directly in HTML is a non-starter still, but the other way around is fine. |
| 21:13 | <smaug____> | TabAtkins: why do you want to embed html directly into svg? |
| 21:14 | <TabAtkins> | So I can put <span> or <p> inside of SVG, without reinventing HTML in SVG elements? |
| 21:14 | <TabAtkins> | If you've never tried to write SVG by hand, dealing with text is THE WORST THING EVER. |
| 21:14 | <TabAtkins> | You want a box filled with text? Congrats, you get to guess how large the text will be and make a completely independent rectangle positioned behind it. |
| 21:15 | <TabAtkins> | Linebreaking? SURELY YOU JEST, SIR. |
| 21:16 | <smaug____> | TabAtkins: oh, you want to *fix* svg :) |
| 21:17 | <TabAtkins> | Also, shit like <video> and <audio> without going the Tiny1.2 route and having magical unique elements that are different-but-the-same as HTML. |
| 21:17 | <TabAtkins> | smaug____: Fixing from the inside, sure. |
| 21:17 | <TabAtkins> | The end goal is making SVG entirely a part of HTML, but *some* people have a bizarre attachment to namespaces that is making that difficult. |
| 21:32 | <TabAtkins> | The fun part is that SVG is totally cool with merging entirely into HTML, but there's pushback on the HTML side of the "they made their bed, now they have to lie in it" variety. :/ |
| 21:32 | <gavinc> | bah, those people suck |
| 21:44 | <annevk> | TabAtkins: seems mostly a CSS/SVG problem |
| 21:44 | <annevk> | TabAtkins: unless you want to change HTML parsing too... in which case WHATWG |
| 21:46 | <Hixie> | TabAtkins: my reasoning is "svg is not a media-independent language and it makes no sense to merge them" |
| 21:47 | <WeirdAl> | I'd argue against it myself: HTML and SVG are two honkin' huge specs |
| 21:47 | <WeirdAl> | </gallery> |
| 21:51 | <gavinc> | Hixie: canvas is media independent? |
| 22:16 | <Hixie> | gavinc: you can't put HTML in canvas either |
| 22:17 | <Hixie> | gavinc: i don't have a problem with embedding media-specific components in HTML, e.g. <img>, <canvas>, or <svg>. What I'm arguing is that they shouldn't be merged, as in, you're in the middle of SVG and you just randomly break out into HTML, then back into SVG, etc. |
| 22:17 | <Hixie> | gavinc: (plus, <canvas> and <img> require that the author provide non-graphical alternatives) |
| 22:18 | <zewt> | (for a fake, handwaving value of "require" :) |
| 22:25 | <jamesr> | Hixie, but having a <foreignContent> / <svg> boundary makes jumping in/out OK? what's the difference? |
| 22:28 | <Hixie> | jamesr: i don't think it makes it particularly ok, no |
| 22:28 | <Hixie> | jamesr: i think where svg would make sense is in something like web components |
| 22:29 | <Hixie> | (<foreignObject> makes sense in SVG proper because there you're not pretending to be using a media-neutral language, and so you can use HTML for its features while still being fully aware it's still media-specific) |
| 22:31 | <jamesr> | i see, so you just think <svg> doesn't make sense in HTML |
| 22:32 | <Hixie> | no, i think HTML doesn't make sense inside SVG inside HTML |
| 22:32 | <Hixie> | SVG in HTML makes sense just like PNG in HTML makes sense |
| 22:32 | <Hixie> | or <audio> in HTML makes sense |
| 22:32 | <Hixie> | sometimes you have some media-specific content to place in a media-neutral discussion |
| 22:33 | <Hixie> | this is similar to how it makes sense to have a PDF in an <iframe>, but not <font> in a <p> |
| 22:33 | <jamesr_> | so what's wrong with that media-specific content embedding media-neutral content? |
| 22:33 | <TabAtkins> | Hixie: In my railroad diagrams http://www.xanthir.com/etc/railroad-diagrams/example.html I need to do a *stupid* "guess at metrics and hope" or else "manually measure text" just to get a styled box. Including a simple <span> in SVG would solve those problems. |
| 22:34 | <Hixie> | TabAtkins: the "right" solution is IMHO to have SVG have something like flexbox but for graphics |
| 22:34 | <TabAtkins> | SVG could add its own primitives that do the same thing, but that's just duplication of the same nasty variety that led to SVG's <script> and <style>, not to mention Tiny's <audio> and <video>. |
| 22:34 | <TabAtkins> | No, the right solution is to *use the technology we have in front of us instead of inventing something new for no reason*. |
| 22:35 | <Hixie> | maybe i'm misunderstanding why you are measuring text |
| 22:35 | <TabAtkins> | So I can make it look like it's inside of a box. |
| 22:35 | <Hixie> | if you just want a box to size to its contents and for all graphics that point to that box to adjust accordingly, HTML ain't gonna help you. |
| 22:35 | <TabAtkins> | That's a <text> and an *independent* <rect> element, positioned so that it looks like one is inside the other. |
| 22:35 | <gavinc> | TabAtkins: ... that page is supposed to not work right? |
| 22:36 | <TabAtkins> | Um, whoops. |
| 22:36 | <TabAtkins> | gavinc: I, um, messed it up. One sec. |
| 22:36 | <Hixie> | TabAtkins: i don't see what that has to do with HTML |
| 22:36 | <gavinc> | TabAtkins: Ah! Thanks :D |
| 22:36 | <Hixie> | jamesr: my problem is with people who write pages intended for the web that only work on one medium, when they should be able to work on any medium. |
| 22:36 | <TabAtkins> | gavinc: Fixed. |
| 22:37 | <TabAtkins> | Hixie: I think you're not understanding me quite right, and assume I'm asking for soemthing weird. I'll start small. |
| 22:37 | <TabAtkins> | So, see those boxes of text. They are *not* boxes of text, because SVG doesn't handle text well. Instead, they're a <rect> and a <text> element, independent siblings, which are positioned on top of each other such that they *look* like a box full of text. |
| 22:38 | <TabAtkins> | This is, obviously, stupid. The shortest path to a solution is to pull in HTML, so I can just put in a <span> and style it like normal CSS, with border and background. |
| 22:38 | <Hixie> | TabAtkins: yes |
| 22:38 | <Hixie> | TabAtkins: o_O |
| 22:38 | <Hixie> | TabAtkins: that seems like a non-sequitur to me |
| 22:38 | <Hixie> | TabAtkins: HTML doesn't have any elements with boxes |
| 22:38 | <TabAtkins> | ?_? |
| 22:39 | <Hixie> | TabAtkins: if you are saying you want the _CSS box model_ in SVG, then that's got nothing to do with HTML. |
| 22:39 | <Hixie> | TabAtkins: and that i would support |
| 22:39 | <TabAtkins> | Sure, theoretically. But <text> *does not work like span* (or <p> for that matter). Adding an <svg:span> or <svg:p> that *does* work correctly with the css 'inline' or 'block' model is just nasty, useless duplication. |
| 22:40 | <Hixie> | i have no idea what you mean by "work like span" |
| 22:40 | <TabAtkins> | I mean "work like an abspos display:inline element". |
| 22:40 | <TabAtkins> | <text> has its own crazy handling which can't be changed at this point. |
| 22:40 | <Hixie> | that's an entirely different, unrelated, and orthogonal statement. |
| 22:41 | <Hixie> | "span" is not "display:inline" |
| 22:41 | <Hixie> | they are literally orthogonal facets |
| 22:41 | <Hixie> | well not literally |
| 22:41 | <TabAtkins> | Dude, bro, I don't care. The point is, I want normal text in my SVG without having to add <svg:span> to the language. |
| 22:41 | <Hixie> | "span" is no more "display:inline" than "h1" is "loud volume" |
| 22:41 | <TabAtkins> | I also want <video>, etc, in the same way. |
| 22:42 | <Hixie> | i am entirely in favour of making it possible to use the CSS box model in SVG |
| 22:42 | <Hixie> | (by the way, that's what <foreignObject> does) |
| 22:42 | <TabAtkins> | Yes, but <foreignObject> is stupid and cumbersome. |
| 22:42 | <Hixie> | ? |
| 22:42 | <Hixie> | how so |
| 22:42 | <TabAtkins> | And fundamentally *does not work* for the kinds of things I want. |
| 22:42 | Hixie | files a preemptive ticket to get Tab a new asterisk key :-P |
| 22:43 | <TabAtkins> | For one, it's an extra long-named wrapper object. For two, I need to declare a namespace. For three, it needs a defined width and height. |
| 22:43 | <Hixie> | why do you need to declare a namespace |
| 22:43 | <Hixie> | <foreignObject> My Text </foreignObject> |
| 22:43 | <TabAtkins> | Because otherwise you're using elements in an arbitrary XML dialect, or maybe in just SVG, I dunno. |
| 22:44 | <Hixie> | oh wait, <foreignObject> it self isn't a positioned CSS box, is it |
| 22:44 | <TabAtkins> | That super doesn't work. There's nothing to hang the CSS box model off of there, and it still need a 'width' and 'height' attribute specified. |
| 22:44 | <TabAtkins> | Nope, it's an SVG box. |
| 22:44 | <Hixie> | ok so just get a new element that is a positioned CSS box or whatever |
| 22:44 | <Hixie> | <box> |
| 22:44 | <TabAtkins> | (All elements in SVG are forced into the SVG display model.) |
| 22:44 | <Hixie> | anyway this has no more to do with HTML than it does with MAthML |
| 22:44 | <TabAtkins> | So, then what? I have a <box>. What do I put in it? Just plain text? |
| 22:45 | <Hixie> | whatever you want, same as in CSS-styled raw XML |
| 22:45 | <TabAtkins> | That's a dumb solution. CSS-styled raw XML is cumbersome. |
| 22:45 | <TabAtkins> | Plus much less featureful. |
| 22:45 | <Hixie> | it's not a dumb solution |
| 22:45 | Hixie | returns to <track> |
| 22:46 | <TabAtkins> | I'm not sure how you can say "just use raw XML from an arbitrary language" is better than "use HTML". |
| 22:47 | <TabAtkins> | Where "use HTML" has things like "yay, free styling/accessibility for <em>! yay, <video>! yay, <details>! yay, everything else that HTML gives me for free, and that I'd have to reinvent manually in raw XML!" |
| 22:53 | <TabAtkins> | Anyway, back to the original question. |
| 22:53 | <TabAtkins> | annevk: You said WHATWG if I wanted to change HTML parsing. I shouldn't need to, I don't think... |
| 22:53 | TabAtkins | goes to check the parser. |
| 22:56 | <Hixie> | your use case was text with a box using the CSS inline box model, and didn't mention anything that would result in us even considering <video>, <details>, or <em>. If there are other use cases, then we should consider those as well. |
| 22:56 | <Hixie> | but so far I haven't seen any. |
| 22:56 | <Hixie> | (note that <video> in Tiny and <video> in HTML are quite different and have different use cases) |
| 22:56 | <TabAtkins> | Those other cases come along for the ride. :/ If I'm putting text in a diagram, *obviously* I sometimes want to emphasize parts of it. |
| 22:57 | <Hixie> | you want to emphasise it, or you want to italicise it? |
| 22:57 | <TabAtkins> | Both. |
| 22:57 | <Hixie> | can you elaborate on your use case for emphasis? |
| 22:57 | <TabAtkins> | The entire set of inline-type elements have useful semantics for text inside of diagrams. |
| 22:57 | <Hixie> | i don't understand how or why |
| 22:57 | <TabAtkins> | I don't understand how you dont' understand. :/ You have text. In a diagram. Some of that text may be emphatic. |
| 22:58 | <Hixie> | your use case seems circular :-) |
| 22:58 | <TabAtkins> | How so? |
| 22:58 | TabAtkins | doesn't understand. |
| 23:00 | <Hixie> | you want to be able to mark text as emphasised because you have text that is emphasised? |
| 23:00 | <TabAtkins> | ...yes? |
| 23:00 | <Hixie> | do you also want to be able to mark verbs? |
| 23:00 | <TabAtkins> | I'd like to be able to mark up text with the same set of semantics that HTML grants, because that set has proven useful over time. (Some of the set is just legacy, but including them doesn't harm anything.) |
| 23:01 | <TabAtkins> | This set of semantics is already mapped to presentation in other formats, like screen readers. |
| 23:01 | <TabAtkins> | It is the lingua franca of text semantics on the web. |
| 23:02 | <Hixie> | it has proven to be useful in particular because HTML can be rendered to multiple media, including in particular speech, braille, and visual media. This doesn't seem to apply when the use case is specifically for graphical diagrams. |
| 23:02 | <Hixie> | hence my asking you what the use case is |
| 23:02 | <zewt> | uh, no, "multiple media" has very very little to do with the wide use of html |
| 23:02 | <TabAtkins> | And that's incorrect. For example, an SVG diagram can be combined with a pointing device that reads out text at the given point, to help low-vision users. |
| 23:02 | <TabAtkins> | This already exists, I believe. |
| 23:02 | <Hixie> | zewt: the set being useful has very little to do with the wide use of HTML too |
| 23:03 | <TabAtkins> | Expanding the set of textual semantics usable in this situation is a win. |
| 23:03 | <Hixie> | TabAtkins: aha, a new use case |
| 23:03 | <zewt> | it's fine for you to consider it important, but don't pretend it's a bigger factor for its success than it is |
| 23:03 | <Hixie> | zewt: i don't believe i pretended anything was a success? |
| 23:03 | <Hixie> | zewt: not sure what you're arguing against :-) |
| 23:04 | <zewt> | you said that multiple media is a significant ("particular") reason for HTML having been proven useful; really, it's a tiny, tiny piece |
| 23:04 | <TabAtkins> | zewt: We're not talking about HTML's suitability in general, so it's not necessary to defend its honor in this instance. |
| 23:05 | <Hixie> | TabAtkins: you should describe the use cases somewhere, rather than start with the solution you prefer, because it's not clear to me that the solution you prefer is a logical result of the use cases you've presented so far, but i can't tell if that's because it's a bad solution or if the use cases are incomplete (or both). |
| 23:05 | <TabAtkins> | Since, on inspection, this *will* require minor parser changes of some kind, I'll make a post on WHATWG. |
| 23:05 | <zewt> | TabAtkins: i may be doing the opposite of defending its honor, since i'm saying HTML would be just-about as successful if it didn't support multiple media :) |
| 23:05 | <Hixie> | zewt: i'm specifically talking about the semantics of certain inline elements, most of which are vastly underused and are definitely not what i would call a "success", at least not on the level of HTML overall |
| 23:06 | <Hixie> | TabAtkins: please be sure to start (and possibly stop, if you can :-) ) with use cases, at least in your first post :-) |
| 23:06 | <TabAtkins> | (To somehow avoid the "when you see an HTML element, POP EVERYTHING until you get out of the SVG context.) |