- From: <bugzilla@jessica.w3.org>
- Date: Mon, 01 Apr 2013 15:54:05 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21439 --- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> --- (In reply to comment #1) > I'm prepared to offer an example of using a data URL in the examples, and > suggest that in prose as a possible repair strategy. Super! Perhaps you could add, in that regard, that the purpose of turning it into a data URI is an economical one: * FIRSTLY, it allows the UA to reuse its usual mechanism for handling longdesc URIs (as opposed to implementing two different ways to handle the content of the longdesc attribute). * SECONDLY, it allows users to interect with invalid longdesc attribute content in the same way they interact with valid content. > User agents are not required to open the longdesc in a new window or tab and > I am not prepared to make that requirement. I’m fine with not telling how the data URI should be handled. My sole point was really only the encomical point I made above. Sorry for my unclarity. > There are implementation > strategies which seem perfectly valid but do not do this. We should avoid > introducing restrictions whose effects we don't really understand, IMHO. I’m not sure what you mean here. But in the HTML5 spec, it is sometimes/somewhere said that the purpose of describing algorithms is not that implementations follow the algorithms 100% to the letter, but rather that they perform an (possibibly optimized) activity that has the same outcome as the described algorithm. And perhaps it would be possible to say something like that? That said, I am a bit sceptical about giving invalid data URIs too much attention - to the extent that I am not 100% sure it is a good thing to have it in the spec. I mean, I am not aware of UAs or AT, today, that do anything with such content. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 1 April 2013 15:54:07 UTC