| 00:01 | <Hixie> | anyone got IE handy? |
| 00:04 | <Hixie> | hsivonen: you around? |
| 00:09 | <heycam> | Hixie, I have an IE |
| 00:42 | <dgorbik> | Hixie: how should be lang WebVTT node get translated to DOM? |
| 00:43 | <JonathanNeal> | I'm drowning, my blood has gone to the extremities, and the only way to save me is to decide whether {} are braces or brackets in Hixie English. |
| 00:44 | <dgorbik> | dgorbik: oh, looks like it's still considered to be a class node but with the lang attribute set, right? |
| 00:53 | <dgorbik> | Hixie: okay so class nodes will get their language from the stack, but language nodes will still be created in the tree. So the question still remains - should they be dropped when we build a DOM tree or should a span be created with lang attribute set? |
| 04:04 | <JonathanNeal> | hello |
| 12:29 | <hsivonen> | Hixie: I’m around now |
| 12:49 | <Ms2ger> | jgraham, browser-tests? |
| 13:13 | <darobin> | bikeshed all the things! |
| 13:13 | <Ms2ger> | Hi darobin, how are you today? :) |
| 13:13 | <darobin> | I think I'm going to head home and back to bed :) |
| 13:24 | <annevk> | darobin: solid plan |
| 13:24 | <darobin> | annevk: I like it too |
| 13:26 | <MikeSmith> | oh joy http://www.iana.org/assignments/character-sets that the validator needs to parse to get valid character-set info and that has been a plain-text file for the last gazillion years now redirects to http://www.iana.org/assignments/character-sets/character-sets.xml |
| 13:27 | <MikeSmith> | though I see now the plain-text one is at http://www.iana.org/assignments/character-sets/character-sets.txt |
| 13:28 | <MikeSmith> | hsivonen: seems you must have a load problem on bugzilla.validator.nu |
| 13:29 | <MikeSmith> | it's taking a long time to load |
| 13:31 | <annevk> | MikeSmith: please implement the Encoding Standard and not IANA character-sets |
| 13:32 | <MikeSmith> | annevk: has Hixie updated the HTML spec yet? |
| 13:32 | <MikeSmith> | oh yeah I guess he did earlier this week |
| 13:33 | <annevk> | hoping to review that in more detail today |
| 13:33 | <MikeSmith> | ok |
| 13:33 | <annevk> | but yeah, HTML, CSS, now use it |
| 13:33 | <annevk> | JavaScript too I guess since HTML defines JavaScript's network layer |
| 13:34 | <MikeSmith> | OK then yeah we can update the validator to what the HTML spec says now |
| 13:35 | <annevk> | MikeSmith: which is much easier, the Encoding Standard has a fixed list |
| 13:36 | <annevk> | MikeSmith: available as JSON to boot |
| 13:36 | <MikeSmith> | yup |
| 13:37 | <hsivonen> | MikeSmith: we should switch over to the Encoding Standard like annevk says |
| 13:38 | <MikeSmith> | ok I'll up a bugzilla.validator.nu bug for it |
| 13:38 | <hsivonen> | MikeSmith: probably someone running Schematron on the same host that runs bugzilla |
| 13:40 | <MikeSmith> | hsivonen: man we really got to turn that off. I have come around to thinking it's probably still useful to keep HTML4 checking but we could just replace the current xhtml.sch with Java code just like for the HTML5 case |
| 13:41 | <MikeSmith> | the HTML4 xhtml.sch is a much smaller and simpler set of assertions than the HTML5 set |
| 13:41 | <MikeSmith> | hsivonen: good idea? bad idea? |
| 13:42 | <hsivonen> | MikeSmith: good |
| 13:43 | <hsivonen> | MikeSmith: but we should also make the default config not do HTML4 validation automatically |
| 13:43 | <hsivonen> | MikeSmith: that is, HTML4 validation should always require user action |
| 13:43 | <hsivonen> | MikeSmith: FWIW, I think https://addons.mozilla.org/en-us/firefox/addon/omnivalidator/ is what's making bugzilla.validator.nu slow |
| 13:47 | <hsivonen> | Although I could just make Validator.nu 403 for that one, I’d rather fix the perf problem |
| 13:47 | <MikeSmith> | hsivonen: if that's what's causing it you may want to ask the developer to point it at http://validator.w3.org/nu/ instead |
| 13:47 | <hsivonen> | or html5.validator.nu |
| 13:48 | <hsivonen> | hmm. maybe I can add a redirect |
| 13:48 | <MikeSmith> | I wonder if the fix for the perf problem might be to set up rate throttling |
| 13:49 | <MikeSmith> | or if the problem is not single IPs using it excessively but instead just the overall volume, I guess that wouldn't help |
| 13:50 | <hsivonen> | that, too, but most pressing fixes is: Make sure Schematron is never run without the user explicitly asking to run Schematron |
| 13:50 | <MikeSmith> | yeah |
| 13:50 | <hsivonen> | I’ll try to set up a redirect now |
| 13:50 | <MikeSmith> | so yeah I agree HTML4 validation should always require user action, never do HTML5 validation automatically |
| 13:51 | <MikeSmith> | for the W3C instance that makes even more sense because there's already the existing validator for HTML4 |
| 13:51 | <MikeSmith> | currently at least |
| 13:53 | <MikeSmith> | though the long-term plan is still to phase that out and make the validator.nu backend the default at http://validator.w3.org and move the legacy one to http://validator.w3.org/html4 or something |
| 14:13 | <hsivonen> | looks like I don't manage to make Apache do what I want |
| 14:13 | <hsivonen> | oh well |
| 14:33 | <MikeSmith> | annevk: so the document-conformance requirement in the Encoding spec is that documents must use utf-8, right? |
| 14:33 | <annevk> | yeah |
| 14:33 | <MikeSmith> | ok so we need to just emit an error for anything other than that |
| 14:33 | <annevk> | admittedly a bit optimistic, though given the many issues with everything else I think it's fair |
| 14:38 | <MikeSmith> | I guess for the other values that are listed in the spec as being required for UAs to support, we could emit a specific error saying, "Error: 'iso-8859-2' is supported in current browsers but is no longer a valid encoding. Use utf-8 instead." |
| 14:39 | <zewt> | not sure i'd say it's not "valid" (it is) |
| 14:40 | <zewt> | "iso-8859-2 is an obsolete legacy encoding, utf-8 should be used instead"? not sure |
| 14:41 | <MikeSmith> | zewt: actually I like that wording better, yeah |
| 14:42 | <zewt> | (i'm always a little wary of overselling conformance criteria) |
| 14:43 | <zewt> | personally when every browser supports something and will always support something, i find "you really shouldn't do this" to be a bit more honest than "this is illegal stop it", heh |
| 14:43 | <MikeSmith> | yeah, true |
| 14:43 | <MikeSmith> | more helpful |
| 14:44 | <MikeSmith> | I'm interested in just trying to make sure the error message is more helpful than it is annoying |
| 14:44 | <zewt> | i wonder if there's a summary somewhere of issues legacy encodings will cause that everyday authors might experience (i've been on utf-8 far too long to remember any, at least at the non-scripting markup level) |
| 14:45 | <MikeSmith> | hmm if there isn't yet we could certainly make a summary at the wiki or somewhere |
| 14:45 | <zewt> | eg. reasons non-programmer web authors, who don't need to write text outside of their legacy encoding, should care (if there are any) |
| 14:45 | <MikeSmith> | and I could actually have the error messages then include a link to that |
| 14:46 | <zewt> | ("utf-8 is nicer" isn't something joe blogger the piano teacher cares about) |
| 14:46 | <MikeSmith> | yeah |
| 14:47 | <MikeSmith> | so yeah we should definitely have a page somewhere to link to |
| 14:48 | <annevk> | zewt: http://annevankesteren.nl/2009/09/utf-8-reasons has some |
| 14:49 | <MikeSmith> | annevk: btw I think it would be better to have the spec say, "Documents must use the utf-8 encoding" instead of "Authors must use the utf-8 encoding" |
| 14:49 | <annevk> | http://annevankesteren.nl/presentations/1F4A9.html has a bunch of points too |
| 14:49 | <annevk> | MikeSmith: do you consider .js and .css files documents? |
| 14:49 | <zewt> | annevk: those (first one) are programmer reasons |
| 14:49 | <zewt> | those are easier to come up with |
| 14:50 | <zewt> | annevk: heh i was just thinking about PILE OF POO for this same reason D: |
| 14:50 | <zewt> | (it's probably a more compelling feature for random users than the others, heh) |
| 14:50 | <annevk> | you hit issues as soon as go beyond a very simple document |
| 14:51 | <annevk> | also, it's required material for a lot of new formats |
| 14:52 | <annevk> | MikeSmith: btw, for now I'd make it a Warning if that's feasible |
| 14:52 | <annevk> | MikeSmith: give people another year or so to get used to the idea |
| 14:54 | <MikeSmith> | annevk: hmm yeah as far as author vs document, I guess people normally would not consider .js and .css files to be documents, so please forget what I said :) |
| 14:54 | <zewt> | i almost sort of wish some kind of magic was stuffed into the html doctype, like <!doctype html!> or something, that future browsers could interpret as "default to utf-8", so we could skip boiletplating the charset declaration in the future |
| 14:56 | <MikeSmith> | annevk: as far as Warning vs Error I don't mind it being an Error. For end users, in practice I think most of them they really don't make any distinction -- they consider both to be errors that they need to fix |
| 14:57 | <MikeSmith> | you should ask hsivonen too but I suspect he also figures it should be an Error if you're going to make it a requirement at all |
| 14:57 | <zewt> | sometimes i pay more attention to errors, at least for documents that end up with pages of "warning autocomplete is illegal" warnings that drown out everything else (don't recall which validator that was, whichever one opera punts to by default) |
| 14:57 | <annevk> | MikeSmith: fair enough |
| 14:58 | <MikeSmith> | zewt: yeah me too but I'm mot sure if most users do that. From bug reports at least, many just seem to want "how do I make this message go away!!" |
| 14:59 | <zewt> | heh |
| 15:00 | <zewt> | everyone knows the real reason to pass validation is to make the validator pass, not to solve problems :P |
| 15:00 | <zewt> | afk work |
| 15:04 | <MikeSmith> | :) |
| 15:26 | <hsivonen> | oh great. I post to www-style and get a reply from someone who thinks we should deprecate media queries. |
| 15:26 | <hsivonen> | I wonder if I should reply to any part of his email. |
| 15:26 | <Ms2ger> | Deprecate all the things! |
| 15:26 | <Ms2ger> | My general approach to such emails is chuckle and ignore |
| 15:27 | <Ms2ger> | "If you use `respec`, your ED may be broken" |
| 15:27 | <Ms2ger> | May? |
| 15:51 | <annevk> | hsivonen: yeah, or a less than comparison in script |
| 15:52 | <annevk> | hsivonen: you'd think the point was clear even though the example was inaccurate |
| 15:55 | <annevk> | Ms2ger: so should we use a callback? |
| 15:55 | <Ms2ger> | Come again? |
| 15:55 | <annevk> | Ms2ger: sorry, for the local name + namespace -> interface map |
| 15:55 | <Ms2ger> | Ah |
| 15:55 | <annevk> | Let interface be the element interface for x and y. |
| 15:55 | <Ms2ger> | For createElement? |
| 15:56 | <Ms2ger> | That sounds good enough for me |
| 15:57 | <annevk> | The element interface for x and y is Element, unless stated otherwise. Note: other specifications require otherwise, e.g. for html and http://www.w3.org/1999/xhtml you'll get HTMLHtmlElement |
| 15:57 | <annevk> | Ms2ger: also createElementNS, don't think there's anything else, is there? |
| 15:57 | <Ms2ger> | Not as far as I know |
| 15:58 | <Ms2ger> | I just completely missed that you were talking about those at first :) |
| 15:58 | <annevk> | Well, for me the context was clear, but I should have shared it first :) |
| 15:58 | <annevk> | I think this is why sometimes people are confused with my blog posts. |
| 15:58 | <Ms2ger> | I should write some more tests |
| 15:58 | <Ms2ger> | Either that or reddit |
| 15:59 | <annevk> | Whoa reddit. I think I'm now almost two weeks without visiting reddit. |
| 16:00 | <annevk> | But given everything else that's going on it's hard to measure the impact of that. |
| 16:16 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=20775 |
| 16:16 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=20776 |
| 16:16 | <annevk> | Does MathML use special interfaces? |
| 16:17 | <annevk> | Doesn't look like it |
| 16:18 | <annevk> | Test used: <math></math><script>w(document.getElementsByTagName("math")[0])</script> |
| 16:25 | <Ms2ger> | Yeah, there was something of a MathMLElement interface, but it never got implemented |
| 16:55 | <Hixie> | hsivonen: what's the status in Gecko in terms of making BOMs override the user when the user asks for an encoding override? Leif claims you want to do this. |
| 17:00 | <Ms2ger> | Hixie, https://bugzilla.mozilla.org/show_bug.cgi?id=234628 |
| 17:14 | <Hixie> | that's about xml |
| 17:15 | <Hixie> | or at least was for a while? |
| 17:16 | <Hixie> | i can't tell what the answer to my question is from that bug |
| 17:20 | <Ms2ger> | Hmm |
| 17:20 | <Ms2ger> | Maybe it's for polyglot |
| 17:20 | <Hixie> | ok well, either way, this all seems to be UI-specific, so I'll just punt on this. |
| 17:38 | <TabAtkins> | hsivonen: Jeezus christ, no, don't respond to that email. |
| 17:45 | <esprehn_> | TabAtkins: ?? |
| 17:45 | <TabAtkins> | esprehn_: hsivonen posted a message to www-style about MQs, got several dumb emails amounting to "MQs are dumb, just use fluid design". |
| 17:46 | <esprehn_> | TabAtkins: I do rather enjoy lines of text that span my entire 30in monitor |
| 17:48 | <Hixie> | wow, talk about unlucky |
| 17:49 | <Hixie> | back on jan 16th i was testing some code i wrote |
| 17:49 | <Hixie> | which converts a Date to a string in the format "day-of-month month", as in, Jan 16 |
| 17:49 | <Hixie> | and it worked great! |
| 17:49 | <Hixie> | today I noticed _all_ the days were Jan 16 |
| 17:50 | <MikeSmith> | hahaha :-) |
| 17:50 | <TabAtkins> | Hahaha |
| 17:50 | <Hixie> | turns out that the number of seconds from jan 1 1970 to now equals the number of milliseconds from jan 1 1970 to jan 16 1970 |
| 17:50 | <hsivonen> | TabAtkins: I already did, but only to the part that posed a question many others might wonder about |
| 17:50 | <TabAtkins> | hsivonen: Now that I've read the rest of the thread, bozo bit flipped on this Fred dude. |
| 17:55 | <JonathanNeal> | "There is no single combination of containers and codecs that works in all HTML5 browsers." That's not true anymore, is it? |
| 17:55 | <JonathanNeal> | Does webm work in IE10? |
| 17:55 | <TabAtkins> | WebM still doesnt' work in Safari anyway, iirc. |
| 17:55 | <JonathanNeal> | Bummer. |
| 17:55 | <TabAtkins> | WebM can work in IE10 if you've installed the codecs yourself. |
| 17:56 | <JonathanNeal> | "This is not likely to change in the near future." also true? |
| 17:56 | <TabAtkins> | To the best of my knowledge, yes. |
| 17:56 | <JonathanNeal> | Do they all support H.264? |
| 17:57 | <TabAtkins> | Dunno about Opera. FF... might now, if you have the codecs already on your system. |
| 17:59 | <JonathanNeal> | Okay, Opera only supports webm and ovg. |
| 17:59 | <JonathanNeal> | *ogv |
| 18:21 | <JonathanNeal> | Hahaha, just read up on the two year anniversary of Chrome not pulling out H.264 support. http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html |
| 18:21 | <JonathanNeal> | But I like H.264. |
| 18:23 | <TabAtkins> | If it weren't for licensing, I'd have no problems with it. |
| 18:23 | <TabAtkins> | (Though I think WebM is technically better now.) |
| 18:28 | <Hixie> | Stevef_: you're welcome to participate in the whatwg community, but i would really appreciate it if you would then actually participate, rather than just throwing links to other discussions in every few weeks. |
| 18:31 | <Stevef_> | hixie: I stated why I pointed to the particular discussion and also pointed to some suggestions I had produced, if you don't want the what wg list members to be aware of discussions affecting HTML in other fora, I will not make them aware via your list. |
| 18:32 | <Hixie> | Stevef_: people who want to be aware of public-html discussions have subscribed to public-html |
| 18:32 | <Hixie> | Stevef_: so if your goal is just to have people be aware of public-html discussions, there's no need |
| 18:32 | <Hixie> | Stevef_: thanks for the consideration, though |
| 18:34 | <Stevef_> | hixie: ok message understood I will not bring up disvussions that have potential to chnage stuff in the HTML 5/5.1 on the whatwg list |
| 18:34 | <TabAtkins> | Dude, don't be purposely difficult. |
| 18:34 | <Hixie> | TabAtkins: let it go, he's gotten way less rude than he used to be |
| 18:34 | <astearns> | s/Dude/Dudes/ |
| 18:34 | <Ms2ger> | What he said |
| 18:35 | <Hixie> | i like the ambiguity of Ms2ger's statement, leaving it unclear if he's supporting tab, me, or astearns :-P |
| 18:35 | <Ms2ger> | astearns, in fact |
| 18:35 | <Hixie> | seems reasonable :-) |
| 18:36 | <JonathanNeal> | Yea, I have to agree with astearns too. Dude has a point. |
| 18:36 | <TabAtkins> | s/Dude/Dudes/ |
| 18:37 | <Ms2ger> | No, just astearns |
| 18:37 | <TabAtkins> | (I just wanted to make your sentence ungrammatical.) |
| 18:37 | <JonathanNeal> | Nope |
| 18:37 | <TabAtkins> | Hixie: Yo, do you call {} "braces" or "brackets"? |
| 18:37 | <Hixie> | braces or curly brackets |
| 18:37 | <TabAtkins> | Haha. |
| 18:38 | <Hixie> | straight brackets, or square brackets, are [] |
| 18:38 | <Hixie> | parentheses, or round brackets, are () |
| 18:38 | <Hixie> | angle brackets, or les conveniently "less than greater than", are <> |
| 18:38 | <Hixie> | less |
| 18:39 | <Hixie> | by "straight brackets" i mean straight "brackets", not the term "straight brackets" |
| 18:39 | <TabAtkins> | Ah, that was unclear. |
| 18:39 | <TabAtkins> | Use "Just" or "Plain" to avoid geometric terms in a situation like this. |
| 18:39 | <Hixie> | yeah |
| 18:39 | <hober> | "the unmarked case" |
| 18:39 | <Hixie> | "plain brackets" are brackets you use to surround fields |
| 18:40 | <JonathanNeal> | I think Hixie and his English would agree with http://www.jonathantneal.com/characters/ |
| 18:40 | <Hixie> | as in corn fields, not as in plane fields |
| 18:40 | <Hixie> | also i may be being silly now |
| 18:40 | <TabAtkins> | plane fields are airplane junkyards. |
| 18:40 | <Ms2ger> | [corn fields] |
| 18:40 | <Hixie> | JonathanNeal: i prefer "octothorpe" for #, though hash is fine too. |
| 18:41 | <Hixie> | and ` is "backtick", not just "tick" |
| 18:41 | <Hixie> | "?" is "question mark", not "query" |
| 18:41 | <Hixie> | " is "double quote" |
| 18:41 | <Hixie> | | is "vertical bar" |
| 18:41 | <Ms2ger> | Oh dear |
| 18:41 | <TabAtkins> | Next controversial pronunciation question: is "char" pronounced with a soft ch like "chair", or a hard ch like "character"? And is it a long ar like "bar", or a soft ar like "bare"? |
| 18:41 | <JonathanNeal> | It is a double quote, but when someone says quote I first think of ". The section just to the right of that clarifies it. |
| 18:41 | <Hixie> | and ! is only "bang" if you're reading it as part of something else |
| 18:42 | <Hixie> | TabAtkins: "char" is pronounced "car" in my world, because it's shart for "character". |
| 18:42 | <TabAtkins> | ...shart? |
| 18:42 | <Hixie> | uh |
| 18:42 | <Hixie> | short |
| 18:42 | <Hixie> | dvorak typo |
| 18:43 | <Hixie> | (or a weird british accent, your choice) |
| 18:43 | <TabAtkins> | So, becuase it's short for character, you still don't pronounce it like "character". (Wrong vowel.) |
| 18:44 | <Hixie> | yeah, the "a" is weird. dunno why. (note i don't pronounce the first "a" in "character" as either "bar" or "bare") |
| 18:44 | <Hixie> | i pronounce it more like the norwegian ae ligature character |
| 18:45 | <Hixie> | like "hat" |
| 18:45 | <JonathanNeal> | I will find a way to get everyone agreeing on this language, by golly. |
| 18:45 | <Hixie> | hah |
| 18:45 | <Hixie> | good luck with that |
| 18:45 | <Hixie> | afk |
| 18:45 | <JonathanNeal> | "char" as in "chardonnay" |
| 18:46 | <TabAtkins> | Just swap both phonemes to the wrong one? |
| 18:46 | GPHemsley | pronounces "char" like it reads, ignoring any relationship to "character" |
| 18:46 | TabAtkins | too. |
| 18:46 | <JonathanNeal> | I pronounce it like charcoal. |
| 18:46 | <TabAtkins> | Like the english word "char". |
| 18:46 | GPHemsley | scrolls back to find out what this conversation is about. |
| 18:47 | <TabAtkins> | How Hixie names the {} characters. |
| 18:48 | <GPHemsley> | () = parentheses; [] = square brackets; {} = curly braces; <> = angle brackets |
| 18:48 | <GPHemsley> | # depends on contexts, probably hash nowadays |
| 18:49 | <GPHemsley> | ` = backtick; ? = question mark; " = double quotes; | = vertical bar |
| 18:49 | <JonathanNeal> | The context is as independent characters in web programming |
| 18:49 | <JonathanNeal> | GPHemsley http://jonathantneal.com/characters/ |
| 18:49 | <TabAtkins> | Also, more or less how you would read the character if encountering it in code that you're reading out to another coder. |
| 18:49 | <GPHemsley> | ! = exclamation point, except for hashbang |
| 18:49 | <TabAtkins> | Frex, while I name | as "vertical bar", I'd just call it "bar" casually. |
| 18:50 | <GPHemsley> | ! can also be "not" in certain contexts |
| 18:50 | <GPHemsley> | like != = "not equals" |
| 18:51 | <GPHemsley> | * = star or asterisk |
| 18:51 | <GPHemsley> | interestingly, I don't seem to think of < and > as open and close |
| 18:53 | <GPHemsley> | I don't use shorthand "paren" or "dollar"; it's "parenthesis" and "dollar sign" |
| 18:53 | <GPHemsley> | I think the rest are OK |
| 18:55 | <JonathanNeal> | Thanks GPHemsley. It is interesting to learn how many different ways we identify these characters. |
| 18:55 | <GPHemsley> | It's also interesting, because I'm not used to saying these things out loud |
| 18:55 | <GPHemsley> | so, for example, how do you pronounce "admin"? |
| 18:56 | <JonathanNeal> | "add men" |
| 18:56 | <JonathanNeal> | yourself? |
| 18:56 | <TabAtkins> | Like "administrator" without the suffix? |
| 18:56 | <TabAtkins> | Oh, and stress moved to the first syllable, per stadnard English rules. |
| 18:56 | <JonathanNeal> | I wish the stress was moved to the first syllable in paren. |
| 18:57 | <TabAtkins> | JonathanNeal: It is when I say it. |
| 18:57 | <JonathanNeal> | Do you say "puh ren" or "per en"? |
| 18:57 | <TabAtkins> | GPHemsley: I started expicitly shortening "parenthesis" when I started saying it more, because the repeated th/s phonemes are tongue-twisters. |
| 18:57 | <TabAtkins> | "pair en". |
| 18:58 | <JonathanNeal> | Interesting, and I call them "per en". |
| 18:58 | <TabAtkins> | Pronouncing it like it was a new word, unrelated to the context from which it was shortened. |
| 18:58 | <GPHemsley> | TabAtkins: Yeah, see, I don't do the stress movement. |
| 18:58 | <TabAtkins> | (I pronounce a lot of initialisms too, which requires some creativity due to them breaking spelling rules.) |
| 18:59 | <GPHemsley> | Also at play here is the Mary/marry/merry distinction/merger |
| 18:59 | <TabAtkins> | CSS = SEH-sis, HTML = HUH-tuh-mul |
| 18:59 | <GPHemsley> | oh wow |
| 18:59 | <TabAtkins> | GPHemsley: Yeah, the sound definitely falls into that merger. |
| 18:59 | <TabAtkins> | Or HEH-tim-mul, I guess, now that I say it out loud. |
| 18:59 | <Ms2ger> | What-wig? |
| 19:00 | <TabAtkins> | Yes. |
| 19:00 | <JonathanNeal> | TabAtkins: whoooooa |
| 19:00 | <JonathanNeal> | "png" as in "ping", gif with a g as in "guide". |
| 19:00 | <GPHemsley> | yikes |
| 19:00 | <TabAtkins> | Yup. |
| 19:00 | <GPHemsley> | SEE ess ess; aitch tee EM ell; what double you jee |
| 19:01 | <GPHemsley> | PNG is usually pee enn jee |
| 19:01 | <JonathanNeal> | GPHemsley: ++ |
| 19:01 | <JonathanNeal> | except for PNG |
| 19:01 | <GPHemsley> | but I'm a soft G GIFfer |
| 19:03 | <JonathanNeal> | Webemm? |
| 19:03 | <GPHemsley> | sounds good |
| 19:03 | <TabAtkins> | Webimm. |
| 19:04 | <JonathanNeal> | Speaking of which, I want to change the recommended order of encoding videos from "Webm, ogg, h.264" to "Webm, h.264, ogg", because of the current state of support. What do you think? |
| 19:04 | <TabAtkins> | Well, I think that's my merger talking. Webemm is probably a better spelling. |
| 19:04 | <GPHemsley> | oh, then there's the pin/pen merger |
| 19:04 | <JonathanNeal> | ogg isn't really necessary in a post Firefox 3.5 - Opera 10.5 world. |
| 19:04 | <TabAtkins> | JonathanNeal: Yes, that's fine. Using *just* WebM and h.264 is sufficient. |
| 19:05 | <TabAtkins> | Iirc, you can do the same two-codec dance with audio, too. MP3 works in several, but I forget which free format covers the remainder. |
| 19:09 | <JonathanNeal> | Neither do I, but I suspect its ogv. |
| 19:09 | <TabAtkins> | Likely. |
| 19:09 | <TabAtkins> | Since Opera and FF both like Ogg. |
| 19:10 | <TabAtkins> | And I think everyone else does MP3 |
| 19:10 | <Ms2ger> | Wave? |
| 19:11 | <TabAtkins> | Come now, be serious. |
| 19:13 | <JonathanNeal> | *waves back* |
| 19:14 | <Stevef_> | hixie: FYI i pointed to html list for context i pointed to http://www.html5accessibility.com/tests/comments.html which is some ideas and explanation i put together, so didn't merely throw a link |
| 19:14 | <JonathanNeal> | http://diveintohtml5.info/video.html#video-containers also fails to mention wmf, but does mention avi |
| 19:19 | <pablof> | this is bringing the metafilter pronunciation survey to mind, http://metatalk.metafilter.com/21984/2012-MetaFilter-Survey-and-Research-Discussion-Thread |
| 19:19 | <JonathanNeal> | wmv, sorry. |
| 19:22 | <Ms2ger> | Mailing lists are a support forum anyway |
| 19:37 | <tantek> | Ms2ger++ |
| 20:11 | <jgraham> | The correct prnounciation of "{}" is "thank goodness I'm not using a Swedish keyboard". At least that's what I say if I have to type them and read what I'm doing aloud |
| 20:12 | <jgraham> | Although probably "goodness" isn't quite right |
| 20:13 | <TabAtkins> | Good thing about CSS is that it uses enough punctuation to lock us into caring about a fairly narrow set of keyboards, so we've got a decent idea of what other glyphs we can use. |
| 20:16 | <jgraham> | I am really surprised that so many people don't just switch to something more programmer-friendly for writing code. I mean it isn't really *fair* that programming languages were invented in English-speaking countries and used the symbols that are easy to access on the corresponding keyboard, but having to reach for AltGr all the time must suck. In fact I think sometimes you need three-key combinations |
| 20:21 | <esprehn_> | jgraham: I'd assume most editors fill stuff in automatically |
| 20:24 | <jgraham> | esprehn_: Not really, I mean some will ad a losing brace if you put in an opening one, but you can't do much more than that |
| 20:24 | <JonathanNeal> | Ah, the "fairness" of coding languages. |
| 20:25 | <jgraham> | *add a closing |
| 20:26 | <JonathanNeal> | Seeking any kind of sweeping cultural fairness (especially in technology) as a policy is flawed, I think inherently. |
| 20:27 | <Ms2ger> | But we need to be fair! |
| 20:27 | <Ms2ger> | And have unicode case insensitivity! |
| 20:27 | <JonathanNeal> | Effectively, the engineers of HTML and CSS hijacked english, and it is now part of their trade language. Now, due to their similarities, english and web terminology will affect each other. |
| 20:31 | <JonathanNeal> | I saw a video recently of an arabic programming language. I think that's really cool. I understand the potential advantages. I understand the linguistic advantage of dropping English and speaking Esperanto. |
| 20:31 | <JonathanNeal> | But it's just not practical, given the human experience and human limitation. </html5:rant> |
| 20:34 | <Ms2ger> | And it's a lot more convenient than Arabic for us, no? |
| 20:35 | <jgraham> | (I believe that esperanto isn't considered very theoretically good) |
| 20:35 | <gsnedders> | (Indeed.) |
| 20:36 | <jgraham> | (The future is supposed to be more like http://www.exocomics.com/101 ) |
| 20:36 | <gsnedders> | (There is no language that is theoretically good, because sociolinguistic pressures always cause deviation) |
| 20:37 | <jgraham> | Well yes, that's one issue |
| 20:39 | <JonathanNeal> | say "pacific ocean" and give the "c" the same sound every time. |
| 20:40 | <jgraham> | why? |
| 20:45 | <JonathanNeal> | y? |
| 21:56 | <JonathanNeal> | Do you call ‹ a chevron? That's not <, mind you. Or do you call it an angle quotation, something else? |
| 21:56 | <TabAtkins> | I don't know what the character is, exactly. |
| 21:56 | <TabAtkins> | Is it the french quotation mark? |
| 21:58 | <TabAtkins> | The only thing I call a chevron is the symbol used in military ranks. |
| 21:58 | <JonathanNeal> | It's from http://www.w3.org/TR/WD-entities-961125#entspecial It may be the french one, it goes by the name guillemet. |
| 21:58 | <TabAtkins> | Ah, kk. In that case, I call it a guillemet, or "single french quotation mark, you know, the angle thingies". |
| 21:58 | <JonathanNeal> | Wikipedia calls it "Double angle quote (chevron, guillemet, duck-foot quote), left" |
| 21:59 | <TabAtkins> | But I don't actually refer to it in any meaningful amount, outside of discussing the internationalization of quotation marks in CSS, so the name I give it doesn't matter much. |
| 22:01 | <JonathanNeal> | And the guillemet has two. Okay. |
| 22:05 | <JonathanNeal> | Yea, we don't use any of these when writing structural HTML, CSS, or JavaScript |
| 22:06 | <esprehn_> | chevron is just a generic term for things that look like like < and > or stripes |
| 22:06 | <esprehn_> | the military rank bars are chevrons even if they're straight lines |
| 22:09 | <esprehn_> | Hixie: what's the reason for webvtt being an entirely new language instead of just XML or HTML? |
| 22:10 | <TabAtkins> | esprehn_: It's not an entirely new language - it's a close cousin to an existing subtitle format. |
| 22:10 | <TabAtkins> | (And I think plain VTT is still parseable as WebVTT for the most part.) |
| 22:10 | <esprehn_> | mm |
| 22:10 | <TabAtkins> | s/existing/existing and very popular/ |
| 22:11 | <esprehn_> | This feels like it should have been XML with a mapping from the XML ns to the HTML ns, the wormhole is very unfortunate |
| 22:12 | <esprehn_> | ex i { color: red; } ::cue(i) { color: blue } |
| 22:12 | <esprehn_> | the design is confusing |
| 22:12 | <TabAtkins> | What wormhole? It's an embedded document. No embedded documents are targetable directly from the outside document. |
| 22:13 | <esprehn_> | oh I see, these things are not actually elements |
| 22:13 | <esprehn_> | hmm |
| 22:13 | <esprehn_> | dgorbik: I'm not sure this implementation you have makes sense |
| 22:13 | <esprehn_> | in the spec they're not Elements or even HTMLElements |
| 22:14 | <esprehn_> | they're just a logical tree that produces a rendered result that you can then convert to HTML in the form of a DocumentFragment |
| 22:15 | <esprehn_> | TabAtkins: yeah, now that I read this spec more closely... |
| 22:15 | <esprehn_> | TabAtkins: the web VTT universe is not really even a DOM universe |
| 22:16 | <TabAtkins> | esprehn_: Right, it's not DOM, but it's close enough that it's mappable into a document tree for CSS. |
| 22:16 | <TabAtkins> | It *could* be made into full DOM. |
| 22:16 | <TabAtkins> | It has all the necessary abstractions. |
| 22:17 | <esprehn_> | yeah |
| 22:17 | <JonathanNeal> | needs moar <!doctype subtitle> |
| 22:19 | <nimbu1> | bleh welcome to web word esprehn_ everything is just 'close enough' to everything else |
| 22:19 | <esprehn_> | heh |
| 22:32 | <dgorbik> | esprehn_: there is no other way to have CSS matching and rendering without using Elements obviously |
| 22:33 | <esprehn_> | dgorbik: yes but the webvtt node tree can be a tree of very light weight nodes that just maps to the resulting HTMLElements that live in the shadow |
| 22:33 | <Hixie> | esprehn_: it's essentially SRT |
| 22:33 | <esprehn_> | dgorbik: think of this as if you were implementing it in JS, you'd have a tree of JS objects for the VTT nodes, and the DOM would contain HTML nodes |
| 22:33 | <Hixie> | esprehn_: but as a general rule, XML is a disaster, and HTML more so, so that's why not to reuse those. :-) |
| 22:34 | <dgorbik> | esprehn_: I am not sure how that would be different from reusing Nodes and Elements and all this infrustructure. Why should we invent trees again? |
| 22:36 | <esprehn_> | dgorbik: because what you're doing requires a lot of special hackery and being very careful |
| 22:37 | <jgraham> | In case any HTMLWG chairs are listening "You really don't know much about this field, do you?" is the point at which you start applying whatever etiquette policy we have. |
| 22:37 | <dgorbik> | esprehn_: I still will not be able to build a tree for rendering purposed (in shadow dom) with those lightwait objects. |
| 22:38 | <dgorbik> | purposes* |
| 22:38 | <esprehn_> | dgorbik: ex ::cue(i[style]) should not match, but clearly would if you just used an inline style. |
| 22:38 | <JonathanNeal> | I get so used to functions that don't exist. |
| 22:39 | <JonathanNeal> | Element.prototype.forEach. |
| 22:40 | <dgorbik> | esprehn_: are you trying to say that inline styles will introduce some other problems like this? |
| 22:40 | <esprehn_> | dgorbik: when you implement that nested selector matching you'll need to be careful |
| 22:40 | <esprehn_> | I guess either approach is fine |
| 22:40 | <esprehn_> | creating elements in the html namesape that are not HTMLElement certainly isn't :) |
| 22:41 | <dgorbik> | esprehn_: which one is the second approach? the first one is to use inline styles and separate tags |
| 22:42 | <esprehn_> | dgorbik: to create a separate tree, produce real HTML elements, and stick a scoped stylesheet down in the shadow. |
| 22:42 | <esprehn_> | I guess you're someone stuck since <v> is not an HTML element :/ |
| 22:43 | <esprehn_> | somewhat* |
| 22:44 | <esprehn_> | sigh |
| 22:44 | <esprehn_> | dgorbik: just fix the namespace and use an inline style for now |
| 22:44 | <esprehn_> | Hixie: my issue is that we're going to bloat the browser terribly if every new thing invents a new format |
| 22:45 | <esprehn_> | I suppose if this format already exists :) |
| 22:46 | <zewt> | <v> generates a <span title=voice> DOM node, not a <v> element |
| 22:46 | <Hixie> | esprehn_: i don't think supporting new dedicated formats is a substantial source of code complexity or size, especially relative to the alternatives |
| 22:46 | <Hixie> | zewt: the only time <v> generates <span title=voice> is if you use the method that converts WebVTT to HTML, but that's not really likely to be used much |
| 22:47 | <esprehn_> | zewt: not in the tree dgorbik is producing, because he wants ::cue(v) to match without extra work |
| 22:47 | <Hixie> | zewt: in particular, that isn't relevant to the rendering part |
| 22:47 | <zewt> | Hixie: he said "produce real HTML elements", so that seems like the only sane thing to do |
| 22:47 | <esprehn_> | yes |
| 22:49 | <zewt> | esprehn_: you'll (he'll) have to do some extra work no matter what, since ::cue doesn't exist outside of WebVTT in the first place (right?) |
| 22:49 | <dgorbik> | esprehn_, Hixie: this is a balance between having a unified markup or having a more suitable language for each purpose (and easier for the end user). The problem that this webvtt thing is not convertible in terms of syntax to html markup because it introduces its small differences. So we try to reuse existing html objects but also add something new to them. |
| 22:52 | <esprehn_> | zewt: yeah, it's a question of which machinery you want to change |
| 22:53 | <Hixie> | dgorbik: imho "unified markup" has been convincingly demonstrated to be a fool's errand. :-) |
| 22:53 | <Hixie> | zewt: i don't understand the relevance of HTML elements to WebVTT |
| 22:53 | <esprehn_> | principally this whole feature is like glorified generated content, like if you could ask an HTMLElement to produce the equivalent html for the :before or :after pseudo elements |
| 22:53 | <esprehn_> | perhaps such a mapping should even exist |
| 22:56 | <dgorbik> | When we try to mimic webvtt rendering by using htmlelements latter start to imply their own meaning (like style attribute like esprehn_ mentioned). That makes this even harder |
| 22:57 | <dgorbik> | Hixie: well, it may be less or more unified, it's just a matter of balance |
| 22:57 | <zewt> | not sure what you mean by the style attribute; webvtt's dom construction rules never create style attributes |
| 22:58 | <Hixie> | don't try to mimic webvtt rendering by using html elements, why would you do that? |
| 22:58 | <esprehn_> | zewt: he's talking about a webkit implementation detail |
| 22:58 | <esprehn_> | the one that I'm questioning |
| 22:58 | <zewt> | what detail is that, again? |
| 22:59 | <dgorbik> | Hixie: is mimicing webvtt rendering by using just elements or styledelements is fine though? : |
| 22:59 | <dgorbik> | :) |
| 22:59 | <Hixie> | i wouldn't mimic webvtt rendering at all :-) |
| 22:59 | <Hixie> | just render webvtt directly |
| 22:59 | <Hixie> | why would you use any kind of dom elements? |
| 23:00 | <esprehn_> | Hixie: because that's how selector matching works for things like ::cue(v) { ... } and anonymous renderers like those this would create are very problematic, specifically the text inside them is not selectable |
| 23:00 | <dgorbik> | esprehn_: does this mean that Hixie suggests having a separate tree we attach to and produce a RenderTree? |
| 23:00 | <esprehn_> | dgorbik: yes |
| 23:00 | <dgorbik> | yep, selector matching still will not work in this case. |
| 23:00 | <Hixie> | i don't understand what selector matching has to do with elements, other than as a historical implementation detail |
| 23:01 | <Hixie> | nothing in CSS requires that it be matched against DOMs only |
| 23:01 | <Hixie> | any tree with named nodes is fine |
| 23:01 | <esprehn_> | Hixie: That |
| 23:01 | <esprehn_> | That's just not how webkit works |
| 23:01 | <esprehn_> | and there's no way they're going to make the selector matching engine generic as you describe |
| 23:01 | <Hixie> | so fix webkit |
| 23:02 | <esprehn_> | it's extremely optimized for very specific use cases |
| 23:02 | <dgorbik> | only HTMLElements are related to DOM directly as far as I understand. Just Element implements some traits of html elements but can be used elsewhere. Is this right? |
| 23:02 | <Hixie> | so optimise it for two use cases :-) |
| 23:02 | <Hixie> | dgorbik: HTMLElement inherits from Element |
| 23:03 | <esprehn_> | Hixie: I'm not going to fight that fight with the people that maintain that part of webkit, the entire thing would need to be rewritten |
| 23:03 | <Hixie> | dgorbik: the DOM is a tree of Element objects (and other objects inheriting from Node), rooted at a Document object (hence Document Object Model) |
| 23:03 | <Hixie> | esprehn_: so rewrite it. why would there be a fight? |
| 23:04 | <zewt> | ... i expect there would be a fight in any production browser at someone rewriting a critical component, heh |
| 23:04 | <esprehn_> | dgorbik is welcome to debate that with Apple |
| 23:04 | <dgorbik> | :D |
| 23:04 | <Hixie> | esprehn_: writing hacky code because of concerns over who's going to fight what is definitely not a good design approach :-) |
| 23:04 | <esprehn_> | I'm not going to be involved in the discussion to rewrite a major critical component of webkit just for WebVTT |
| 23:05 | <esprehn_> | it's a year's worth of work |
| 23:05 | <esprehn_> | and a political mine field :) |
| 23:06 | <zewt> | Hixie: any production codebase is going to see massive resistance to rewriting a critical, heavily-tested and optimized component, especially if it's just for one isolated feature |
| 23:06 | <dgorbik> | esprehn_: how is this related to the political side of things? |
| 23:07 | <zewt> | i wouldn't be surprised if the reaction was that the feature just isn't worth the reengineering cost--that isn't political at all, simply practical cost analysis |
| 23:07 | <esprehn_> | dgorbik: I don't think antti and kling would want to rewrite the entire selector matching system just for webvtt to match logical non Node things |
| 23:08 | <esprehn_> | nor do I think that approach really makes sense anyway |
| 23:09 | <dgorbik> | esprehn_: Is there even a way to do this? I wonder based on what this selector matching system would match non Node objects |
| 23:09 | <zewt> | why can't they be a Node subclass (but one that isn't exposed as a child to scripts)? |
| 23:09 | <dgorbik> | esprehn_: you will have to have some kind of an interface for what can be matched and will end up with the same Element or HTMLElement |
| 23:10 | <esprehn_> | dgorbik: yes, just use an Element |
| 23:10 | <zewt> | <zewt> what detail is that, again? <- |
| 23:10 | <zewt> | (some issue related to style) |
| 23:12 | <zewt> | (if they're Element, then they don't have a style anyway--that's HTMLElement) |
| 23:12 | <Hixie> | using something like Node or Element is an ugly hack with horrible memory characteristics |
| 23:13 | <Hixie> | there's no need for parts of webvtt to have event listener machinery, for example |
| 23:13 | <zewt> | whether or not that has horrible memory characteristics seems like an implementation detail :P |
| 23:14 | <zewt> | (one which I know nothing about) |
| 23:14 | <Hixie> | isn't all of this an implementation detail? |
| 23:15 | <zewt> | sure |
| 23:15 | <zewt> | still an implementation detail |
| 23:17 | <dgorbik> | zewt: if we set the inline style for those webvtt elements, 'style' attribute appears and is accessible with css matching code like ::cue(v[style]) |
| 23:17 | <zewt> | (if they want to deal with that eg. by introducing an internal base class of Node without event handling they can do that--it just doesn't seem like the issue here) |
| 23:17 | <dgorbik> | which is not required by specs |
| 23:18 | <esprehn_> | Hixie: can I apply transitions on these things? |
| 23:18 | <esprehn_> | or animations |
| 23:18 | <Hixie> | dgorbik: it's not "not required", it's "required not", as in, that would be a violation of the spec |
| 23:18 | <zewt> | dgorbik: if it's an Element, it has no style (that's introduced in HTMLElement), right? |
| 23:19 | <Hixie> | esprehn_: not currently, but we should in due course fix that and provide a way to do transitions |
| 23:19 | <esprehn_> | dgorbik: element[style] has nothing to do with style, it has to do with an element that has an attribute named style |
| 23:19 | <Hixie> | esprehn_: the main problem is the transitions that are needed for webvtt are generally directional too |
| 23:19 | <esprehn_> | err zewt I meant |
| 23:19 | <Hixie> | esprehn_: not just temporal |
| 23:19 | <Hixie> | esprehn_: e.g. sweeping a colour change left to right |
| 23:19 | <zewt> | esprehn: you definitely wouldn't set an attribute named "style" |
| 23:20 | <dgorbik> | Hixie: do you suggest separating those classes the way so we have all that is needed by selector matching in the underlying class and have everything else above? I don't see yet how it's even possible to extract selector matching and make it unified |
| 23:20 | <esprehn_> | zewt: in the hacky way of implementing this feature as dgorbik was describing you would. |
| 23:20 | <zewt> | sounds like the wrong way, then :) |
| 23:20 | <esprehn_> | yes |
| 23:20 | <Hixie> | dgorbik: i'm not familiar with webkit's code enough to make intelligent recommendations at that level |
| 23:21 | <zewt> | it makes sense to me (on first glance, at least) to parse webvtt cues to a tree of Element subclasses (or maybe just Node), and then you'd have a renderer sitting at the top of that tree, rendering based on its children |
| 23:21 | <Hixie> | dgorbik: but in principle, selectors as a concept are agnostic to the kind of node being matched |
| 23:21 | <dgorbik> | Hixie: but how would you do this if you were creating you own 'ideal' browser? |
| 23:22 | <Hixie> | dgorbik: have a generic selector-matching machinery that could be passed trees where hte nodes in the tree implemented an interface that exposed things that the selector matcher would use |
| 23:22 | <zewt> | it *might* make sense to parse to a tree of HTMLElements, and let the general-purpose DOM renderer do the rendering, but you'd need to avoid things like setting attributes |
| 23:22 | <Hixie> | dgorbik: like "what is your name", and "what is your parent", and "what are your attributes", and "what is your language", and "are you being hovered over", etc |
| 23:22 | <zewt> | (my impression from the things that WebVTT does is that trying to render it like that would be tricky at best, though...) |
| 23:23 | <Hixie> | dgorbik: or alternatively, make the selector matching system be templated so that you could instantiate one for DOM Nodes, one for WebVTT trees, etc |
| 23:23 | <dgorbik> | Hixie: it would be much easier if we used Objective C instead of C++ I guess :-) |
| 23:23 | <zewt> | i also don't know enough (anything at all) about webkit to help, though |
| 23:26 | <zewt> | can you define an internal style property on HTMLElement, which is fed into the style determination (like the style attribute) but is internal and not reflected by any attribute, so you can set it without it being visible to selectors? |
| 23:27 | <dgorbik> | zewt: too much hackery in general code |
| 23:27 | <zewt> | why? |
| 23:27 | <dgorbik> | people don't like to see webvtt checks in the core |
| 23:27 | <zewt> | it's just another style string, fed into the style immediately after @style |
| 23:27 | <dgorbik> | or any other webvtt-specific code |
| 23:27 | <zewt> | if you can't change anything at all then give up, your restrictions make doing anything useful impossible :) |
| 23:28 | <zewt> | if you want specs to be written so they can be implemented without changing any code, you're going to find that a tough sell |
| 23:29 | <esprehn_> | nah, there's a way to to do this |
| 23:29 | <dgorbik> | zewt: I think it makes the code harder to mainain also. In the approach esprehn_ suggested (by setting the RenderStyle directly, so we are doing it at another level, not markup but rendering level) makes it much easier to keep all those specific things in a couple of files. |
| 23:29 | <esprehn_> | I already discussed it |
| 23:29 | <zewt> | dgorbik: that's exactly the same thing as i'm saying--set the style at a level that doesn't require setting attributes |
| 23:30 | <esprehn_> | zewt: yeah, we just make the "style resolver" wise about WebVTT |
| 23:30 | <dgorbik> | zewt: I though you suggested setting those at the level of the renderstyle but then have a check so that the style property doesn't appear when we access it |
| 23:31 | <zewt> | no, set the style independently from @style, so the attribute never exists in the first place |
| 23:32 | <dgorbik> | zewt: that's what I am going to do |
| 23:40 | <esprehn_> | zewt: it's a bit more complex since what you describe is the wrong specificity. ::cue(b) { font-weight: normal; } should override the default of bold. |
| 23:41 | <esprehn_> | but if what you did was the equivalent of style="font-weight: bold" for all webvtt <b> elements you'd override the author sheet |
| 23:41 | <zewt> | esprehn: so apply the internal style before applying stylesheets (which itself is before @style) |
| 23:41 | <esprehn_> | exactly :) |
| 23:41 | <zewt> | "b a" isn't more complex than "a b" :) |
| 23:43 | <zewt> | for simple things like <b>, couldn't you just have ::cue(b) { font-weight: bold; } in the UA stylesheet |
| 23:45 | <dgorbik> | esprehn_: I still have to find out why b {color: red} didnt work for internal nodes when it was define in author rules. |
| 23:45 | <zewt> | (dynamic things like the results of the webvtt positioning algorithm being where you'd need direct control) |
| 23:45 | <dgorbik> | esprehn_: I will debug this case |
| 23:46 | <dgorbik> | probably UA rules are matched against ALL nodes on the page including those that are inside of the shadow dom. |
| 23:46 | <dgorbik> | but all the others don't |
| 23:51 | <esprehn_> | dgorbik: yes, that's how shadows work |
| 23:52 | <esprehn_> | dgorbik: at least I'm pretty sure user agent shadows don't let author sheets effect them |
| 23:54 | <abucur_> | hi! there's a paragraph in the web-apps spec stating that not all the events are dispatched using the task queue and that other are dispatched synchronously during other tasks. does anyone have an example for that? |