| 00:28 | <MikeSmith> | hsivonen: bugzilla.validator.nu unresponsive |
| 00:28 | <MikeSmith> | or responding only very slowly |
| 00:29 | <MikeSmith> | "Remote DOM Community Group"? |
| 00:29 | <MikeSmith> | http://www.w3.org/community/blog/2013/06/09/proposed-group-remote-dom-community-group/ |
| 00:29 | <MikeSmith> | [[Similarly to how the Shadow DOM paved the way for custom elements using web technologies, a “Remote DOM” could allow display of portions of the web app to be displayed on “remote” (i.e. “external”) devices, such as screens, Smart TVs, etc. |
| 02:16 | <MikeSmith> | help me out here |
| 02:17 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html#entity-copy-legacy |
| 02:17 | <MikeSmith> | that means the spec requires "©" (without the semicolon) to be displayed as U+000A9 (the copyright symbol), right? |
| 02:20 | <annevk> | MikeSmith: might depend on the context |
| 02:20 | <MikeSmith> | k |
| 02:21 | <annevk> | MikeSmith: actually, testing <body title=©>test©test that seems to be what it means |
| 02:22 | <MikeSmith> | annevk: yeah, and in stuff like href='http://example.org/demo?id=hello©=1&world=fun'; too |
| 02:23 | <MikeSmith> | anywhere actually |
| 02:23 | <MikeSmith> | regardless of the context, I think |
| 02:23 | <MikeSmith> | as far as the parser behavior goes |
| 02:25 | <annevk> | MikeSmith: so actually |
| 02:25 | <annevk> | MikeSmith: "If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned." |
| 02:26 | <annevk> | MikeSmith: so <body title=©s> has a title of "©s" |
| 02:26 | <annevk> | and not "©s" |
| 02:27 | <MikeSmith> | hmm OK |
| 02:27 | <MikeSmith> | I missed the part about the equals sign |
| 02:27 | <MikeSmith> | ah yeah, "alphanumeric ASCII character" too |
| 02:31 | <MikeSmith> | shit now I have to scribe |
| 02:54 | <annevk> | did you give the person asking a shit-bow? |
| 03:11 | <MikeSmith> | man I didn't do a good job of scribing that |
| 03:48 | <annevk> | Do we have anything else besides WebSocket with regards to streaming? |
| 03:48 | <annevk> | Oh doh, EventSource |
| 03:50 | <annevk> | http://wiki.whatwg.org/wiki/Streams ... |
| 05:28 | <JonathanNeal> | So, <hn> elements section content by nature, correct? |
| 07:06 | <SteveF> | JonathanNeal: yup |
| 08:04 | <hsivonen> | MikeSmith: seems to work now but slowly |
| 08:05 | <MikeSmith> | hsivonen: yeah very slowly |
| 08:14 | <hsivonen> | MikeSmith: it should now be better for a little while again |
| 08:15 | <hsivonen> | the validator process would benefit from running on Heroku-like infrastructure |
| 08:15 | <hsivonen> | but I don't want the DMCA exposure of hosting it in the U.S. |
| 08:16 | <hsivonen> | and European companies seem to be too incompetent to come up with something like Heroku |
| 08:16 | <Ms2ger> | It's already hosted on the NSA servers too |
| 08:16 | <MikeSmith> | hsivonen: thanks I just tried again and it's better and I'll take advantage of it to update a few bugs :-) |
| 08:16 | <hsivonen> | Ms2ger: I don't mean in terms of NSA exposure. I mean in terms of the public U.S. legal system. |
| 08:18 | <Ms2ger> | (Just joking about the NSA now, because everyone will have forgotten next month) |
| 08:26 | <hsivonen> | If I decided to pay for a separate bugzilla server, what guide should I follow to set up bugzilla in such a way that getting security updates works? |
| 08:29 | <hsivonen> | oh. awesome. We don't seem to fire DOMContentLoaded for XSLT-generated docs |
| 08:29 | <hsivonen> | bug or feature? |
| 08:30 | <darobin> | I would assume that no one knows :) |
| 08:31 | <MikeSmith> | hsivonen: run Debian stable on the server you use for bugzilla? |
| 08:31 | <hsivonen> | my patch starts accidentally firing DOMFrameContentLoaded for the XSLT source docs |
| 08:31 | <hsivonen> | MikeSmith: do they backport patches? |
| 08:31 | <hsivonen> | MikeSmith: do I get an ancient Bugzilla? |
| 08:32 | <MikeSmith> | hsivonen: current Debian stable has version 4.2.5 I think |
| 08:32 | <hsivonen> | Gecko also has a bug when it comes to sizing the view port for an XSLT-generated doc in an iframe |
| 08:32 | <Ms2ger`> | Yay, XSLT |
| 08:33 | <hsivonen> | my problem: I don't forget to test XSLT |
| 08:33 | <Ms2ger`> | No good deed goes unpunished |
| 08:33 | <MikeSmith> | hsivonen: I don't know how Debian handles patches but I think stable gets regular security-patch updates |
| 08:33 | <darobin> | wait, you mean you've made it so that the xml-stylesheet PI fires DOMFrameContentLoaded? |
| 08:34 | <darobin> | somehow I find that very funny |
| 08:34 | <darobin> | not entirely sure why |
| 08:35 | <Ms2ger`> | darobin, you're French, and drunk? I dunno |
| 08:35 | <jgraham> | darobin: Not enough coffee? Too much coffee? |
| 08:35 | <darobin> | I opt for jgraham's explanation |
| 08:36 | <darobin> | maybe the last shreds of sanity I had has finally evaporated |
| 08:37 | <hsivonen> | So since we have a pre-existing bug about XSLT not filing DOMContentLoaded, I think I'll take the EME approach and declare that fixing that bug is out of scope of the fix for the bug I'm trying to fix |
| 08:39 | <darobin> | when would XSLT fire DCL anyway? before or after transformation? (given that new resources are likely involved) |
| 08:41 | <jgraham> | I would assume after |
| 08:41 | <jgraham> | OTOH, as we previously discussed, Gecko's XSLT suffers from trying to do things too well |
| 08:41 | <hsivonen> | darobin: after |
| 08:45 | <zcorpan> | https://github.com/Masterminds/html5-php "This project initially began with the seemingly abandoned html5lib project original source. But after some initial refactoring work, we began a new parser." |
| 08:46 | <zcorpan> | hsivonen: have you opened a bug yet about abandoning the xslt code path (i.e. doing the wrong thing)? |
| 08:47 | <jgraham> | "The Tokenizer requests data off of the scanner, parses it, clasifies it, and sends it to an EventHandler. It is a recursive descent parser." |
| 08:47 | <jgraham> | I don't understand |
| 08:48 | <hsivonen> | zcorpan: I haven't |
| 08:49 | <zcorpan> | hsivonen: are you going to? :-) |
| 08:55 | <zcorpan> | "Processor Instructions: The HTML5 spec does not allow processor instructions. We do. Since this is a server-side library, we think this is useful." |
| 08:55 | <hsivonen> | zcorpan: not sure. I was planning on fixing XSLT as part of the planned but always deferred XML rewrite project |
| 08:56 | <Ms2ger`> | Processor, eh |
| 08:56 | <hsivonen> | Ms2ger`: HTML5 bans your processor from running instructions |
| 08:57 | <jgraham> | Unless Hollywood allow it |
| 09:06 | <zcorpan> | MikeSmith: i think href="©=" is an error currently. "However, if this next character is in fact a U+003D EQUALS SIGN character (=), then this is a parse error, because some legacy user agents will misinterpret the markup in those cases." |
| 09:06 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/#tokenizing-character-references |
| 09:06 | <hendry> | anyone good with legalese? Just trying to write a phrase where I try explain: if you use my company's services without paying, we reserve the right to persue you for payment. |
| 09:07 | <MikeSmith> | zcorpan: oh |
| 09:08 | <zcorpan> | also, i don't have a strong opinion on the document conformance around ampersands. i have had strong opinions about how they should be parsed, though :-) |
| 09:09 | <zcorpan> | http://html5.org/r/7679 is the change |
| 09:11 | zcorpan | commented in the bug |
| 09:15 | <hendry> | oh crap, wrong channel |
| 09:21 | <marcdm> | Hello sleeping people and those that are awake. i'm seeking some answers regarding the new API for html5lib-python can anyone help? |
| 09:22 | <jgraham> | Sure |
| 09:22 | <marcdm> | thanks jgraham. |
| 09:22 | <marcdm> | I'm seeking to modify bleach for my own purposes, but I can't seem to understand one or 2 little things about the new API.... |
| 09:23 | <marcdm> | 1. how would I access Element.type and ... |
| 09:23 | <MikeSmith> | zcorpan: thanks fur the big comment |
| 09:24 | <jgraham> | marcdm: Which "API" do you mean? The one for the tree of elements that you get after parsing? Or something else? |
| 09:24 | <marcdm> | yes jgraham |
| 09:24 | <marcdm> | 2. If I want to modify the tree, say I want to make changes to the list I get from .get_children(), which docs should I read for how i can make a new tree or modify it inplace |
| 09:25 | <zcorpan> | hmm, seems i messed up with the anolis .tail fix |
| 09:25 | <zcorpan> | File "build/bdist.macosx-10.8-intel/egg/anolislib/processes/filter.py", line 32, in filter |
| 09:25 | <zcorpan> | TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType' |
| 09:25 | <marcdm> | the real problem is that in bleach they do an in-place modification using a while loop through tree.childNodes |
| 09:25 | <jgraham> | Right, so now html5lib itself doesn't actually have any built-in tree representation. It just outputs a tree in an existing format |
| 09:26 | <jgraham> | Before it had this built-in "simpletree" thing, that wasn't really supposed to be production-quality |
| 09:26 | <marcdm> | so I'm really just at the mercy of what I can get from ElementTree |
| 09:26 | <jgraham> | So the new default is to use ElementTree |
| 09:26 | <jgraham> | Which is in the stdlib |
| 09:27 | <marcdm> | ah, and the bleach guys implemented their algorithm using the simpletree API |
| 09:27 | <jgraham> | Yes, I think they did |
| 09:27 | <marcdm> | uphill task. changing into 2nd gear. |
| 09:28 | <jgraham> | So, if I understand the situation with bleach right, they need to rework their use of html5lib to use ElementTree |
| 09:28 | <marcdm> | and I think the easiest thing might be to implement a fake simpletree over elementTree to provide those attributes they want |
| 09:28 | <jgraham> | That might be simple, but it doesn't sound like a great fix. |
| 09:29 | <marcdm> | totally agreed. |
| 09:29 | <marcdm> | I'm looking at the faulty code now, wanting to run it in Py3.2 on Wheezy |
| 09:29 | <jgraham> | I haven't looked closely at bleach, but I wouldn't have thought it was hard to make it work with ElementTree |
| 09:30 | <marcdm> | well, since I didn't quite understand how html5lib works, I wasn't quite sure what to expect from the code. |
| 09:32 | <jgraham> | So it looks like it's just linkify that needs to be updated? |
| 09:32 | <marcdm> | jgraham, just to confirm, parser.parseFragment(text) produces a regular ElementTree.Element right? |
| 09:32 | <marcdm> | yup. |
| 09:32 | <jgraham> | I think it can return a list of elements |
| 09:32 | <marcdm> | more specifically, linkify_nodes within linkify |
| 09:33 | <jgraham> | For cases like "<div>foo</div><div>bar</div>" |
| 09:33 | <jgraham> | But that is very much from memory |
| 09:33 | <marcdm> | huh? |
| 09:34 | <marcdm> | the tree is passed in and modified in-place... heading to the etree docs |
| 09:35 | <jgraham> | Oh |
| 09:35 | <jgraham> | Not a list, a custom element type |
| 09:35 | <jgraham> | In [1]: import html5lib |
| 09:35 | <jgraham> | In [2]: p = html5lib.HTMLParser() |
| 09:35 | <jgraham> | In [3]: p.parseFragment("<div>foo</div><div>bar</div>") |
| 09:35 | <jgraham> | Out[3]: <Element u'DOCUMENT_FRAGMENT' at 0x371c300> |
| 09:35 | <marcdm> | yup |
| 09:36 | <marcdm> | when I try to getchildren on that, which is what linkify_nodes wants to do, I get the 1st div tho |
| 09:36 | <marcdm> | I mean I get the divs |
| 09:36 | <zcorpan> | how do i sync my anolis fork? |
| 09:37 | <jgraham> | yeah, just doing list(p.parseFragment("<div>foo</div><div>bar</div>")) works |
| 09:37 | <marcdm> | (facepalm) |
| 09:37 | <zcorpan> | Ms2ger`: ^ |
| 09:37 | zcorpan | switching trains |
| 09:38 | <Ms2ger`> | hg pull -u https://zcorpan⊙bo/ms2ger/anolis && hg push https://zcorpan⊙bo/zcorpan/anolis I guess |
| 09:38 | <marcdm> | try this (p.parseFragment("http://foo.co and <div>bar</div> you⊙mu") |
| 09:39 | <marcdm> | syntax corrections where necessary |
| 09:40 | <jgraham> | Yeah, that is going to be harder I guess |
| 09:42 | <marcdm> | tree.text gives me the text before the div, but I haven't gotten at the text after the div yet |
| 09:42 | <jgraham> | It is the .tail of the last element |
| 09:43 | <marcdm> | so I'd want t a list containing the .text of the parent, the children and the .tail of each child? |
| 09:44 | <marcdm> | heading to look at simpletree code |
| 09:44 | <marcdm> | .itertext? |
| 09:45 | <jgraham> | Iterates over all the text in a subtree |
| 09:46 | <jgraham> | Which might not be enough for you, since you also need to know what the parent element was |
| 09:46 | <marcdm> | well, the bleach code wraps all things in a div (I think), so we can control the parent that way |
| 09:47 | <jgraham> | Right, but I mean if you have <div>foo <span>bar <i>http://example.com</i></span>; baz</div>, you need to know that the link should be a child of the <i> |
| 09:48 | <marcdm> | if I remember right, BeautifuSoup gives us some kind of "node" iterator that treats bits of text as TextNodes.... I need something like that |
| 09:48 | <marcdm> | yeah, I know what you mean, I realized it wasn't a complete solution |
| 09:56 | <zcorpan> | Ms2ger`: thanks. new pr coming up |
| 09:57 | <Ms2ger`> | Np |
| 09:58 | <zcorpan> | https://bitbucket.org/ms2ger/anolis/pull-request/9/turns-out-none-none-throws/diff |
| 10:00 | <Ms2ger> | zcorpan, thanks |
| 10:00 | Ms2ger | kicks .tail |
| 10:00 | <zcorpan> | yeah, seriously. it shouldn't be this hard to remove an element |
| 10:02 | <Ms2ger> | I kinda liked simpletree ;) |
| 10:07 | <marcdm> | simpletree was nice for what we're trying to do here, _read_ html. etree is awesome when you trying to write x/html |
| 10:22 | <marcdm> | I think I sufficiently understand etree api to reimplement the faulty parts of bleach. thanks for your help jgraham |
| 10:27 | <zcorpan> | hmm. --w3c-compat turns on lots of xref elements. but turning it off takes away features like [STATUS], <!--logo-->, etc. maybe we should just trim the list of xref elements for w3c mode as well |
| 10:31 | <Ms2ger> | --w3c-compat-substitutions? |
| 10:35 | <zcorpan> | ah, that seems to do what i want |
| 10:43 | <hsivonen> | :-( MDN says the load event is defined by DOM Level 3 |
| 10:43 | <hsivonen> | it's a wiki, I know |
| 10:47 | <Ms2ger> | Yeah, they aren't terribly up to date |
| 10:54 | <marcdm> | I have a fairly blonde question, does html5lib-python always return {http://www.w3.org/1999/xhtml} as the namespace for html files? |
| 10:55 | <marcdm> | when using etree |
| 10:56 | <SimonSapin> | marcdm: yes, for HTML elements. For SVG elements you will get the SVG namespace, etc. This is per the spec |
| 10:56 | <marcdm> | what about the newer html elements like aside, section, audio and video? |
| 10:57 | <zcorpan> | why does anolis when not in --w3c-compat mode turn <code> into <a><code> but in --w3c-compat mode <code><a>? |
| 10:57 | <SimonSapin> | I think there is a list of special cases like SVG and MathML that change the namespace, but everything else defaults to the XHTML namespace. |
| 10:57 | <zcorpan> | the former gives blue underlines :-( |
| 10:58 | <zcorpan> | which isn't fixable with css afaict |
| 10:58 | <marcdm> | SimonSapin: thanks. |
| 11:18 | <hsivonen> | looking forward to UTF-16-encoded XSLT |
| 11:20 | <Ms2ger> | zcorpan, there's an option for that :) |
| 11:21 | <Ms2ger> | --w3c-compat-xref-a-placement |
| 11:21 | <zcorpan> | Ms2ger: yeah, i noticed. but what's the point? |
| 11:21 | <Ms2ger> | 301 gsnedders |
| 11:33 | <hsivonen> | Ms2ger: what's the current thinking on exposing an interface object on the global object when speccing a new WebIDL interface? |
| 11:34 | <Ms2ger> | In general, just expose it |
| 11:35 | <hsivonen> | Ms2ger: what's the mechanism in our code that makes an interface exposed? |
| 11:36 | <Ms2ger> | Somewhere in classinfo, I think. There's a few ways to get exposed |
| 11:36 | <Ms2ger> | * webidl interface without [NoInterfaceObject] |
| 11:36 | <Ms2ger> | * XPIDL interface that starts with nsIDOM |
| 11:36 | <Ms2ger> | * XPIDL interface that starts with nsI and has classinfo for some reason |
| 11:37 | <hsivonen> | thanks |
| 11:37 | <Ms2ger> | I *think* that's all of them |
| 11:37 | <hsivonen> | I have been tasked with zapping interface objects that shouldn't be exposed |
| 11:38 | <Ms2ger> | The fun part is that a lot of the b2g stuff uses xpidl + classinfo |
| 11:38 | <hsivonen> | looks like most items I need to zap are XUL or B2G |
| 11:39 | <hsivonen> | yay B2G for moz prefix proliferation |
| 11:39 | <Ms2ger> | Yeah, they want to ship :/ |
| 11:39 | <zcorpan> | presto mostly had the opposite problem, we didn't expose enough |
| 11:40 | <hsivonen> | Ms2ger: they could ship without prefixes... |
| 11:40 | <hsivonen> | I guess my next step is taking the list from http://hg.mozilla.org/mozilla-central/annotate/tip/dom/tests/mochitest/general/test_interfaces.html and checking it against Blink, WebKit, Presto and Trident |
| 11:43 | <Ms2ger> | Note that it doesn't actually fail if there's interfaces in there that aren't exposed |
| 11:44 | <Ms2ger> | Say, if you forget to remove MozBlobBuilder |
| 11:55 | <hsivonen> | clearly, for a DOM peer, I know quite little about the DOM |
| 11:55 | <Ms2ger> | You know about XSLT ;) |
| 11:55 | <hsivonen> | why doesn't for (var name in window) {...} not show any interface objects? |
| 11:56 | <hsivonen> | s/not// |
| 11:57 | <Ms2ger> | w(Object.getOwnPropertyDescriptor(window, "XMLHttpRequest").enumerable) |
| 11:57 | <Ms2ger> | log: false |
| 11:58 | <hsivonen> | Ms2ger: I suspected there was a concept like that |
| 11:58 | <hsivonen> | but of course it's useful that personalbar is enumerable, for instance |
| 11:58 | <Ms2ger> | These BarProps are lovely |
| 12:00 | <Ms2ger> | Maybe you want Object.getOwnPropertyNames(window) |
| 12:04 | <hsivonen> | Ms2ger: indeed, the test case lists a number of names that aren't actually exposed on window |
| 12:04 | <hsivonen> | in the sense that (foo in window) would be true |
| 12:05 | <Ms2ger> | Any others than HTMLCommandElement and MozBlobBuilder? |
| 12:06 | <hsivonen> | SVGStylable, SVGTransformable, MozMobileCellInfo, etc. |
| 12:06 | <hsivonen> | many others |
| 12:07 | <Ms2ger> | Mm |
| 12:14 | <hsivonen> | Ms2ger: awesome. there are also interfaces that aren't exposed but aren't listed in the test case |
| 12:14 | hsivonen | wonders what the test case is good for |
| 12:14 | <smaug____> | hmm |
| 12:15 | <smaug____> | hsivonen: exposed in which way? |
| 12:15 | <Ms2ger> | Hmm |
| 12:15 | <Ms2ger> | I guess we don't put WebIDL-only interfaces on Ci |
| 12:15 | <smaug____> | hsivonen: I added the test to make it less likely to expose random stuff to web |
| 12:15 | <hsivonen> | smaug____: listed by Object.getOwnPropertyNames(window) |
| 12:16 | <smaug____> | the test was added before we started to webidlfy stuff |
| 12:16 | <hsivonen> | smaug____: so the test only cares about nsI stuff getting accidentally exposed, it seems |
| 12:16 | <smaug____> | and nsIDOM |
| 12:16 | <smaug____> | but I'm not sure about Webidl stuff |
| 12:17 | <smaug____> | (nsI and nsIDOM are handled very differently in this kind of case) |
| 12:52 | <hsivonen> | hmm. no Object.getOwnPropertyNames() in Chrome |
| 12:54 | <jgraham> | Really?! |
| 12:55 | <hsivonen> | oh, it's uneval that's missing |
| 12:55 | hsivonen | thought everyone had uneval |
| 12:55 | <hsivonen> | do I really have to write my own array serializer? |
| 12:55 | <jgraham> | JSON.stringify |
| 12:55 | <hsivonen> | thanks |
| 12:55 | <Ms2ger> | .toString()? |
| 12:56 | <jgraham> | Well if he wants something that will parse later with eval |
| 12:56 | <jgraham> | ... then that's probably a problem on its own |
| 12:56 | <Ms2ger> | Fair |
| 12:57 | <jgraham> | (I thought only gecko had uneval) |
| 12:57 | <hsivonen> | jgraham: so it seems |
| 12:57 | Ms2ger | had never heard of uneval |
| 12:57 | <hsivonen> | but how am I supposed to know that we're the abnormal ones |
| 12:58 | <jgraham> | Well to be fair with js, that's the common case :) |
| 12:59 | <Ms2ger> | The question is, is it an e4xism |
| 12:59 | <jgraham> | (you were the only ones with E4X and all the js 1.x stuff) |
| 12:59 | <jgraham> | (for various values of x) |
| 12:59 | <Ms2ger> | We're planning to move to 1js, though, I hear |
| 13:05 | <darobin> | JSON.stringify doesn't work on everything, though, obviously |
| 13:05 | <darobin> | in some cases IIRC you still need toSource(), but I think that's mostly for old Geckos |
| 15:14 | <Ms2ger> | Mm, we're implementing WAP |
| 15:19 | <jgraham> | But in good news, I guess my time machine works |
| 15:21 | <jgraham> | Ms2ger: Bug or it didn't happen |
| 15:21 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=853715 |
| 16:16 | <sangwhan_> | Ms2ger: Does the fact that Opera has already done it make it hurt less? |
| 16:17 | <Ms2ger> | Opera did it first, eh |
| 16:17 | <sangwhan_> | Wait till you have to implement OMA DRM |
| 16:19 | <Ms2ger> | I don't think I want to know what that is |
| 16:19 | <Ms2ger> | I don't think I want to know what that is |
| 16:26 | <sangwhan_> | Looking at the commit, it's not _that_ bad :) |
| 16:43 | <KevinMarks> | thanks Yitro - I used it in http://techcrunch.com/2013/06/09/how-apples-ios-fragmentation-problems-distort-design-thinking/ |
| 17:36 | <rafaelw> | Hixie: ping |
| 18:07 | <KevinMarks> | was that an Exclusions demo in Safari? |
| 18:43 | <Ms2ger> | zcorpan: can you look at bz's comment in https://bugzilla.mozilla.org/show_bug.cgi?id=880997 please? |
| 19:06 | <Hixie> | rafaelw: pong |
| 19:28 | <rafaelw> | Hixie: can you read my last comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22185 |
| 20:11 | <Hixie> | rafaelw: looking... |
| 20:15 | <Hixie> | rafaelw: as far as i can tell, your last comment and my last coment are orthogonal |
| 20:15 | <rafaelw> | Ok. can we take them one at a time? |
| 20:15 | <rafaelw> | Am I mis-reading the spec, or is it incorrect? |
| 20:17 | <Hixie> | i don't think those are mutually exclusive :-) |
| 20:17 | <Hixie> | i don't think there's any doubt in anyone's mind that the jump to a code entry-point algorithm shouldn't call the mutation observers |
| 20:17 | <Hixie> | (at least, not unless it's the last script) |
| 20:17 | <Hixie> | the question is, should it even both calling it if it's the last script, and do you really want to remove the call to mutation observes in the parser |
| 20:19 | <rafaelw> | So I offered a proposal of a simple way to make the current spec accurate. Did my proposal remove the call to mutation observers from the parser? |
| 20:20 | <Hixie> | your proposal and your suggested changes were contradictory, so i wasn't sure what you intended, hence my follow-up questions |
| 20:21 | <Hixie> | (i don't have an opinion about what exactly should happen) |
| 20:28 | <rafaelw> | Can you explain the contradiction? |
| 20:28 | <rafaelw> | There's a step in the text insertion mode that says to run a microtask checkpoint open reaching a </script>. |
| 20:29 | <rafaelw> | If my proposal changed that, it wasn't intentional. |
| 20:29 | <rafaelw> | hixie: ^^ |
| 20:29 | <Hixie> | comment 18, right? |
| 20:30 | <Hixie> | you say "should happen at two times", but neither of the times you list is the parser, but then your suggested chnanges don't change the parser |
| 20:30 | <Hixie> | this isn't a criticism or anything, i was (and am) just trying to make sure i do what you actually intended |
| 20:30 | <rafaelw> | I see. |
| 20:30 | <rafaelw> | You are correc.t |
| 20:30 | <rafaelw> | It should be "three times". |
| 20:30 | <rafaelw> | I can go back and clarify that. |
| 20:30 | <Hixie> | here's fine :-) |
| 20:31 | <Hixie> | how about the other thing? are we sure we want to fire mutation observers twice per task if the task fires two scripts synchronously, rather than just once at the end of the task? |
| 20:31 | <rafaelw> | This was debated at length when we designed mutation observers. |
| 20:31 | <rafaelw> | It was intentional. |
| 20:31 | <Hixie> | (as opposed to the example in comment 21, which is about firing them twice within a script (as per the spec now, which is bogus, we all agree) vs once at the end of a script) |
| 20:32 | <rafaelw> | Take the case of a click. If there are multiple handlers, and mutation observers registered, then the observers should go after *each* event handler, so that the next event handler sees a "stable" state of the world. |
| 20:33 | <rafaelw> | Is this the case you are referring to? |
| 20:34 | <Hixie> | yeah, that's a good example of it |
| 20:34 | <Hixie> | btw, what's the change in your proposal regarding "global script clean-up jobs" to do with? |
| 20:35 | <rafaelw> | I suppose you can look at that as orthogonal. |
| 20:35 | <Hixie> | k |
| 20:35 | <rafaelw> | It looked to me like that was added out of a misunderstanding of how microtask checkpoints should work. |
| 20:36 | <Hixie> | global script clean-up jobs are unrelated to microtask checkpoints, iirc |
| 20:36 | <rafaelw> | Mutation Observers *is* a script clean-up job. |
| 20:37 | <rafaelw> | My point is that there are now two mechanims doing exactly the same thing. |
| 20:37 | <rafaelw> | You can make them be seperate, but it seems silly to me. |
| 20:37 | <Hixie> | you mean, they are in principle, or they are in concrete? |
| 20:37 | <rafaelw> | Principle. |
| 20:37 | <rafaelw> | And there are going to be more. |
| 20:38 | <rafaelw> | ECMAScript Object.observe callbacks, Promises, etc... |
| 20:38 | <Hixie> | the global script clean-up jobs only run at the end of a script (every script, though whether that means nested ones or not is not clear yet) |
| 20:38 | <rafaelw> | I was hoping that we could end up with one "period to run stuff that needs to put the world back in order" thingie. |
| 20:38 | <Hixie> | they don't run e.g. before scripts run in the parser |
| 20:38 | <Hixie> | or after non-script tasks |
| 20:38 | <Hixie> | (like parsing) |
| 20:39 | <rafaelw> | Is their any client for end-of-script cleanup jobs other than FileURLs? |
| 20:40 | <Hixie> | not as far as i know of, currently |
| 20:40 | <Hixie> | one key thing is that end-of-script cleanup jobs cannot run scripts of their own |
| 20:40 | <Hixie> | since their ordering isn't defined |
| 20:41 | <rafaelw> | So I'm confused by your message of "leave FileURL out of this" vs "How does script-clean-up fit into all of this" |
| 20:42 | <Hixie> | "this" in the first of those is the bug, "this" in the second is your specific proposal |
| 20:42 | <rafaelw> | I see. Well the I propose we simply remove the script clean up language. |
| 20:43 | <rafaelw> | Actually, I retract everything I said about script-clean-up. |
| 20:44 | <Hixie> | k :-) |
| 20:44 | <rafaelw> | If it only has one client and the requirements aren't clean, then I guess I don't really care about it. |
| 20:44 | <rafaelw> | (Although it seems odd to me to have language about it in that case) |
| 20:44 | <Hixie> | the requirements are clean, they're just different than microtassks |
| 20:44 | <rafaelw> | Ok, how about if I (on the bug): |
| 20:45 | <rafaelw> | 1) Clarify that microtask checkpoint should be run at three times |
| 20:45 | <rafaelw> | 2) Clarify my proposal to ignore the script clean-up. |
| 20:46 | <Hixie> | don't worry about it, i've already edited the spec as you were suggesting |
| 20:46 | <Hixie> | i'm committing the change now |
| 20:47 | <rafaelw> | Ok. Thank you. |
| 20:47 | <Hixie> | np |
| 20:47 | <Hixie> | (unfortunately for my credibility, the change also includes some unrelated editorial fixes to the script clean-up job stuff. but we'll ignore that.) |
| 20:48 | <Hixie> | at least this is an easy one. the thing about the parser's namespace-sensitivity is distressingly less so. |
| 20:49 | <rafaelw> | Good topic. |
| 20:49 | <rafaelw> | So WebKit/blink already implemented what adam proposed. |
| 20:50 | <rafaelw> | Aside from the conflict about what the author most likely meant, |
| 20:50 | <rafaelw> | One main motivation is that ambiguity like that in the parser as a source of crashers that the security folks found. |
| 20:50 | <Hixie> | there's cases where i don't even understand what we can do. e.g. "If the stack of open elements has a p element in button scope, then act as if an end tag with the tag name "p" had been seen." - what if there's a, <svg:p> on the stack, won't that close that instead? |
| 20:50 | <rafaelw> | s/as/was |
| 20:51 | <Hixie> | i don't understand why it caused crashes |
| 20:51 | <Hixie> | the spec wasn't ambiguous, it was (is) just weird in certain cases, as far as i can tell |
| 20:52 | <rafaelw> | The main problem is a conceptual one inside the implementation of the parser. |
| 20:52 | <rafaelw> | As I mentioned in the bug, when a token is encountered, it's namespace goes from abstract to concrete. |
| 20:53 | <rafaelw> | The parser code is written with the assumption that end tags match start tags of the same namespace. |
| 20:54 | <Hixie> | ah, that's definitely not a good assumption |
| 20:54 | <rafaelw> | You are suggesting that they should be tolerant of this, but it's just not how the code was written. |
| 20:54 | <Hixie> | in particular, end tags don't have a namespace |
| 20:54 | <Hixie> | tags in general don't have a namespace, in fact |
| 20:58 | <rafaelw> | I don't think that matters. |
| 20:58 | <rafaelw> | It just is the case that we fixed a bunch of crashers related to invalid assumptions in the parser code which generally takes the view I'm describing. |
| 20:59 | <rafaelw> | And based on my discussions with Mozilla re:<template> parsing, I suspect their code is similarly structured. |
| 21:00 | <rafaelw> | My point is that even if I agreed with your view that <foreignObject></div> should match an <svg:div>, I'd have a hard time landing that patch. |
| 21:04 | <Hixie> | i don't understand how you assign a namespace to a tag |
| 21:38 | <Hixie> | GPHemsley: (btw, if you could avoid cc'ing other lists that'd be great, because it causes all kinds of confusing thread fragmentation. e.g. i can't make heads or tails of your subthread that got cc'ed to apps-discuss.) |
| 21:38 | <Hixie> | GPHemsley: (though that could just be because the other guy only replied to you each time?) |
| 21:43 | <Hixie> | heycam|away: any feedback on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22102 ? |
| 22:17 | <aklein> | Hixie: this might be easier to discuss if the spec were fixed in the places where it _doesn't_ use a namespace for comparison. that is, where it says "... with the same tag name as that of the token" instead of "... has a td element in whatever scope" |
| 22:17 | <aklein> | it's not just that the spec was "weird", it was (as I think you said) "inaccurate" |
| 22:21 | <aklein> | Hixie: those passages where the spec sees, e.g., a </tr> and then says to go look for a "tr element" are those places where a namespace is being "assigned", conceptually, to a tag (in the WebKit and Blink implementations anyway) |
| 22:22 | <Hixie> | hm, interesting |
| 22:22 | <Hixie> | i'm not sure that's the right fix for that though |
| 22:23 | <Hixie> | with the foreign content stuff, i think we maybe need to stop acting as if we saw a tag |
| 22:23 | <Hixie> | and just do what we think acting that way should do |
| 22:24 | <Hixie> | so e.g. instead of "if a <th> element is in scope, act as if you saw a </th> tag token", we should just close the <th> (popping the stack, etc) directly |
| 22:35 | <aklein> | I think that would allay a lot of my concerns; that'd be a new concept though, wouldn't it? |
| 22:42 | <Hixie> | we do it in some places, i think |
| 22:42 | <Hixie> | but it would involve some normative changes, yes |
| 22:42 | <Hixie> | i think it'd probably make it easier to understand |
| 22:42 | <Hixie> | which would be a win |
| 22:43 | <aklein> | yeah, that sort of change sounds good to me regardless of this whole conversation |
| 22:43 | <aklein> | just by being more direct |
| 22:47 | <Hixie> | filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=22322 |
| 22:57 | <nessy> | Hixie: I'd like to discuss TextTrackCue API changes with you - want me to email WHATWG or what's your preference? |
| 22:57 | <zcorpan> | Hixie: do you want me to elaborate on what you should say in the html spec for https://www.w3.org/Bugs/Public/show_bug.cgi?id=15588#c11 ? |
| 23:00 | <GPHemsley> | Hixie: Any CCing of other lists happened as a result of a reply-all. I'm not actually on any other lists. |
| 23:02 | <GPHemsley> | Hixie: (So if you got multiple copies because you're on other lists, feel free to ignore anything not from the WHATWG list.) |
| 23:14 | <Hixie> | nessy: i'm here now if you want to talk here |
| 23:15 | <Hixie> | zcorpan_: i just need to use "beginning of the document" right? |
| 23:16 | <zcorpan_> | Hixie: well currently the html spec invokes "scroll an element into view" with "top of the document" which is bogus since that's not an element |
| 23:16 | <Hixie> | zcorpan_: if you have a specific wording you'd like the html spec to use, please do let me know in the bug. but i can probably work it out. |
| 23:16 | <GPHemsley> | FYI: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes |
| 23:16 | <Hixie> | GPHemsley: ah |
| 23:17 | <Hixie> | GPHemsley: i don't get multiple copies (gmail dedupes and i filter all mail through gmail), but if there were e-mails sent to you and apps-discuss from people not on whatwg, they didn't make it to the whatwg list |
| 23:17 | <Hixie> | GPHemsley: (but your replies would have) |
| 23:17 | <zcorpan_> | Hixie: ok. i'll comment in the bug while i have it paged in :-) |
| 23:17 | <Hixie> | zcorpan_: thanks :-) |
| 23:18 | <GPHemsley> | Hixie: AFAIK, those threads were only me and Peter, and I thought he's on the WHATWG list. There was one time where he only replied to me, but I reintroduced the WHATWG list in my reply. |
| 23:18 | <Hixie> | k |
| 23:18 | <nessy> | Hixie: it's particularly about this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 |
| 23:19 | <Hixie> | looking... |
| 23:19 | <nessy> | Hixie: I'm wondering if we should rename TextTrackCue to AbstractTextTrackCue, then inherit a TextTrackCue object from it that has .text in it |
| 23:20 | <GPHemsley> | Hixie: And it looks like my e-mails never even went through to apps-discuss because I'm not on that list. |
| 23:20 | <nessy> | Hixie: then WebVTTCue can inherit from that |
| 23:20 | <GPHemsley> | Hixie: (Nor is Peter, AFAICT.) |
| 23:20 | <nessy> | Hixie: then, TextTrackCue can have its constructor back, too |
| 23:20 | <Hixie> | nessy: that's what i suggested in comment 2 |
| 23:21 | <Hixie> | nessy: but it still makes no sense for TextTrackCue to have a constructor in this scenario |
| 23:21 | <nessy> | Hixie: did you? … looking... |
| 23:21 | <Hixie> | GPHemsley: good times |
| 23:21 | <GPHemsley> | indeed |
| 23:22 | <nessy> | Hixie: why would a constructor not make sense? |
| 23:22 | <Hixie> | nessy: let's go back to first principles here for this API. stop me as soon as i say something you think is wrong. |
| 23:22 | <nessy> | Hixie: ok |
| 23:23 | <zcorpan_> | Hixie: maybe i can provide a term "scroll to the beginning of the document" which would be less boilerplate for you |
| 23:23 | <Hixie> | nessy: first, each format (like WebVTT, TTML, DVD bitmap subtitles, etc) has an algorithm that defines how cues are rendered to the video frame |
| 23:24 | <nessy> | Hixie: no, not all formats are rendered |
| 23:24 | <Hixie> | nessy: so for example, WebVTT has the complicated algorithm for avoiding cue overlap. DVD bitmap subtitles just render an image over the video at an x,y coordinate. etc. |
| 23:24 | <nessy> | Hixie: some of them are for metadata only and left to deal with by JS |
| 23:24 | <Hixie> | nessy: there are subtitle/caption formats that are never rendered? |
| 23:24 | <Hixie> | nessy: like what? |
| 23:25 | <nessy> | Hixie: TextTrackCue also applies to @kind=metadata cues |
| 23:25 | <nessy> | Hixie: that could be JSON or anything else |
| 23:26 | <rillian> | chapters as well |
| 23:26 | <Hixie> | that's orthogonal |
| 23:26 | <nessy> | Hixie: they would not be exposed in a TextTrackCue ??? |
| 23:26 | <Hixie> | let's start over |
| 23:27 | <Hixie> | there are subtitle formats. these are formats for files that contain text cues. these formats can be separate files, or embedded in media resources. correct so far? |
| 23:27 | nessy | is not sure what I'm missing... |
| 23:27 | <nessy> | well, WebVTT and TTML are not just subtitle formats, but more generic |
| 23:28 | <nessy> | why are you restricting it to subtitle formats? |
| 23:28 | <Hixie> | s/subtitle formats/text track formats/ |
| 23:28 | <nessy> | ah ok, agreed |
| 23:28 | <Hixie> | ok. each of these formats come with a set of rendering rules. these rules might not apply to any particular cue at any particular time, but each format nonetheless has a set of rules. correct so far? |
| 23:29 | <Hixie> | zcorpan_: yeah, that'd be awesome |
| 23:29 | <nessy> | no, there are only rendering rules for certain types of these files |
| 23:29 | <nessy> | for example only when they contain captions or subtitles |
| 23:29 | <nessy> | when they contain descriptions or metadata, there is no rendering |
| 23:29 | <nessy> | they just get exposed to JS |
| 23:30 | <nessy> | (well, you could say that "descriptions" have rendering - but definitely not "metadata") |
| 23:30 | <Hixie> | ok i see the problem. |
| 23:30 | <nessy> | or put in a different way: WebVTT can contain cues that contain just JSON |
| 23:31 | <Hixie> | you are confusing the format's properties, with the properties of a specific instance of a text track in the HTML API |
| 23:31 | <nessy> | that could be exposed in a TextTrackCue with .text |
| 23:31 | <nessy> | where? when I say "WebVTT can contain cues that contain just JSON" ? |
| 23:32 | <rillian> | Hixie: are you saying that if the cues don't display they need to have a separate type? |
| 23:32 | <Hixie> | there's no such thing as a "metadata WebVTT file" or a "chapters TTML file" or a "descriptions DVD subtitle file" |
| 23:32 | <Hixie> | there's a WebVTT file, and if it's imported as a kind=subtitles file, it renders |
| 23:33 | <Hixie> | and if it's imported as a kind=metadata file, it doesn't |
| 23:33 | <Hixie> | but either way, WebVTT has a set of rules that say how it would render, if it were to be rendered |
| 23:33 | <nessy> | ok, but it still needs to expose its content to HTML |
| 23:33 | <nessy> | s/HTML/JS/ (more correctely) |
| 23:34 | <Hixie> | ok so let's go back to what i saw saying earlier |
| 23:34 | <Hixie> | each format has a set of rules for how it is rendered |
| 23:34 | <nessy> | ok :-) |
| 23:34 | <Hixie> | at any one time, the cue may or may not be rendered, but the cue, if it were to be rendered, has a set of rules to follow |
| 23:35 | <Hixie> | these rules come from what format the cue was parsed from |
| 23:35 | <Hixie> | so e.g. a cue from a webvtt file uses the webvtt rules |
| 23:35 | <Hixie> | a cue from a ttml file uses the ttml rules |
| 23:35 | <Hixie> | a cue from a DVD bitmap subtitle track uses the DVD bitmap subtitle rules |
| 23:35 | <Hixie> | right? |
| 23:35 | <nessy> | yup |
| 23:36 | <Hixie> | each cue has an object in the DOM |
| 23:36 | <nessy> | so a cue that is rendered from a WebVTT file is exposed as a WebVTTCue object |
| 23:36 | <Hixie> | that object is also associated with some rendering tules, the same rendering rules as the cue, derived from the file from which it was parsed |
| 23:36 | <Hixie> | but some cues aren't parsed, they're created from JS |
| 23:37 | <Hixie> | those cues need to know what rules they should use if they were suddenly to be rendered |
| 23:37 | <Hixie> | right? |
| 23:37 | <nessy> | yup, following this far |
| 23:37 | <Hixie> | so each set of rules that the browser supports being created from JS -- TTML, WebVTT, DVD bitmaps, whatever -- needs its own constructor |
| 23:38 | <Hixie> | (or factory method, or argument to a factory method, or some other mechanism, but contructor is how WebVTTCue does it) |
| 23:38 | <Hixie> | right? |
| 23:38 | <nessy> | yup, I think we're all good with cues that get rendered - we have the rendering rules associated with the particular objects etc |
| 23:39 | <Hixie> | _all_ cues can get rendered |
| 23:39 | <Hixie> | they _all_ have rendering rules just in case they are rendered |
| 23:40 | <nessy> | right …. how can that work for cues that are part of a kind=metadata track and are not rendered? can you run me through such cues all the way, too? |
| 23:40 | <nessy> | I'm a JS developer and have created a track with kind=metadata |
| 23:40 | <nessy> | how do I add cues? |
| 23:41 | <Hixie> | the kind is irrelevant |
| 23:41 | <Hixie> | you add it the same way you would if it was kind=anythingelse |
| 23:42 | <nessy> | I want to add cues that contain JSON and I don't have rendering rules for them, because they are not meant to be displayed, but used by JS only |
| 23:42 | <Hixie> | there's no such thing as a cue that doesn't have rendering rules |
| 23:42 | <Hixie> | if it's a webvtt cue, it has webvtt rules. if it's a ttml cue, it has ttml rules. |
| 23:42 | <nessy> | assume my rendering rules are "don't display anything" |
| 23:43 | <nessy> | yeah, I don't think that works |
| 23:43 | <Hixie> | you don't get to pick the rendering rules, the rendering rules are those of the formats the browser supports |
| 23:43 | <Hixie> | i don't understand what is difficult about this |
| 23:43 | <Hixie> | it's exactly the same as a WebVTT file imported with kind=metadata |
| 23:44 | <nessy> | are you saying, even if I have WebVTT cues that contain JSON, they will be exposed as WebVTTCue objects? |
| 23:45 | <Hixie> | yes |
| 23:45 | <Hixie> | because at any time you could change the .kind of the TextTrack object to "subtitles" and then they'd render |
| 23:45 | <Hixie> | there's _nothing special_ about metadata tracks |
| 23:45 | <nessy> | are you further saying that, given I want to do everything in JS, I am forced to pick a cue format that provides rendering, even if I know that I will never ever want to render it (and in fact some of the content that I may have would be really really bad when rendered)? |
| 23:46 | <Hixie> | well you're nor "forced to pick a cue format that provides rendering", you just pick the only format browsers support, WebVTT |
| 23:48 | <nessy> | so, can't we introduce a cue object that has rendering rules that simply say not to render anything? |
| 23:48 | <Hixie> | what's the point? |
| 23:49 | <Hixie> | note that right now, you can really easily debug these cues by just setting kind=subtitles instead of kind=metadata |
| 23:49 | <nessy> | it makes for simpler objects |
| 23:49 | <Hixie> | it makes for more interfaces, that's not simpler |
| 23:49 | <zcorpan_> | Hixie: done |
| 23:49 | <zcorpan_> | nn |
| 23:50 | <rillian> | Hixie: you just explained how every cue type has associated rendering rules. Therefore metadata and chapter cues should have rendering rules saying nothing is drawn. :P |
| 23:50 | <Hixie> | zcorpan_: nn |
| 23:50 | <Hixie> | zcorpan_: thanks |
| 23:50 | <Hixie> | rillian: "metadata" and "chapter" are not "cue types" |
| 23:51 | <Hixie> | rillian: that's the whole point |
| 23:51 | <Hixie> | rillian: they're text track kinds which every "cue type" can be set to |
| 23:51 | <rillian> | hrm |
| 23:52 | <nessy> | ok, then maybe we can create an object that does only simple bottom middle of video plain text rendering |
| 23:52 | <rillian> | (I also don't understand why we're breaking the old api if no one's going to implement anything but webvtt) |
| 23:52 | <rillian> | nessy: TextTrackCue? :) |
| 23:52 | <nessy> | no overlap avoidance, no complicated rendering |
| 23:52 | <Hixie> | nessy: why? |
| 23:52 | <nessy> | rillian: Microsoft are implementing (and already support) TTML |
| 23:52 | <Hixie> | rillian: because apparently people _are_ implementing other formats, in some weird places |
| 23:53 | <Hixie> | rillian: in general i agree that that's bad, mind you |
| 23:53 | <Hixie> | nessy: i don't understand what problem you are trying to solve |
| 23:53 | <nessy> | Hixie: so we can create cues in JS that don't bear the heavy weight of WebVTT cues |
| 23:53 | <Hixie> | nessy: what "heavy weight"? |
| 23:54 | <Hixie> | nessy: WebVTT is a really light-weight format |
| 23:54 | <rillian> | Hixie: you added all those positioning attributes |
| 23:55 | <Hixie> | i think it's crazy that we're seriously debating whether to create yet another subtitling format for the web, personally |
| 23:55 | <Hixie> | but putting that aside, the way one would do it is the same way we have WebVTT or TTML in the web platform: just create a new spec that defines the new format. |
| 23:55 | <nessy> | not a file format - just a cue format |
| 23:55 | <nessy> | an object in HTML |
| 23:55 | <Hixie> | file format without a serialisation, it's still a file format |
| 23:55 | <Hixie> | for these purposes |
| 23:56 | <Hixie> | (and i bet you'd shortly be asked "can we have a serialisation") |
| 23:56 | <nessy> | that's why I suggested no rendering rules |
| 23:56 | <nessy> | no, serialisation is already possible in TTML or WebVTT or SRT or anything else that does times plain text for that matter |
| 23:56 | <nessy> | no need for a new file format |
| 23:56 | <Hixie> | all of this is already possible in WebVTT |
| 23:57 | <Hixie> | this literally adds nothing new |
| 23:57 | <zewt> | i don't understand the "heavy weight WebVTT cues" argument (you're already paying the cost of implementing WebVTT; are you suggesting WebVTT cues use a lot of memory or something?) |
| 23:57 | <rillian> | nessy: looking at it from the other side, what do the webvtt cue settings mean on a metadata track where the cue text is json? |
| 23:57 | <zewt> | what does "heavy weight" mean in this context? |
| 23:58 | <nessy> | instantiating a WebVTTCue object creates interfaces (vertical, snapToLines, line, position, size, align, text, getCueAsHTML() ) that are irrelevant for cues that are not rendered |
| 23:58 | <zewt> | so? |
| 23:59 | <zewt> | (putting aside whether they can be optimized out or whatever--who cares?) |
| 23:59 | <Hixie> | man, you should see the HTMLElement interface if you think WebVTTCue is "heavy" |
| 23:59 | <Hixie> | bbiab |