| 00:20 | <esprehn> | Hixie: is there a reason http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-mime-type mentions RFC2616 instead of RFC4288 which has the actual grammar in it? |
| 00:23 | <Hixie> | probably not |
| 00:24 | <esprehn> | okay, trying to understand the deal with mime types. Webkit tries to respect all the RFCs |
| 00:24 | <Hixie> | 2616 seems to have actual gramar too... |
| 00:24 | <esprehn> | Gecko completely ignores everything, in fact any mime type with the substring "xml" is considered XML in Firefox :/ |
| 00:25 | <Hixie> | where does 4288 define this? |
| 00:25 | <Hixie> | i don't see what i would reference in 4288 |
| 00:25 | <esprehn> | Hixie: I don't see the grammar in 2616 |
| 00:25 | <esprehn> | Hixie: http://tools.ietf.org/html/rfc4288#section-4.2 |
| 00:25 | <Hixie> | it's in the section mentioned |
| 00:26 | <Hixie> | that doesn't define what the html spec needs |
| 00:26 | <esprehn> | Hixie: the section doesn't say what chars are actually allowed in the parts |
| 00:26 | <Hixie> | sure, it then references other stuff |
| 00:27 | <esprehn> | none of those seem to say either |
| 00:27 | <esprehn> | at least not clearly that I could find |
| 00:27 | <Hixie> | fwiw, i expect in the medium term we'll be dumping all these references are referencing a new spec or mimesniff or some such, or defining it inline |
| 00:27 | <Hixie> | the mime type specs aren't as much of a mess as other things, but they're still pretty messed up |
| 00:28 | <zewt> | gave me headaches with the blob mime type stuff recently |
| 00:28 | <Hixie> | esprehn: "token" in the HTTP spec is defined in 2.2 |
| 00:28 | <Hixie> | esprehn: as "1*<any CHAR except CTLs or separators>" |
| 00:28 | <zewt> | (the whole "blob mime types shouldn't contain subtypes" thing, what an ugly mess) |
| 00:28 | <Hixie> | esprehn: which is the definition HTML is trying to use |
| 00:29 | <esprehn> | ah I see |
| 00:29 | <esprehn> | interesting |
| 00:30 | <esprehn> | 4288 is a lot more clear, I see the token = and CHAR but not section now though |
| 00:30 | <Hixie> | 4288 doesn't define this at all |
| 00:30 | <Hixie> | as far as i ca ntell |
| 00:30 | <Hixie> | it doesn't have a definition of media type as being type "/" subtype |
| 00:31 | <esprehn> | no, it specifies what type and subtype are |
| 00:31 | <zewt> | (the whole idea of "type/subtype" seems practically useless today, i just think of them as opaque strings) |
| 00:31 | <esprehn> | "Type and subtype names MUST conform to the following ABNF" |
| 00:31 | <Hixie> | esprehn: right but what the HTML spec needs is a definition of the format type / subtype ; parameter ; parameter |
| 00:31 | <esprehn> | right |
| 00:32 | <esprehn> | That's actually specified in a couple places |
| 00:32 | <esprehn> | to varying degrees of vagueness |
| 00:32 | <zewt> | ietf degrees |
| 00:33 | <Hixie> | esprehn: right |
| 00:33 | <Hixie> | esprehn: hence i picked one, rfc2616 :-) |
| 00:34 | <esprehn> | Hixie: should you be able to do things like DOMPaser.parseFromString(..., "text/html;charset=utf-8") ? |
| 00:36 | <esprehn> | oh I see parseFromString doesn't even really do mime types either |
| 00:36 | <esprehn> | http://domparsing.spec.whatwg.org/#dom-domparser-parsefromstring |
| 00:36 | <esprehn> | zewt: indeed they are opaue strings, marginally better than the guids that MS folks love so much |
| 00:37 | <zewt> | i'd say more than marginally (in that humans don't have to look them up every time), i'd just like the fiction of type/subtype to go away |
| 00:37 | <Hixie> | dunno, parseFromString isn't mine :-) |
| 00:37 | <esprehn> | I don't actually care about that, I just needed to know if the stuff for validating content types is correct in webkit |
| 00:37 | <Hixie> | the processing of mime types varies wildly from api endpoint to api endpoint |
| 00:38 | <Hixie> | i doubt that any single implementation can be consistently used in many places |
| 00:38 | <esprehn> | specifically XHR will only allow responseXML if we think it's XML or HTML |
| 00:38 | <Hixie> | the term in the html spec is mainly used for conformance checkers, not browsers |
| 00:38 | <Hixie> | ah well for XHR, see the XHR spec :-) xhr.spec.whatwg.org |
| 00:38 | <esprehn> | yes, it has an even more vague one that says effectively "any valid mime that ends in +xml" |
| 00:38 | <zewt> | i'd think it'd be simplest for responseXML to always work, as long as it's parsable (but no idea off-hand about security and webcompat concerns) |
| 00:39 | <Hixie> | esprehn: file a bug on anne :-) |
| 00:40 | <zewt> | do you have an :-) button |
| 00:40 | <Hixie> | esprehn: mimesniff.spec.whatwg.org is probably what we should link to |
| 00:40 | <esprehn> | Webkit matches the type/subtype against the grammar, Gecko you can return an XML file with hixie$$xml$$/webgl and you get responseXML since indexOf("xml") != -1 |
| 00:40 | <Hixie> | esprehn: dunno if it defines it yet |
| 00:40 | <Hixie> | zewt: on my phone, yes. but on the laptop, i have to type them. :-( |
| 00:40 | <esprehn> | I wonder if IE actually checks the format of the mime |
| 00:42 | <Hixie> | bbl |
| 00:42 | <zewt> | seems particularly odd since i'd guess that there are tons of formats that use xml where responseXML would be useful for, but which have their own mime types (not that i have any examples off the top of my head) |
| 00:45 | <esprehn> | zewt: per the spec they should all be foo/foo+xml as the mime |
| 00:46 | <zewt> | but i don't know what the practical value of restricting the responseXML feature to that is |
| 00:46 | <zewt> | but i'm not up to speed on that stuff |
| 00:47 | <esprehn> | dunno, ask anne |
| 00:47 | <esprehn> | the spec requires checks for responseXML |
| 06:43 | <hsivonen> | hmm. how long does it usually take for an email to appear in the Web archive on lists.w3.org? |
| 06:47 | <SimonSapin1> | hsivonen: minutes, at most? |
| 06:50 | <hsivonen> | SimonSapin1: it's been 16 minutes now without my message appearing |
| 06:52 | <SimonSapin1> | Did you get it back from being subscribed to the list? (Usually appears in the archives before that, for me) |
| 06:52 | <SimonSapin1> | Did you get an email asking for permission to publish it in the archives? (If you’ve never written to that list before and not given permission for all W3C lists) |
| 06:53 | <hsivonen> | SimonSapin1: I don't get my own messages back in general. I didn't get a permission email. |
| 06:54 | <hsivonen> | or if I do get my own messages back, Gmail hides them |
| 06:58 | <SimonSapin1> | I think Gmail hides them, I get them in Thunderbird with a custom MTA |
| 07:05 | <hsivonen> | ok. it took 30 minutes for the message to appear |
| 08:35 | <hsivonen> | what's the context of the latest meme on w3cmemes? I thought EME already supported CDNs. |
| 09:28 | <annevk> | smaug____: Polyglot is wring HTML and XHTML at the same time meeting the constraints of both |
| 09:32 | <tobie> | annevk: looking at the URLQuery interface of the URL spec, how are querys of the form …?foo=123&bar handled by the JS API? |
| 09:33 | <tobie> | annevk: more specifically: how do you set "bar" in the above example? |
| 09:34 | <tobie> | s/set/set or append/ |
| 09:34 | <annevk> | tobie: using set or append |
| 09:35 | <tobie> | annevk: what would you set the value to? |
| 09:35 | <tobie> | the empty string? |
| 09:35 | <tobie> | true? |
| 09:35 | <tobie> | not specify a value? |
| 09:35 | <annevk> | tobie: you'll get bar= |
| 09:36 | <annevk> | tobie: per IDL it ToString's the value |
| 09:36 | <annevk> | tobie: so empty string |
| 09:36 | <tobie> | what if what you want is ?foo=123&bar and not ?foo=123&bar= |
| 09:36 | <annevk> | you wouldn't use this API |
| 09:37 | <zcorpan> | should getDefaultComputedStyle apply presentational hints or not? |
| 09:37 | <annevk> | zcorpan: what does getDefault mean? |
| 09:37 | <tobie> | isn't that a serious shortcoming? |
| 09:37 | <zcorpan> | annevk: like getComputedStyle but without author styles (and always computed style instead of resolved style) |
| 09:38 | <annevk> | tobie: it matches what you can do with <form> |
| 09:38 | <tobie> | annevk: oh really? |
| 09:38 | <annevk> | tobie: the underlying format is shared |
| 09:39 | <annevk> | tobie: it's basically an API for application/x-www-form-urlencoded |
| 09:39 | <SimonSapin> | zcorpan: Re http://www.w3.org/Style/CSS/Tracker/issues/316 , the question is whether we should just remove the quirk or make it standard. The latter (#1hash is a valid ID selector) simplifies both specs and implementations. |
| 09:39 | <tobie> | aren't radio buttons and checkboxes sent as : bar rather than bar=? |
| 09:39 | <zcorpan> | SimonSapin: right. i'm saying we should remove the quirk. |
| 09:39 | <zcorpan> | SimonSapin: it's just IE that needs to change |
| 09:40 | <zcorpan> | SimonSapin: how does HASH simplify anything? |
| 09:40 | <SimonSapin> | and preserve the current standard behavior, ie. restrict ID selectors to #<ident>? Why? |
| 09:40 | <zcorpan> | SimonSapin: because it's what gecko/webkit/blink do in all their rendering modes |
| 09:40 | <annevk> | tobie: 'If the field element has a value attribute specified, then let value be the value of that attribute; otherwise, let value be the string "on".' |
| 09:40 | <zcorpan> | SimonSapin: why change? |
| 09:41 | <tobie> | annevk: darn it's been a while. Thanks for the clarification. |
| 09:41 | <SimonSapin> | with the restriction, the tokenizer needs a special case to detect #1hash vs. #\31hash, and a flag on hash tokens |
| 09:41 | <SimonSapin> | also, apparently HTML now allows id="1hash", and consistency is nice |
| 09:42 | <zcorpan> | SimonSapin: IDENT is used in other places than ID selectors, no? |
| 09:43 | <SimonSapin> | yes any keyword, but as a IDENT token, not a HASH token with the "id" flag |
| 09:43 | <zcorpan> | SimonSapin: HTML allows non-HASH IDs, too, so you're still not consistent |
| 09:44 | <zcorpan> | i'm not following |
| 09:45 | <SimonSapin> | That’s the definition for @id, right? http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute |
| 09:46 | <SimonSapin> | I was replying to "IDENT is used in other places than ID selectors, no?", but I’m not sure where you were going with this |
| 09:46 | <annevk> | zcorpan: so you're gonna expose the underdocumented user agent styles even more prominently? |
| 09:46 | <annevk> | maybe it'll help getting them aligned |
| 09:46 | <zcorpan> | SimonSapin: you said it would simplify the tokenizer |
| 09:49 | <zcorpan> | ok i see how it could simplify the tokenizer |
| 09:50 | <SimonSapin> | Yes. In the tokenizer, all of #ident #1hash and #\31hash are HASH tokens. Selectors say that ID selectors are '#' + IDENT, but it’s not tokenized that way. In particular, #1hash and #\31hash have the same parsed value but only the latter is a valid ID selectors. |
| 09:50 | <SimonSapin> | So we need to add a flag to HASH token, saying whether it had valid identifier syntax before un-escaping, and add behavior in the tokenizer to set that flag |
| 09:50 | <SimonSapin> | http://dev.w3.org/csswg/css-syntax/#hash-state |
| 09:51 | <SimonSapin> | It’s not terrible, but I find it a bit silly. |
| 09:51 | <zcorpan> | right |
| 09:52 | <SimonSapin> | (#1FF still has to be a valid HASH in case it’s a color) |
| 09:52 | <zcorpan> | we have interop in standards mode, and only one browser engine that is still maintained does it in quirks mode |
| 09:53 | <zcorpan> | the web compat impact of changing this in standards mode is not known |
| 09:53 | <SimonSapin> | Yes, we could just keep the current standard behavior. That’s least risky. |
| 09:53 | <SimonSapin> | But it’s also nice that authors don’t need to escape IDs that start with a digit, although it’s minor |
| 09:54 | <SimonSapin> | maybe it’s not worth spending so much time on this whole thing |
| 09:54 | <zcorpan> | being nice for authors is a valid argument though i don't remember seeing that argument being made until now :-) |
| 09:55 | <SimonSapin> | It’s hidden under consistency with HTML |
| 09:55 | <zcorpan> | HTML allows id="#" |
| 09:56 | <zcorpan> | and id="{};" |
| 09:56 | <SimonSapin> | which would need to be escaped in CSS: #\#, #\{\} |
| 09:56 | <zcorpan> | yes. so what's the difference between that and id="1"? |
| 09:57 | <SimonSapin> | digits are especially annoying to escape: \1 is U+0001, you have to use \31 for U+0031 |
| 09:57 | <SimonSapin> | a-f never need escaping |
| 09:59 | <SimonSapin> | but classes would still need to be escaped: class="1" → .\31 |
| 10:00 | <annevk> | tobie: btw, if you can collect feedback on desired URL comparison capabilities somehow that'd be awesome |
| 10:00 | <annevk> | tobie: (somewhat unrelated) |
| 10:01 | <tobie> | annevk: one thing I've had to do in the past was to check whether two urls were of the same origin |
| 10:02 | <annevk> | tobie: url.origin == url.origin will cover that |
| 10:02 | <tobie> | annevk: awesome. |
| 10:03 | <annevk> | things I've been thinking about: ignoring hash, ignoring hash and query/search, ignoring order in query/search, ignoring the trailing host dot |
| 10:03 | <tobie> | (had missed the origin property while skimming over the spec) |
| 10:03 | <tobie> | annevk: do you have an API in mind for this? |
| 10:04 | <tobie> | Just trying to have a better understanding of what you're looking at. |
| 10:08 | <zcorpan> | SimonSapin: consistency with classes seems important |
| 10:09 | <SimonSapin> | classes are tokenizer as DELIM(.) + IDENT. I guess we could add a token, but I don’t know if it’s worth it |
| 10:12 | <annevk> | tobie: something like url.isEqual(url/string, options) |
| 10:12 | <zcorpan> | classes would be even more silly that what we have with id selectors if we want to support starting with a number for both |
| 10:13 | <annevk> | tobie: I also kinda want url == url2 to work, but that would require it either becoming a native JS object, or overloading of == which does not exist yet |
| 10:13 | <SimonSapin> | that would mean a new token I suppose |
| 10:14 | <zcorpan> | except .1 still needs to be a NUMBER in other places |
| 10:14 | <asmodai> | The Unity guys also dropping Flash, even more focus on HTML/WebGL: http://blogs.unity3d.com/2013/04/23/sunsetting-flash/ |
| 10:14 | <tobie> | annevk: that would be cool. |
| 10:15 | <annevk> | C++ is getting URLs as a first-class citizen reportedly |
| 10:15 | <SimonSapin> | oh, yeah, a class token won’t work. .1 is a number, and .1foo is a dimension |
| 10:15 | <annevk> | (leaving the implementation of URLs undefined) |
| 10:20 | <tobie> | annevk: C++ has a lot of first-class citizens |
| 10:21 | <annevk> | tobie: but if we had operator overloading it wouldn't really matter if it was first-class or not I think |
| 10:21 | <annevk> | then everything is first-class |
| 10:21 | <tobie> | annevk: indeed. |
| 10:22 | <tobie> | Is operator overloading on the ES timeline? |
| 10:22 | <annevk> | my backchannel tells me ES7-8 |
| 10:23 | <tobie> | heh |
| 10:25 | <tobie> | I'm not looking forward to the amount of abuse operator overloading will create at first. |
| 10:25 | <zcorpan> | SimonSapin: (1.4% of all id="" attributes in http://webdevdata.org/ dec2012 start with a number) |
| 10:27 | <SimonSapin> | zcorpan: do you that kind of data for stylesheets? More important are invalid selectors that would break a page when they become valid |
| 10:28 | <zcorpan> | SimonSapin: webdevdata doesn't include external style sheets so it's a bit limited |
| 10:29 | <zcorpan> | SimonSapin: but if you can come up with a regexp that matches selectors you're interested in i can run it |
| 10:35 | <SimonSapin> | # is not special in regexps, is it? Try #[0-9][0-9a-zA-Z]*[g-zG-Z] , ie. a HASH token that starts with a digit but is not a hex color |
| 10:35 | <SimonSapin> | Also try #- although I suspect it’s be much less frequent |
| 10:35 | <zcorpan> | SimonSapin: the problem is not matching things that are not selectors in arbitrary HTML documents |
| 10:35 | <zcorpan> | including color:#123 |
| 10:36 | <zcorpan> | now trying: grep -aEi "<style(\d[^>]+)?>[^<\{]+([^<\{]+{[^<\{\}]+}[^<\{]*)*#\d" |
| 10:36 | <SimonSapin> | uh |
| 10:37 | <SimonSapin> | why \d in <style(\d[^>]+)?> ? |
| 10:37 | <zcorpan> | oops |
| 10:38 | <zcorpan> | meant \s |
| 10:39 | <zcorpan> | body #2degrees-click:hover {cursor:pointer;cursor:hand;} |
| 10:43 | <SimonSapin> | I think the consistency with classes is the strongest argument |
| 10:43 | <SimonSapin> | (Which is not that strong, but more so than anything else in this discussion.) |
| 10:45 | <zcorpan> | yeah |
| 10:45 | <zcorpan> | huh, i get a few results of the grep that don't even contain "<style" |
| 10:46 | <zcorpan> | anyway, assuming i didn't mess up the regexp, the above instance was the only id selector starting with a digit in the data set |
| 10:48 | <zcorpan> | which is http://www.3news.co.nz/ |
| 11:29 | <zcorpan> | http://www.w3.org/mid/50786331.6080905⊙me - what are override style sheets? |
| 11:30 | <gsnedders> | zcorpan: User stylesheets, no? |
| 11:30 | <zcorpan> | no (user style sheets was addressed later in the thread) |
| 11:30 | <gsnedders> | Then idk |
| 11:31 | <SimonSapin> | zcorpan: I’m not sure, but css-cascade refers to this: http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-OverrideAndComputed |
| 11:32 | <annevk> | zcorpan: SVG uses those I think for animations |
| 11:33 | <annevk> | zcorpan: the DOM had an API for that once too but it never got implemented |
| 11:48 | <zcorpan> | ok thanks |
| 12:14 | <zcorpan> | TabAtkins: was there a conclusion for this thread? http://www.w3.org/mid/CAAWBYDA2o-k+Jwd8wbEsuAFbHxubrPTjRt6gaaHZGOi4vkNRVQ⊙mgc |
| 12:27 | <zcorpan> | https://plus.google.com/100132233764003563318/posts/hqHFwvZhbDS |
| 12:29 | <hsivonen> | zcorpan: why a new tag instead of a facility to make <iframe> disconnect JS from parent? |
| 12:29 | <zcorpan> | don't ask me |
| 12:33 | <zcorpan> | there's also <webview>, apparently |
| 12:34 | <hsivonen> | zcorpan: the Firefox OS equivalent to <webview> is an attribute on <iframe> |
| 12:34 | <zcorpan> | hsivonen: does the attribute do anything for normal web pages? |
| 12:35 | <hsivonen> | zcorpan: Dunno. probably not. |
| 12:36 | <zcorpan> | hsivonen: what is the attribute called? |
| 12:38 | <MikeSmith> | mozbrowser? |
| 12:39 | <zcorpan> | https://developer.mozilla.org/en-US/docs/HTML/Element/iframe lists mozapp and mozbrowser |
| 12:54 | <annevk> | hsivonen: we regard the attribute as a mistake though |
| 12:54 | <mounir> | zcorpan: the attribute is ignored for normal web pages |
| 12:54 | jgraham | wonders who "we" is in this case |
| 12:55 | <annevk> | jgraham: implementer |
| 12:55 | <gsnedders> | jgraham: Ergh, getting pull requests on code that will conflict with all the flake changes. Yay. :| |
| 12:56 | <jgraham> | gsnedders: YEah, I need to finish your review :p |
| 12:56 | <gsnedders> | (I just rejected the pull request because it made us fail tests. :P) |
| 12:57 | <jgraham> | I saw |
| 13:01 | <zcorpan> | annevk: what should be used instead? |
| 13:01 | <zcorpan> | annevk: oh i see |
| 13:02 | <zcorpan> | annevk: you mean the attribute should work for normal web pages, too? |
| 13:04 | <zcorpan> | TabAtkins: why are custom properties case sensitive? |
| 13:05 | <annevk> | zcorpan: no, from what I read it would've been better as an element |
| 13:05 | <annevk> | zcorpan: makes an easier boundary |
| 13:06 | <zcorpan> | annevk: i don't follow |
| 13:06 | <mounir> | our goal is to move to something like <webview> |
| 13:08 | <SimonSapin> | zcorpan: the general principle is that author-defined stuff is case-sensitive: http://dev.w3.org/csswg/css-values/#custom-idents |
| 13:12 | <annevk> | Future.resolve(value) would be equal to Future.any(value)... I guess that's okay. |
| 13:32 | <zcorpan> | annevk: am i missing something or can i just say that getPropertyValue() must "serialize a CSS value" for the given property? https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-CSSStyleDeclaration-getPropertyValue-DOMString-DOMString-property https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#serializing-css-values |
| 13:35 | <annevk> | zcorpan: wouldn't that include !important? |
| 13:35 | <annevk> | zcorpan: it wasn't entirely clear whether !important should be there or not iirc |
| 13:35 | <annevk> | not sure what the other issues were |
| 13:36 | <annevk> | I wonder if I kept track of them somehow |
| 13:37 | <zcorpan> | "serialize a CSS component value" doesn't have an entry for !important |
| 13:37 | <annevk> | zcorpan: ah yeah, and then there's the thing with style.color being defined in terms of getPropertyValue, but actually potentially returning different values |
| 13:38 | <annevk> | I guess the latter does need to return !important but getPropertyValue doesn't or some such |
| 13:38 | <annevk> | overall though that API is broken and not a good time |
| 13:40 | <zcorpan> | !important doesn't seem to be returned by style.color |
| 13:41 | <annevk> | oh okay, so maybe it's all somewhat saner than my recollection :) |
| 13:42 | <zcorpan> | maybe :-) thanks |
| 13:52 | <zcorpan> | any opinion on null vs empty string for unknown properties? |
| 13:53 | <zcorpan> | chrome returns null, opera/firefox "" |
| 13:54 | <zcorpan> | ie10 "" |
| 14:09 | <annevk> | Hixie: I saw you introduced some nice terminology for worker-related stuff |
| 14:10 | <annevk> | Hixie: I'm thinking of sprinkling that around to XMLHttpRequest & friends, URL, FormData, Event?, Future |
| 14:10 | <annevk> | Hixie: is there anything I should be aware of? |
| 14:11 | <zcorpan> | annevk: he said in the relevant bug that he might tweak it some more |
| 14:13 | <annevk> | I know |
| 14:13 | <annevk> | hence the impatient IRC questions |
| 14:23 | <hsivonen> | annevk, mounir: ok. moving to something like <webview> is news to me |
| 15:25 | <marcosc> | tobie: how often are new released of Respec shipped? |
| 15:58 | <mounir> | hsivonen: that is not a long planned thing though |
| 16:09 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <jgraham> | gsnedders: It depends on fullTree=False, right? Which isn't really an internal API |
| 16:41 | <tobie> | marcosc: I usually bug darobin for this. |
| 16:42 | <tobie> | iirc, he sent me a list of instructions on how to do a release. |
| 16:42 | <tobie> | Will look for the, |
| 16:42 | <tobie> | s/the,/them/ |
| 17:01 | <Ms2ger> | Fwiw, it's not clear if <iframe mozbrowser> will stay |
| 17:01 | <Ms2ger> | Oh look, people said that |
| 17:02 | <gsnedders> | jgraham: Regardless, the existing code was broken. :P |
| 17:07 | <annevk> | dglazkov: lets discuss it in the week of May 6 |
| 17:07 | <annevk> | dglazkov: I'm not at this TPAC thing you speak of |
| 17:07 | <annevk> | dglazkov: well, at least not one that's running this week |
| 17:18 | <gsnedders> | jgraham: Okay, if you're using a non-standard etree API which allows access to parents then it can leak. But that's it, I believe. |
| 17:19 | <gsnedders> | jgraham: (The existing code is totally b0rked because it tries to use JS scoping rules in PYthon.) |
| 17:22 | <jgraham> | gsnedders: What am I missing? You can call getEtreeBuilder with fullTree=True |
| 17:22 | <jgraham> | And then you get that node out |
| 17:23 | <gsnedders> | jgraham: But then html5lib.parseFragment cuts it off, no? |
| 17:26 | <jgraham> | If you call parseFragment you can't set fullTree, so I don't see how that's relevant |
| 17:27 | <gsnedders> | I dunno, and I have doomexam tomorrow, so I'm not looking at it. |
| 17:27 | <jgraham> | You can do something like builder = getTreeBuilder("etree", fullTree=True) |
| 17:28 | <jgraham> | HTML5Parser(builder) |
| 17:28 | <jgraham> | .parseFragment |
| 17:28 | <jgraham> | Well if you have an exam, why are you here chatting? |
| 17:29 | <jgraham> | (I think the only real fix I want is the error to be something better. I don't see the point of going out of our way to support an edge case) |
| 17:35 | <TabAtkins> | zcorpan: Custom properties are case-sensitive because they can contain arbitrary unicode, and we didn't want either (a) unicode case-insensitive matching, nor (b) ascii-case-insensitive matching mixed with non-ascii literal matching. |
| 17:35 | <TabAtkins> | zcorpan: Only way around that was to just say that it's entirely case-sensitive. |
| 17:36 | <TabAtkins> | zcorpan: Also, what SimonSapin said - author-defined stuff is generally case-sensitive (for the reasons I gave, though). |
| 17:37 | <SimonSapin> | TabAtkins: by, the way, css-counter-styles is a bit weird regarding this |
| 17:38 | <SimonSapin> | "Counter style names are case-sensitive. However, the names defined in this specification are ASCII lower-cased on parse wherever they are used as counter styles, e.g. in the list-style set of properties, in the @counter-style rule, and in the counter() functions." |
| 17:38 | <SimonSapin> | The two sentences seem contradictory |
| 17:39 | <SimonSapin> | But I got it later: "the names defined in this specification" shoud be "the name of pre-defined counter styles", with links to section 5 and 6 |
| 17:39 | <SimonSapin> | (Which, by the way, is a bit annoying to implement but meh.) |
| 17:49 | <TabAtkins> | SimonSapin: Yes, the names defined *in* this spec. ^_^ |
| 17:49 | <TabAtkins> | SimonSapin: And I'm sure it's annoying to implement, but that's what you get when you invade an existing namespace. |
| 17:50 | <SimonSapin> | yeah, the implementation is manageable |
| 17:51 | <TabAtkins> | By "you invade" I of course mean "I invade". |
| 17:51 | <SimonSapin> | But I’m still having a hard time with "names defined in this spec". |
| 17:51 | <TabAtkins> | Hm? |
| 17:51 | <SimonSapin> | like, <counter-style-name> is defined in this spec |
| 17:51 | <TabAtkins> | ?_? |
| 17:52 | <TabAtkins> | (?_? is the best emoji, by the way. The question marks look like raised eyebrows!) |
| 17:52 | <SimonSapin> | It took me a long time to understand that this means just the names of predefined styles, not all counter style names |
| 17:53 | <TabAtkins> | Should I change it to "the names of counter styles defined in this specification"? |
| 17:53 | <SimonSapin> | I’d like the spec to clarify, by saying something like "the name of predefined styles" |
| 17:54 | <SimonSapin> | "predefined" indicates "these particular instances" rather than "the general concept of counter styles" |
| 17:54 | <TabAtkins> | Works for me. |
| 18:01 | <annevk> | can't you spell it out in the parser? |
| 18:02 | <TabAtkins> | annevk: In what parser? |
| 18:02 | <annevk> | the value parser I guess |
| 18:02 | <TabAtkins> | Not really, no. |
| 18:02 | <TabAtkins> | Or rather, not without a lot of difficulty. |
| 18:02 | <TabAtkins> | Given the context-sensitivity. |
| 18:02 | <annevk> | don't you have a value parser per property? |
| 18:02 | <SimonSapin> | annevk: spell what out? |
| 18:03 | <TabAtkins> | We have *grammars* per property, which verify that the parsed value is correct per the property's grammar. |
| 18:03 | <annevk> | hmm |
| 18:03 | <TabAtkins> | Actual parsing is taken care of by a generic error-handling parser, which doesn't care about the individual property grammars. |
| 18:03 | <TabAtkins> | (Otherwise we'd have to amend the parser every time we add a new property or value.) |
| 18:14 | <marcosc> | tobie: thanks for the info |
| 19:14 | <reyre_pc> | in regards to WEBVTT -- is there a way that users can add cuetext via java script? |
| 19:14 | <reyre_pc> | we see currently that they can add and create TextTrackCues via javascript |
| 19:28 | <reyre_pc> | nvm all, i think we've solved the question |
| 19:45 | <zcorpan> | reyre_pc: you mean modify the text of an existing cue? |
| 19:46 | <reyre_pc> | zcorpan: yeah that's what we realized |
| 19:46 | <zcorpan> | ok. so cue.text :-) |
| 19:46 | <reyre_pc> | zcorpan: if a cue's cue text is modified via script is there a way to detect that it happened |
| 19:46 | <zcorpan> | ho |
| 19:46 | <zcorpan> | oh, even |
| 19:46 | <reyre_pc> | i know there are events for adding and removing cues to a text track |
| 19:47 | <reyre_pc> | but haven't seen any for cuetext changing |
| 19:50 | <zcorpan> | there's no event for that afaict |
| 19:50 | <zcorpan> | what's the use case? |
| 19:54 | <zcorpan> | Hixie: does the webvtt spec need to be updated to say to run "time marches on" when .text, .align, etc, are set? |
| 19:54 | <reyre_pc> | zcorpan: a user changes a cues cuetext. we want to use lazy loading so we'd like a way to know that the cue's cuetext has changed |
| 19:55 | <zcorpan> | reyre_pc: how does the user change cuetext? do you need to know internally or want to expose to scripts on the page? |
| 19:56 | <reyre_pc> | well as far as we understand you can grab cues from the dom via their identifiers in javascript |
| 19:56 | <zcorpan> | yes or just iterate through them |
| 19:56 | <reyre_pc> | then you can set that TextTrackCues 'text' member |
| 19:56 | <reyre_pc> | changing the cuetext |
| 19:56 | <zcorpan> | by user you mean author (the web developer), not the end-user? |
| 19:57 | <reyre_pc> | well, whoever wants to use java script to manipulate cues on a webpage |
| 19:58 | <reyre_pc> | we'd like to know internally so we can know when to re-parse the cuetext |
| 20:02 | <zcorpan> | ok. i guess you need to have an internal listener for changes to the .text attribute or so. how to do that is an implementation detail |
| 20:02 | <rillian> | reyre: I didn't think of cue.text ouch |
| 20:02 | rillian | bets that's broken everywhere |
| 20:02 | <reyre> | zcorpan: okay thanks for clarifying :) |
| 20:02 | <reyre> | rillian: oh noe |
| 20:02 | <zcorpan> | i think the webvtt spec needs to say to run the "time marches on" steps when .text et al are set |
| 20:03 | <zcorpan> | like e.g. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-texttrackcue-starttime does |
| 20:05 | <reyre> | zcorpan: makes sense |
| 20:08 | <zcorpan> | oh wait that's covered already, fixed in http://html5.org/tools/web-apps-tracker?from=7429&to=7430 |
| 20:09 | <zcorpan> | end of http://dev.w3.org/html5/webvtt/#data-model |
| 20:11 | <reyre> | zcorpan: okay, saw that one before but was unsure about it |
| 20:11 | <reyre> | thanks :) |
| 20:11 | <zcorpan> | np |
| 20:15 | <TabAtkins> | Where's the best version of WebVTT to link to? |
| 20:15 | <manu-db> | Provided without comment: What's wrong with DRM in HTML5: http://yro.slashdot.org/story/13/04/24/209234/whats-actually-wrong-with-drm-in-html5 |
| 20:19 | <rillian> | TabAtkins: http://dev.w3.org/html5/webvtt/ was the last place Silvia mentioned updating |
| 20:19 | <rillian> | that's not a frozen publication though |
| 20:20 | <TabAtkins> | rillian: Not a concern. |
| 20:20 | <TabAtkins> | rillian: I just need somewhere to point to as an example of the time-based selectors. |
| 20:39 | <MikeSmith> | TIL I learned in the HTML WG f2f that we don't actually need to do testing any more to determine interoperability |
| 20:39 | <MikeSmith> | we just get to decide |
| 20:39 | <MikeSmith> | spread the word |
| 20:41 | <TabAtkins> | Yay! |
| 20:46 | <cabanier1> | http://t.co/HA2sgpjs3z |
| 20:48 | <zcorpan> | TabAtkins: should the spec say something differently for presentational hints? |
| 20:50 | <TabAtkins> | cabanier1: Please pre-resolve your t.co links before posting. ^_^ http://w3cmemes.tumblr.com/post/48714963874/we-dont-need-a-comprehensive-test-suite-to-exit |
| 20:50 | <TabAtkins> | zcorpan: Lemme check, I didn't actually look at the text. |
| 20:50 | <zcorpan> | TabAtkins: do you have an example of UA-level preshint? |
| 20:51 | <TabAtkins> | zcorpan: Anything in the UA stylesheet. For example, the styling of <i> is, technically, a preshint. |
| 20:51 | <TabAtkins> | Difference is just whether we arbitrarily decide it's a "user-agent default" or an "author choice". |
| 20:51 | <zcorpan> | TabAtkins: oh. i thought that wasn't called preshint |
| 20:52 | <TabAtkins> | Meh, depends on where you're looking perhaps. |
| 20:52 | <TabAtkins> | In casual conversation it has been called such, at least. |
| 20:52 | <TabAtkins> | Where is the function actually defined? |
| 20:52 | <zcorpan> | https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-Window-getDefaultComputedStyle-CSSStyleDeclaration-Element-elt-DOMString-pseudoElt |
| 20:55 | <TabAtkins> | Nope, spec's fine, since all of those things are qualified with "author-level". |
| 20:56 | <TabAtkins> | zcorpan: The issue on serializing <number> can go away, since we allow scinot in numbers now. |
| 20:56 | <TabAtkins> | zcorpan: And I don't understand the issue in <length>. |
| 20:56 | <zcorpan> | author-level was only intended to apply to "author-level style rules" |
| 20:57 | <TabAtkins> | zcorpan: In that case, move it to further down in the list. Leading adjectives normally distribute over lists. |
| 20:59 | <TabAtkins> | But if you qualify "preshints" with "author-level", it's completely correct and non-ambiguous. |
| 21:06 | <zcorpan> | ok fixed |
| 21:08 | <TabAtkins> | zcorpan: Looks good! |
| 21:08 | <zcorpan> | thanks |
| 21:12 | <GPHemsley> | Are there UAs on board with implementing DRM? (If this question opens a can of worms, ignore it.) |
| 21:14 | <TabAtkins> | Sigh, yes. IE, Chrome, and Safari are all doing it, I believe. |
| 21:14 | <TabAtkins> | Firefox is the holdout. |
| 21:14 | <TabAtkins> | For now. |
| 21:15 | <GPHemsley> | Ah, so, same as it ever was. |
| 21:18 | <TabAtkins> | zcorpan: Btw, no conclusion on the constructable stylesheets thread. We're not to the point of needing to decide on it yet, so feel free to ignore it. We'll poke if it comes up again. |
| 21:18 | <TabAtkins> | (Not to say that I wouldn't mind more constructable things, but I don't have a use-case for them right now.) |
| 21:18 | <zcorpan> | TabAtkins: ok thanks |
| 21:20 | zcorpan | marks that thread as read |
| 21:26 | <zcorpan> | annevk: https://github.com/whatwg/url/commit/1d866b441eef031481bffaa0df9f43630e6fe62e - it's not just when setting .href to something that doesn't resolve, it's setting it to any value |
| 21:31 | <MikeSmith> | HTML WG f2f update; current status: suffering fools unlightly |
| 21:32 | <hober> | MikeSmith: . |
| 21:34 | <jgraham> | I thought one suffered fools gladly |
| 21:34 | <jgraham> | How do you do it (un)lightly? |
| 21:34 | <jgraham> | And is that the same as suffering them heavily? |
| 21:35 | <jgraham> | I sort of imagine that you are all starting to sound like Neil from The Young Ones |
| 21:44 | <dlongley> | TabAtkins: when calling a function that returns a Future, if that function should throw an exception when too few arguments are passed, should it be done via throw via the resolver's reject mechanism? |
| 21:45 | <dlongley> | when using w3c's idl test harness for WebIDL implementations, functions that return a Future are expected to throw TypeErrors if the number of arguments given is insufficient ... |
| 21:45 | <dlongley> | but this is problematic if you're wrapping something that uses a callback style API -- as the error will not be returned (via the callback) until the Future has actually been resolved (rejected) |
| 21:46 | <dlongley> | i'm hoping that you agree that this is a bug with the idl test harness ... and that if a function returns a future it should be checking that Future for a rejection, rather than looking for exceptions thrown in the method that generates the Future. |
| 21:46 | <dlongley> | anyone else in here know anything about DOM Futures? |
| 22:27 | <TabAtkins> | dlongley: Just plain throwing is the same thing as calling reject. |
| 22:37 | <TabAtkins> | annevk: Does "url" imply hierarchical? Context is us defining the :local-link pseudoclass - need a term for something with hierarchy, such that we can match urls against a subset of the url. |
| 22:40 | <Hixie> | no; data: URLs have no hierarchy, but are still URLs |
| 22:40 | <Hixie> | the url spec has a concept of "relative scheme" |
| 22:40 | <Hixie> | which may be what you want |
| 22:41 | <Hixie> | (you probably just want a url that resolves to a parsed url with a relative scheme, and that has the same scheme, host, and port as the reference url) |
| 22:51 | <TabAtkins> | No, not relative scheme. |
| 22:51 | <TabAtkins> | :local-link(n) matches urls who match the document's url up to the first n segments. |
| 22:51 | <Hixie> | did i get the name wrong? |
| 22:51 | <Hixie> | oh |
| 22:51 | <Hixie> | segment? |
| 22:52 | <TabAtkins> | Yes, url segments. Defined in the url spec. |
| 22:52 | <TabAtkins> | The parts of scheme data in between /s and ?. |
| 22:52 | <Hixie> | oh, wow, i had no idea the url spec actually went to the level of detail of path segments |
| 22:52 | <Hixie> | cool |
| 22:52 | <TabAtkins> | Now I just need it to go into a little bit more details, so I can ref it instead of just assuming that people will get what I mean when I say "if the url is hierarchical". ^_^ |
| 22:53 | <TabAtkins> | annevk: Please add the concept of "hierarchical URL" to the URL spec, so I can ref it from the Selectors definition of :local-link(). |
| 22:55 | <Hixie> | i don't understand what you mean by hierarchical URL if you don't mean "has a relative scheme", btw |
| 22:58 | <TabAtkins> | Hixie: Scheme-relative just refers to a url without a specified scheme (so when it absolutized, it takes its scheme from the document). It has nothing to do with hierarchy, I think. |
| 22:58 | <Hixie> | not "Scheme-relative", "relative scheme" |
| 22:59 | <Hixie> | (anne graduated from my school of confusing naming, i think :-) ) |
| 22:59 | <TabAtkins> | I don't know what that means, because it doesn't have a real definition, just a pointer to a table. |
| 23:00 | <Hixie> | if i'm not mistaken, the parser treats urls with "relative schemes" differently than those without |
| 23:00 | <Hixie> | namely, it parses a path out only if it's relative, i think |
| 23:00 | <TabAtkins> | Maybe, but if so, Anne has left that detail encoded in the parser, rather than stating it directly. ^_^ |
| 23:01 | <TabAtkins> | I'd still prefer a "hierarchical url" term to refer to, rather than having to say "a url with a relative scheme". |
| 23:02 | <Hixie> | no argument from me there |
| 23:12 | <zcorpan> | TabAtkins: http://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk |
| 23:29 | <Hixie> | cabanier1: yt? |
| 23:50 | <TabAtkins> | tantek: Why did you recommend using rel=discussion? It's not yet registered in the Microformats wiki. |
| 23:53 | <TabAtkins> | zcorpan: Looks good to em. |
| 23:57 | <TabAtkins> | zcorpan: What's the meaning of the plain <span>s in the markup? It looks like they should be <i> (for a technical term) and/or links. |
| 23:57 | <fantasai> | http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element |