On 2014-12-11 09:09, Simon Pieters wrote:
The spec's parsing rules of meta refresh causes infinite reloading on
some pages. In particular, the spec requires the url= to be present,
but there are pages that omit it. IE9 also requires url= apparently.
Gecko/Blink/WebKit allow url= to be omitted.
On 2015-01-07 08:52, Simon Pieters wrote:
...
I hear (a) these pages have been broken in IE for a long time, and (b)
only 23 (?) pages in your DB are found.
Right.
So why not just leave them broken?
It's a worse user experience and it's a shorter path to interop to
change IE.
...
User
Hi there,
I have a use case where a certain location in a document can have two
anchors (or even more). For instance, in a spec, the author may have
specified an anchor, but a section-number based anchor is required as well.
Right now I can address this by inserting an additional div
On 2014-12-03 15:02, Jukka K. Korpela wrote:
2014-12-03, 15:49, Julian Reschke wrote:
I have a use case where a certain location in a document can have two
anchors (or even more). For instance, in a spec, the author may have
specified an anchor, but a section-number based anchor is required
On 2014-07-16 11:31, Arpita Bahuguna wrote:
Hi Julian,
Thank-you for your views.
Are you suggesting that we instead introduce a new link relation
(perhaps contact) with tel:/mailto: types for specifying these parameters?
This would involve spec modification. Not sure how developers or browser
On 2014-07-16 12:01, Arpita Bahuguna wrote:
Hi Julian,
Please find my comments inline:
-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Julian
Reschke
Sent: Wednesday, July 16, 2014 3:10 PM
To: Arpita Bahuguna
Cc: wha...@whatwg.org; Arpita Bahuguna
On 2014-07-15 12:11, Arpita Bahuguna wrote:
Hi,
I would like to propose addition of the following three meta extensions:
website-mail, website-number and website-address.
Please find below a detailed description for each.
--- x - x
On 2014-05-23 06:53, Michael Heuberger wrote:
Hi James
Single page apps!
These become more and more popular with frameworks like RactiveJS or
AngularJS. There the first request is a HTTP request, for any subsequent
requests an AJAX one is generated. The problem is the first HTTP
AJAX
On 2013-09-13 12:32, Robin Berjon wrote:
On 29/08/2013 15:58 , Simon Pieters wrote:
On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald
jaffathec...@gmail.com wrote:
Causing a network error in existing browsers is a
On 2013-06-05 00:25, Rodrigo Polo wrote:
I really don't want to fight over any issue, I, as a user, want to share
with you the current state on this topic and (as I said on the letter) with
a friendly open letter in the pursuit to make a polite request to make the
life of millions easier give
On 2013-06-05 13:27, Rodrigo Polo wrote:
Hi, well, the kind of support I think should be implemented is
actually something that should be a standard, any anchor that have a
mailto:; inside is supported out of the box in any web browser and the
first time it is clicked the web browser asks for
On 2013-06-05 14:00, Rodrigo Polo wrote:
You are completely right, but in the tests I made on Chrome the geo
URI handler can't be used with the registerProtocolHandler call,
it throws a security error and the use of geo location URI it is not
included as a recommendation or good practice when we
On 2013-03-17 02:49, Jonas Sicking wrote:
It's currently unclear what to do if a page contains markup like a
href=page.txt download=A.txt if the resource at audio.wav
responds with either
1) Content-Disposition: inline
2) Content-Disposition: inline; filename=B.txt
3) Content-Disposition:
On 2013-03-13 21:24, Boris Zbarsky wrote:
On 3/13/13 4:23 PM, Julian Reschke wrote:
Under RFC 3986, it would resolve to
jar:http://example.com/Bar.class
If you assume that this is a hierarchical scheme and that the hierarchy
is in some particular place, no? Why is that assumption being
On 2013-03-13 18:38, pocci...@gmail.com wrote:
(This was originally a bug report, but I was told to e-mail instead. Another
issue is also added.)
-- Non-relative URLs in the query string --
Earlier I posted an issue with serializing the query in non-relative URLs. But
after
I read more about
On 2013-03-13 21:14, Boris Zbarsky wrote:
On 3/13/13 4:02 PM, Julian Reschke wrote:
On 2013-03-13 18:38, pocci...@gmail.com wrote:
jar:http://example.com/jar?x=1!/com/example/Foo.class
is parsed in the URI standards as:
scheme - jar
scheme-specific part - http://example.com/jar?x=1!/com
On 2013-01-08 01:47, Ian Hickson wrote:
The next best choice would be to have datetime-with-timezone but
unfortunately
(1) Official database for all timezones does not exist
(2) Official timezone names (or labels) do not exist
(3) Timezones are subject to future political decisions
The
On 2012-11-29 20:25, Adam Barth wrote:
These are supported in Chrome. That's what causes the download. From
Can you elaborate about what you mean by supported? Chrome sniffs for
the type, and then offers to download as a result of that sniffing? How
is that different from not sniffing in
On 2012-12-04 08:40, Adam Barth wrote:
On Mon, Dec 3, 2012 at 12:39 PM, Julian Reschke julian.resc...@gmx.de wrote:
On 2012-11-29 20:25, Adam Barth wrote:
These are supported in Chrome. That's what causes the download. From
Can you elaborate about what you mean by supported? Chrome sniffs
On 2012-11-17 19:17, Adam Barth wrote:
...
I would prefer if the spec described what implementations actually do
rather than your opinion about what they should do. To answer your
specific questions:
...
That works well if something is widely supported already. It works less
well if you have
On 2012-11-19 19:27, Adam Barth wrote:
On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 2012-11-17 19:17, Adam Barth wrote:
...
I would prefer if the spec described what implementations actually do
rather than your opinion about what they should do. To answer
On 2012-10-31 10:21, Nicolas Froidure wrote:
Hi,
I think we need a specification to allow users to report websites
bugs from their browser. That's why i think it could be usefull to add a
meta markup like this :
meta name=bugreport content=(uri) /
link, not meta.
The uri
On 2012-10-19 14:01, Nils Dagsson Moskopp wrote:
A. Rauschenbach rauschenb...@annuo.de schrieb am Fri, 19 Oct 2012
13:50:04 +0200:
I'm sick of coping the checksum of important files by hand or QR-code
to the download manager or console.
To solve the problem I suggest a checksum attribute in
On 2012-10-09 13:51, Anne van Kesteren wrote:
On Tue, Oct 9, 2012 at 1:50 AM, Ian Hickson i...@hixie.ch wrote:
On Sat, 10 Sep 2011, Daniel Holbert wrote:
I'm writing with a proposal to improve the handling of # in data URIs.
I'm particularly looking for feedback from other browser vendors, but
On 2012-10-09 17:33, Anne van Kesteren wrote:
On Tue, Oct 9, 2012 at 4:59 PM, Julian Reschke julian.resc...@gmx.de wrote:
The test case at
http://greenbytes.de/tech/tc/datauri/#svg
seems to imply that Opera doesn't do this right yet, though. (tested with
12.02)
Yeah, for some reason
On 2012-09-21 17:16, Anne van Kesteren wrote:
I took a crack at defining URLs: http://url.spec.whatwg.org/
At the moment it defines parsing (minus domain names / IP addresses)
and the JavaScript API (minus the query manipulation methods proposed
by Adam Barth). It defines things like setting
On 2012-07-09 23:01, Ian Hickson wrote:
On Thu, 3 May 2012, Evan Jones wrote:
On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
Yes. I think we should define multipart/form-data directly in HTML and
thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated
and not maintained.
On 2012-06-04 09:32, Kornel Lesiński wrote:
On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development
i...@anselm-hannemann.com wrote:
An alternative is to pick different delimiters. See, for instance,
http://tools.ietf.org/html/rfc2295#section-8.3.
I also would like to see
On 2012-06-01 20:24, Kornel Lesiński wrote:
...
If there are commas or backslashes in the URL they must be escaped with `\`.
This is another problem why I would separate the diff. srces.
Escaping an URL is not something that should be necessary in HTML I think.
I agree, it's ugly, but
On 2012-05-22 17:02, Glenn Maynard wrote:
(I wish people would stop starting new threads about the same topic.)
On Tue, May 22, 2012 at 5:53 AM, Paul Courtp...@pmcnetworks.co.uk wrote:
As a HTML author and programmer, I just cannot see myself implementing the
current srcset proposal on
On 2012-05-21 04:21, David Clements wrote:
Hi guys,
Just to let you all know, I've written a javascript implementation of
srcset using a framework for responsive images (which I also wrote)
called Respondu (I'm open to new name suggestions), I'd love it if someone
could check that I've
On 2012-05-21 09:36, huperekch...@googlemail.com wrote:
Hey Julian
I believe the attribute sets are delimited by comma, whereas each attribute
itself is separated by space?
No. The URIs can contain a comma, so you can't use that delimiter. See
the parsing definition in the spec.
...
On 2012-05-18 12:30, Maciej Stachowiak wrote:
On May 18, 2012, at 3:16 AM, Markus Ernstderer...@gmx.ch wrote:
Am 15.05.2012 09:28 schrieb Ian Hickson:
img src=face-600-...@1.jpeg alt=
srcset=face-600-...@1.jpeg 600w 200h 1x,
face-600-...@2.jpeg 600w 200h 2x,
On 2012-05-17 13:30, Kornel Lesiński wrote:
My suggestion is that the srcset (or picture) should assume that
images are 2x scale by default.
My reasoning behind is:
- we have img for easy embedding of 1x images today, but we don't have
2x img for the future. Having to specify width/height in
On 2012-05-10 09:58, Edward O'Connor wrote:
Hi,
When authors adapt their sites for high-resolution displays such as the
iPhone's Retina display, they often need to be able to use different
assets representing the same image. Doing this for content images in
HTML is currently much more of a pain
On 2012-05-16 11:51, Odin Hørthe Omdal wrote:
On Wed, 16 May 2012 11:22:07 +0200, Julian Reschke
julian.resc...@gmx.de wrote:
Inventing a new microsyntax is tricky.
- comma separated implies you'll need to escape a comma when it
appears in a URI; this may be a problem when the URI scheme
On 2012-05-16 15:46, Glenn Maynard wrote:
On Wed, May 16, 2012 at 4:28 AM, Paul Courtp...@pmcnetworks.co.uk wrote:
First, I would like to suggest throwingimg srcset out the window and
into a landfill somewhere (It's not even fit for recycling!). This reminds
me if the recent semi-colon in
On 2012-05-16 16:07, Glenn Maynard wrote:
On Wed, May 16, 2012 at 8:57 AM, Julian Reschkejulian.resc...@gmx.dewrote:
It is?
Quick check, do
srcset=a,b
and
srcset=a, b
mean the same thing?
And what about
srcset=a ,b
Yes, they all mean the same thing: a url a with no descriptors,
On 2012-05-16 16:36, Glenn Maynard wrote:
On Wed, May 16, 2012 at 9:16 AM, Julian Reschke julian.resc...@gmx.de
mailto:julian.resc...@gmx.de wrote:
, is a legal URI character. (Collect a sequence of characters
that are not space characters, and let that be url.)
Actually, the key
On 2012-05-02 13:05, Evan Jones wrote:
On May 1, 2012, at 22:38 , Ashley Sheridan wrote:
The Webkit method looks the better of the two with regards to how
server-side languages might interpret it, but it would need work to
ensure everything that should be escaped is, and that everything that is
On 2012-05-02 19:26, Evan Jones wrote:
On May 2, 2012, at 7:43 , Julian Reschke wrote:
If browser implementers want to try something new that will not affect the old
code paths, supporting the encoding defined in RFC 5987 might be the right
thing to do (yes, it's ugly, but it's unambiguous
On 2012-04-23 10:19, Henri Sivonen wrote:
...
* The Universal detector is used regardless of UI setting or locale
when using the FileReader to read a local file as text. (I'm
personally very unhappy about this sort of use of heuristics in a new
feature.)
...
+1
...
WebVTT is a new format
On 2012-04-20 14:37, And Clover wrote:
On 2012-04-20 09:15, Anne van Kesteren wrote:
Currently browsers differ for what happens when the code point cannot
be encoded.
What Gecko does [?%C2%A3] makes the resulting data impossible to
interpret.
What WebKit does [?%26%23163%3B] is consistent with
On 2012-04-17 11:30, Anne van Kesteren wrote:
Hi,
Apart from big5 (which requires some more research) all encoders and
decoders are now defined:
http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html
...
As a nit, I believe that Character Encoding would make a better title
than just
On 2012-03-14 13:10, tom wrote:
Hi,
AFAIK, WebRTC intends to setup P2P communication between browsers, then
carry video/audio/text media, etc.
Why we need WebRTC? Firstly, Web is the most popular network app, secondly,
video/voice brings the best user experience.
But, the problem is that HTTP
On 2012-03-08 20:25, Christian Schmidt wrote:
...
Separating the network protocol from the user interface seems highly
desirable. Window-Target sacrifices that.
I get your point. But it seems that Content-Disposition already suffers
from this.
RFC 2183 describes the Content-Disposition like
On 2012-02-18 14:45, Sven Neuhaus wrote:
...
Stop here. That's not what the fragment identifier is for.
Instead, you could specify the hash as a separate attribute on the
containing element.
The relevant section from RFC 3986 reads:
The fragment identifier component of a URI allows
On 2012-02-17 09:42, Sven Neuhaus wrote:
Hello,
as of 2012, some websites are including popular javascript libraries from CDNs,
like
Google's. The benefits are:
* Traffic savings for the site operator because the javascript libraries are
downloaded from
the CDN and not from the site that
On 2012-01-18 22:55, Dimitri Glazkov wrote:
On Wed, Jan 18, 2012 at 1:47 PM, Adam Barthw...@adambarth.com wrote:
On Wed, Jan 18, 2012 at 1:29 PM, Dimitri Glazkovdglaz...@chromium.org wrote:
On Wed, Jan 18, 2012 at 1:14 PM, Dimitri Glazkovdglaz...@chromium.org wrote:
Ah, that's a good
On 2011-12-08 18:54, Anne van Kesteren wrote:
On Wed, 07 Dec 2011 18:59:43 +0100, Paul Kinlan paulkin...@google.com
wrote:
Cons:
* ordering of data in the content element - if the ordering of data in
the content value is mandatory and the developer mixes up the
ordering, does the action then
On 2011-09-14 10:16, Robert O'Callahan wrote:
On Sat, Sep 10, 2011 at 11:01 PM, Ryosuke Niwarn...@webkit.org wrote:
Have implementors actively opposed to this idea? It seems like sticking to
RFC is a cleaner option if possible.
Yeah. Will you fix it in Webkit? :-)
:-)
Maybe we should
On 2011-09-12 21:47, Michal Zalewski wrote:
What about javascript: URLs?
Right now, every browser seems to treat javascript:alert('#') in an
intuitive manner.
This likely goes beyond data: and javascript:, so I think it would be
useful to look at it more holistically.
Maybe. Or it makes
On 2011-09-11 04:51, Boris Zbarsky wrote:
...
I think you misunderstand my position. I'm weakly against the proposal
in question; the strongest argument in favor of the proposal is that
there is either a current or future deployed base of data: URIs that
won't work without it but do work in
On 2011-09-11 18:56, Daniel Holbert wrote:
On 09/11/2011 02:09 AM, Julian Reschke wrote:
Given the fact that this change made it into the release without any
major uproar there might be a chance that other UAs might simply adopt
it.
(To be clear -- the proposal hasn't made it into any
On 2011-09-11 17:30, Daniel Holbert wrote:
On 09/11/2011 07:21 AM, Michael A. Puls II wrote:
Not only must # be %23 if you don't want it as a frag id, but
and should be %3E and %3C.
[...]
Of course, if you can percent-encode everything needed as you type, you
can hand-author the URI
On 2011-09-08 08:26, Jens O. Meiert wrote:
Please clarify -- (a) the decisions do not make sense or (b) not applying
them doesn't make sense?
My main concern are the number of differences between the WHATWG and
the W3C version, hence the question whether we’re on it at all to
improve this.
On 2011-08-30 16:51, Anne van Kesteren wrote:
On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote:
* It is in fact an issue for being able to make the website responsive
on Mobile devices in low banwidth.
The mobile devices are the ones with the high-resolution displays.
on
the to-be-downloaded resource?
I've specified that the header wins.
On Wed, 20 Jul 2011, Julian Reschke wrote:
That being said, if you want to go down the road, make it clear how the
file name actually is extracted from the header field in an
interoperable way.
That isn't really in scope
On 2011-07-22 05:03, Hironori Bono (坊野 博典) wrote:
Greetings all,
This is just out of curiosity.
Would it be possible to give me the encoding used for this download
attribute? I think we have several options when we use non-ASCII
characters (this example uses Cyrillic characters) as the
On 2011-07-22 09:24, Ian Hickson wrote:
On Fri, 22 Jul 2011, Julian Reschke wrote:
That isn't really in scope for the HTML spec, it's something either
for the HTTP spec or the Content-Disposition spec (if HTTP doesn't
define th header itself) to define.
Is there a specific reason why the new
On 2011-07-20 13:33, Chris Bentzel wrote:
Who should be trusted for filename if the one specified bya on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?
...
I think the header field needs to be authoritative.
That being said, if you
On 2011-07-18 14:54, aykut.sen...@bild.de wrote:
According to the w3c Validator themetaname=datecontent=# / tag is
invalid. In the WHATWG MetaExtensions List there is no registered extension, no specification and no
proposal for the date meta-tag.
The only alternative for date is a proposal
On 2011-07-18 15:59, aykut.sen...@bild.de wrote:
hi julian,
i have asked one from the seo team and he says for example the freshness
factor is important for google.
is it possible to use the time-tag in the head instead (i mean invisible)?
dc:created is also not in the Meta Extensions List, see:
On 2011-07-14 17:01, Jonas Sicking wrote:
...
True. I would be fine with removing the plugin requirement. Or
changing it such that it states that plugins can only be loaded if
it's done in a manner that ensures that all other requirements are
still fulfilled. Or just dealing with this once there
On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote:
..
It also doesn't naturally help understanding that it's just poor man's
Content-Disposition:attachment. From this point of view, I like Ian's
original proposal (rel=attachment) more.
Yes and no - both are sort of a poor man's
On 2011-07-14 08:22, Jonas Sicking wrote:
On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesterenann...@opera.com wrote:
On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschkejulian.resc...@gmx.de
wrote:
Yes, but we can *define* the flag in HTML and write down what it means with
respect to plugin
On 2011-07-13 22:31, Adam Barth wrote:
Adding allow-plugins today would defeat the prevention of parent redirection.
The short answer is we need an API for informing plugins of the
sandbox flags and a way of confirming that the plugins understand
those bits before we can allow plugins inside
On 2011-07-13 22:58, Adam Barth wrote:
On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschkejulian.resc...@gmx.de wrote:
On 2011-07-13 22:31, Adam Barth wrote:
Adding allow-plugins today would defeat the prevention of parent
redirection.
The short answer is we need an API for informing plugins of
On 2011-07-04 16:13, Anne van Kesteren wrote:
...
Are we sure we want this strict checking of media type parameters? I
always thought the media type itself was what strict checking should be
done upon, but that its parameters were extension points, not points of
failure.
...
The right thing
On 2011-06-03 17:46, Bjartur Thorlacius wrote:
...
I strongly disagree. I think browsers that use the Content-Disposition
filename for attachment but not inline are just buggy and should be
fixed.
FWIW MSIE9 seems to honor the filename hint with inline (contrary to
the test results mentioned
On 2011-06-03 14:23, Dennis Joachimsthaler wrote:
Am 03.06.2011, 10:23 Uhr, schrieb Eduard Pascual herenva...@gmail.com:
On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler
den...@efjot.de wrote:
By the way, another point that we have to discuss:
Which tag should a browser favor. The one
On 2011-05-26 22:54, Dennis Joachimsthaler wrote:
Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky bzbar...@mit.edu:
Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
extensions to match content types, to
On 10.12.2010 01:46, Tab Atkins Jr. wrote:
...
Indeed. You shouldn't be able to trigger POSTs from involuntary
actions. They should always require some sort of user input, because
there is simply *far* too much naive code out there that is vulnerable
to CSRF.
...
Thanks, Tab.
It's sad that
On 02.08.2010 18:56, Tab Atkins Jr. wrote:
2010/8/2 Kornel Lesińskikor...@geekhood.net:
Downloads can be forced already with Content-Disposition: attachment. It's
just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular
PHP snippets for forcing download are among
On 06.08.2010 05:49, Bjartur Thorlacius wrote:
...
IMO there should be a standard metadata wrapper that should be around
virtually all files being passed around the Internet. Downloaders should
register the metadata to xattrs or somesuch and uploaders should collect
said metadata and rewrap it.
On 07.12.2010 18:51, Dennis Joachimsthaler wrote:
Am 07.12.2010, 10:13 Uhr, schrieb Julian Reschke julian.resc...@gmx.de:
It would be great if those scripts could just get fixed.
Do you actually think that would HAPPEN? I think not. Better have people
get
rid of them entirely. Though
On 26.11.2010 05:20, Brett Zamir wrote:
I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: urn and xri (or possibly xriNN
where NN is a version number).
See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info
on XRI (basically allows the
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see all
the protocols listed with them, so I wasn't clear.
In any case, I still see the need for both types being reserved (and for
their subnamespaces targeted by the protocol handler),
On 26.11.2010 16:55, Brett Zamir wrote:
On 11/26/2010 7:13 PM, Julian Reschke wrote:
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see all
the protocols listed with them, so I wasn't clear.
In any case, I still see the need
On 26.09.2010 12:39, Dennis Joachimsthaler wrote:
Hello,
I'd like to bring this back to attention.
I don't want this to be forgotten before anybody who is official
has said their definitive yes or no about it.
Or how else do new additions find their way into the draft?
Many were positive
On 19.09.2010 22:33, Robert O'Callahan wrote:
...
So for example, page A links to resource B. The browser does a GET on A,
and receives a document containing a link to B, and the link element
has etags or last-modified attributes. The browser has a cached resource
for B, whose
On 20.09.2010 02:37, Aryeh Gregor wrote:
...
Sure it would. You can currently only save an HTTP request if a
future Expires header (or equivalent) can be sent. A lot of the time,
the resource might change at any moment, so you can't send such a
header. The client has to check every time, and
On 20.09.2010 17:26, Mike Belshe wrote:
...
LINK, in general, allows a server to indicate to a client that it will
need a particular resource earlier than the client otherwise would have
discovered it. Today, the LINK header doesn't assist with understanding
...
Sorry?
That may be a use
On 20.09.2010 18:17, Gavin Peters (蓋文彼德斯) wrote:
I think Mike was referring to the Link header. This header is defined
in RFC 2068 (but not RFC 2616) in section 19.6.2.4
http://tools.ietf.org/html/rfc2068#section-19.6.2.4 , the most important
part of that text is probably that The Link field is
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote:
Hi, I'm working on link tags inside of chrome. We're now experimenting
with an optimization that uses link tags and headers to avoid round
trips for cache validation in many cases.
...
Clarifying: essentially that's a workaround for resources
On 19.09.2010 20:47, Robert O'Callahan wrote:
2010/9/19 Julian Reschke julian.resc...@gmx.de
mailto:julian.resc...@gmx.de
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote:
Hi, I'm working on link tags inside of chrome. We're now
experimenting
with an optimization
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as official.
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
current rendering is best effort if any
On 07.09.2010 22:00, Boris Zbarsky wrote:
...
* If a file in a top-level browsing context is sniffed as video but
then some kind of error is returned before the video plays the first
frame, fall back to allowing the user to download it, or whatever the
usual action would be if no sniffing had
On 07.09.2010 11:51, And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
+1
Sniffing is
On 07.09.2010 12:52, Philip Jägenstedt wrote:
...
IE9, Safari and Chrome ignore Content-Type in a video context and rely
on sniffing. If you want Content-Type to be respected, convince the
developers of those 3 browsers to change. If not, it's quite inevitable
that Opera and Firefox will
On 01.09.2010 10:12, Philip Jägenstedt wrote:
...
If we start ignoring the Content-Type I expect we would also add
sniffing so that opening a video served with the wrong (or missing)
Content-Type still works in a top-level browsing context, as it does for
images (I think).
...
Sniffing in the
On 01.09.2010 16:23, Philip Jägenstedt wrote:
...
Huh, I guessed incorrectly, neither serving a PNG as text/plain or
text/html makes it be sniffed and rendered in a top-level browsing
context in Opera. However, both work in IE8.
...
Please don't say work when talking about something that's not
On 01.09.2010 15:13, Brian Campbell wrote:
On Aug 31, 2010, at 9:40 AM, Boris Zbarsky wrote:
On 8/31/10 3:36 AM, Ian Hickson wrote:
You might say Hey, but aren't you content sniffing then to find the
codecs and you'd be right. But in this case we're respecting the MIME
type sent by the server
On 31.08.2010 09:36, Ian Hickson wrote:
Fromhttp://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.1:
Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of meaningful
parameters depends on the media type and subtype. Most
On 31.08.2010 15:57, Anne van Kesteren wrote:
...
Another is that when you save the video to disk the browser will fix
up the extension correctly, if needed.
If you sniff you can fix it up correctly too.
...
Then let's hope that sniffing doesn't recognize Windows binaries.
Best regards,
On 29.08.2010 05:15, David John Burrowes wrote:
Hello all,
I wanted to chime in on this discussion. Let me say up front that clearly the
w3c and the browser vendors all are on the same page as you, Ian. I'm not in
the position to be challenging your collective wisdom!
...
With respect to
On 27.08.2010 00:45, Adam Barth wrote:
...
Escaping just those character is insufficient. The appeal of this
approach is that authors don't need the right blacklist of dangerous
characters. By the way, there are already folks doing something
similar manually now. They send the untrusted bytes
On 27.08.2010 12:32, Hugh Guiney wrote:
Ah, thanks. I guess the error is just confusing then in that it calls
it XHTML element noscript, which led me to think that it was indeed
part of XHTML. I think some indication otherwise might prove
beneficial to users.
But, I thought XHTML5 was just an
On 25.08.2010 22:50, Adam Barth wrote:
== Summary ==
...
Not convinced. There's already one way to escape these things, and this
is supported in all UAs.
I don't see how adding another mechanism will help those who can't use
the first one properly. For instance, people unable to escape ,
On 26.08.2010 22:10, Aryeh Gregor wrote:
On Thu, Aug 26, 2010 at 5:58 AM, Julian Reschkejulian.resc...@gmx.de wrote:
Not convinced. There's already one way to escape these things, and this is
supported in all UAs.
Adam gave two examples of cases where htmlspecialchars() is
insufficient, even
1 - 100 of 276 matches
Mail list logo
