00:23
<MikeSmith>
caitp: yeah in contrast the pieces of the Web platform all fit together super elegantly well
00:24
<caitp>
the sarcasm is appreciated
00:24
<SamB>
caitp: well that's good, because otherwise you'd have totally misunderstood him
00:26
<caitp>
my argument that shoving XML into HTML doesn't really fit doesn't necessarily mean that everything else fits together well, but it doesn't necessarily help the situation
00:27
<caitp>
it will be interesting to see how that plays out, and if it can be made to sort of work
00:39
<JonathanNeal>
If I want to use SVG over webfont and use it across domains then I'm going to need to hack.
00:44
<JonathanNeal>
Which probably means an XHR request and access headers, if I can even do that with an SVG. I can imagine it now, JSVN (Jay-Sven, JavaScript Vector Notation) and JSVNP.
00:57
<MikeSmith>
JonathanNeal: btw what's the level of support for img@crossorigin is browsers?
00:57
<MikeSmith>
caniuse tells me nothing
00:58
<JonathanNeal>
MikeSmith: I don't know, and I will be testing as soon as I can get on the laptop.
01:00
<MikeSmith>
JonathanNeal: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image indicates it's been supported in Chrome and Firefox for a long time
01:01
<MikeSmith>
there are some things that Alexis doesn't add to to caniuse even when they already have browser support. I don't understand why
01:01
<caitp>
maybe nobody has tried to add it yet?
01:02
<caitp>
they take patches
01:02
<caitp>
i don't see any issues about CORS wrt images
01:05
<JonathanNeal>
Well, SVG is a special kind of image, in that it's a kind of readable.
01:06
<MikeSmith>
writing a canisuse patch requires me to first have tests, or write the tests myself
01:06
<MikeSmith>
which I suspect is why Alexis hasn't added it
01:07
<MikeSmith>
he doesn't add stuff without tests
01:10
<SamB>
I assume the point of using CORS with an img is to keep it untainted?
01:26
<JonathanNeal>
It looks like even with CORS, IE9-11 is out of the picture.
04:15
<zcorpan>
Hixie: will the broken ndash and dots fix themselves in your new pipeline? See first example in introduction
09:28
<musically_ut>
I have a question about the CORS specification which probably has been discussed on some mailing list. Where should I post the question or search for answers?
09:45
<MikeSmith>
musically_ut: whatwg⊙wo or public-webappsec⊙wo
09:46
<musically_ut>
MikeSmith, Thanks. Is there a web-frontend to search those mailing lists?
09:46
<MikeSmith>
musically_ut: or ping annevk here when he's around (he wrote the spec)
09:46
<MikeSmith>
musically_ut: yeah lists.w3.org
09:46
<musically_ut>
I could write him an e-mail but I'd rather do some research myself first. :)
09:47
<musically_ut>
Perfect.
09:47
<MikeSmith>
the whatwg list archives are at http://lists.w3.org/Archives/Public/public-whatwg-archive/
09:48
<MikeSmith>
musically_ut: note that Anne has folded CORS into the Fetch spec
09:48
<musically_ut>
Huh .. April 2004 was the 10 year anniversary of whatwg. I never made the connection.
09:48
<musically_ut>
* April 2014
09:48
<MikeSmith>
so the standalone CORS spec is obsolete
09:48
<MikeSmith>
no this month was the anniversary of the whatwg actually
09:49
<musically_ut>
:)
09:49
<musically_ut>
http://www.w3.org/TR/cors/ doesn't seem to suggest that the spec has become obsolete.
09:50
<MikeSmith>
April was the 10 year anniversary of the HTML spec (aka WebApps 1.0 aka HTML5) https://github.com/whatwg/web-history#2004-04
09:50
<MikeSmith>
musically_ut: never use anything in http://www.w3.org/TR/
09:50
musically_ut
raises eyebrows.
09:50
<MikeSmith>
seriously
09:51
<MikeSmith>
always use either the Editor's Draft version that corresponds to whatever's in http://www.w3.org/TR or find out whatever has replaced it
09:52
<musically_ut>
What does "TR" in the URL stand for?
09:52
<MikeSmith>
the documents in http://www.w3.org/TR can pretty much always be considered out of date
09:52
<MikeSmith>
Technical Report
09:52
<musically_ut>
Ah.
09:53
<MikeSmith>
anyway as far as CORS, I think the WebAppSec WG is still maintaining a separate spec but the browser implementors are implementing from Fetch now
09:53
<MikeSmith>
or should be
09:53
<musically_ut>
This is rather confusing. http://www.w3.org/TR/ lists neither Fetch nor CORS TR.
09:53
<musically_ut>
But I did not know about the cumulative Fetch specs.
09:54
<musically_ut>
I have found them here: http://fetch.spec.whatwg.org/#http-cors-protocol
09:54
<MikeSmith>
yeah sorry for the confusion but it's not unique to this case
09:54
<MikeSmith>
musically_ut: yeah http://fetch.spec.whatwg.org is what you want to be reading
09:54
<musically_ut>
Excellent.
09:57
<musically_ut>
Okay, I'll search the archives a bit to see if I can find an answer. Otherwise, you'll hear from me on the mailing list. :)
09:57
<MikeSmith>
btw we're trying to do some things to deal with the http://www.w3.org/TR confusion problem but it's taking some time because there's a lot of politics and inertia that get in the way
09:57
<MikeSmith>
musically_ut: sounds great. cheers
09:57
<musically_ut>
What is the plan with www.w3.org/TR then?
09:58
<Ms2ger>
Ignore it
09:58
<MikeSmith>
the plan is to make it always provide up-to-date info about what the latest version of every spec is
09:58
<musically_ut>
up-to-date == github master branch?
10:00
<MikeSmith>
but in the mean time you can ignore TR or least any time you look at a doc in http://www.w3.org/TR you should check the top of it to see if it lists a "Latest Editor's Draft" link
10:00
<MikeSmith>
and if it does, use the document at that link
10:00
<Ms2ger>
And if it doesn't, still try to find one :)
10:00
<MikeSmith>
and if it doesn't then be very suspicious
10:00
<MikeSmith>
yeah
10:00
<musically_ut>
:)
10:01
<musically_ut>
So if it doesn't have an editor draft then it has very likely been made obsolete?
10:01
<MikeSmith>
well
10:01
<MikeSmith>
yeah, basically
10:01
<MikeSmith>
either that or it's not relevant at all to begin with
10:02
<musically_ut>
Great. Thanks for the tips, MikeSmith and Ms2ger
10:02
<MikeSmith>
there are many documents at http://www.w3.org/TR that have absolutely nothing to do with the Web platform so you don't need to care about them at all
10:03
<MikeSmith>
musically_ut: http://platform.html5.org is a much better index of what's relevant
10:04
<MikeSmith>
Ms2ger: do you know if all floating-point numbers are allowed in CSS length values?
10:05
<Ms2ger>
I don't
10:07
<musically_ut>
Ah, nice.
10:10
<MikeSmith>
well I find http://dev.w3.org/csswg/css-values/#number-value which says "A number is either an <integer> or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits." but then it also says "It corresponds to the <number-token> production in the CSS Syntax Module." and TabAtkins railroad diagram at http://dev.w3.org/csswg/css-syntax-3/#number-token-diagram suggests it can be any floating-point number, not just "either an
10:38
<MikeSmith>
TabAtkins: I'm trying to figure out if, e.g., 100e+0vw is a valid length value or not
10:39
<MikeSmith>
TabAtkins: because I'm trying to write an error-reporting @sizes parse for the validator
10:39
<MikeSmith>
*parser
14:38
<TabAtkins>
MikeSmith: Trust the specified parser.
14:38
<TabAtkins>
100e+0vw is valid.
14:39
<TabAtkins>
I need to update V&U to take the scinot change into account.
14:48
<TabAtkins>
MikeSmith: Fixed now.
19:17
<MikeSmith>
TabAtkins: Coolーthanks!
19:22
<TabAtkins>
MikeSmith: To write a good sizes parser, you'll want to write a full css parser, which is trivial to do by following the Syntax spec.
19:22
<TabAtkins>
And is much smaller than an html parser. ^_^
19:38
<MikeSmith>
TabAtkins: for the validator I need the parser to be error-reporting, which I think can make the implemented algorithm need to be somewhat different from the spec
19:39
<MikeSmith>
at the very least it means I basically need to infer some parse errors based on the corresponding authoring requirements
19:40
<MikeSmith>
e.g., at http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#parse-a-sizes-attribute where it says "Remove all consecutive <whitespace-token>s from the end of unparsed size. If unparsed size is now empty, continue to the next iteration of this algorithm.", I need to emit an error for the "If unparsed size is now empty" condition