Re: [whatwg] IPv4 parsing

[Tim Streater]

On 24 Jun 2015 at 20:15, Peter Kasting  wrote: 

> How Chrome's omnibox handles this (which I think is compliant with most
> other places):
>
> If there are no dots in the middle of the expression, the number is
> converted to powers-of-256 format and leading 0s are prepended to reach
> four octets:
>
> 66 = 0.0.0.66
> 256 = 0.0.1.0
>
> If there are dots in the middle, the number after the last dot is treated
> as above, while the numbers before the dots must satisfy 0 <= n <= 255 and
> are placed into the highest octets in order:
>
> 1.66 = 1.0.0.66
> 1.256 = 1.0.1.0
> 1.2.66 = 1.2.0.66
> 1.256.66 = invalid

This makes no sense at all.

--
Cheers  --  Tim

Re: [whatwg]

[Tim Streater]

On 27 Feb 2015 at 19:38, Boris Zbarsky  wrote: 

> On 2/27/15 2:18 PM, Tim Streater wrote:
>> One thing I'd like would be to be able to put content into an iframe (and
>> thus have it parsed), but defer any rendering or speculative download of
>> resources referred to in the content.
>
> Depending on whether you care about the href of your iframe and whether
> you want it sandboxed and so forth:
>
> var parsedThing =
>   new DOMParser().parseFromString(myString, "text/html");

Yes, already doing this.

> // Process parsedThing however you want.
> myIframe.contentDocument.replaceChild(
>   parsedThing.documentElement,
>   myIframe.contentDocument.documentElement
> );

Thanks, I'll try this instead of:

  myIframe.write (new XMLSerializer().serializeToString (parsedThing));

which I'm doing at present :-)

--
Cheers  --  Tim

Re: [whatwg]

[Tim Streater]

On 27 Feb 2015 at 18:52, Fady Samuel  wrote:

> This is obviously larger than the particular set of use cases mentioned
> here, but another set of iframe discussions I've seen lately have centered
> around going off thread or out of process. I wonder if there is a more
> basic primitive here that can apply to all these use cases [and perhaps
> even allow for new behaviors we haven't thought of]? Perhaps a new email
> thread would be appropriate for such a discussion?
>
> In all these use cases we want to defer content within an iframe or render
> content off the main thread. Perhaps there is a fundamental API whereby we
> can decouple content from container (for non-seamless iframes)? Perhaps
> lifetime management, and the question of what context the content is
> loaded, and rendered in can be decoupled from the lifetime and layout of
> the container iframe?

One thing I'd like would be to be able to put content into an iframe (and thus 
have it parsed), but defer any rendering or speculative download of resources 
referred to in the content. This will allow me to modify it. What happens is 
that I am given a text string, which is untrusted HTML and which may be badly 
formed, and which I want to modify to remove or disable certain elements before 
the browser proceeds with it. The content *may* be spam and I want to prevent 
it from "phoning home".

In principle I could parse the string myself but the browser will do a much 
better job than I can, which is why I want to modify the content *after* 
parsing, rather than before.

--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 19 Oct 2013 at 18:27, Ms2ger  wrote: 

> Quoting part of the original email you trimmed:
>
>> Luckily, we have SVGSVGElement.prototype.getElementById available to
>> compare to Element.prototype.querySelector.
>
> That is, getElementById is available on |svg| elements in the SVG namespace.

Yeah, thanks, I missed the significance of that, drat it.

--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 18 Oct 2013 at 22:56, Boris Zbarsky  posted, inter alia, 
this code: 

> [1] The testcase:
>
> 
> 
>   document.write("\n");
> 
> 
>   var node;
>   var count = 20;
>   function doTests(root, elementId, descQS, descQSNoConcat, descGEBI) {
> var start = new Date;
> for (var i = 0; i < count; ++i)
>   node = root.querySelector("#" + elementId);
> var stop = new Date;
> document.writeln(descQS + ((stop - start) / count * 1e6));
> var start = new Date;
> for (var i = 0; i < count; ++i)
>   node = root.querySelector("#test");
> var stop = new Date;
> document.writeln(descQSNoConcat + ((stop - start) / count * 1e6));
> var start = new Date;
> for (var i = 0; i < count; ++i)
>   node = root.getElementById(elementId);
> var stop = new Date;
> document.writeln(descGEBI + ((stop - start) / count * 1e6));
>   }
>   var root = document.getElementById("root");
>   var start = new Date;
>   for (var i = 0; i < count; ++i)
> node = document.getElementById("test");
>   var stop = new Date;
>   document.writeln("document.getElementById: " + ((stop - start) /
> count * 1e6));
>   doTests(root, "test",
>   "In-tree querySelector: ",
>   "In-tree querySelector, no string concat: ",
>   "In-tree getElementById: ");
>   root.remove();
>   doTests(root, "test",
>   "Out-of-tree querySelector: ",
>   "Out-of-tree querySelector, no string concat: ",
>   "Out-of-tree getElementById: ");
> 

I've tested this here on five browsers and it runs to completion Ok apart from 
iCab, which didn't like root.remove so I did that bit longhand. But I'm left 
confused. The other day I ranted about needing to use a document fragment and 
having to use querySelector on a table body. Now this code appears to imply 
that I need neither and could have used getElementById all along, since your 
application of getElementById above is mostly not to a document. I'm sure that 
when I tested that, a year or so back, it didn't work. Could you elucidate?

Thanks,

--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 15 Oct 2013 at 01:18, Glenn Maynard  wrote: 

> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson  wrote:

[snip]

>>document.getElementById(id)
>>
>> ...becomes:
>>
>>document.querySelector('#' + escapeCSSIdent(id))
>>
>> ...which is a lot less pretty and understandable, especially when you
>> consider that many authors are actually coming from:
>>
>>document.all[id]
>>
>> ...which is briefer than either, and still self-explanatory.
>>
>>
>> I feel this is a case where we're not putting authors first, but are
>> instead putting spec purity first.

> (Nothing about this discussion relates to "spec purity", whatever that
> means.  My argument is that this function is useless legacy, and that
> proliferating it to DocumentFragment seems to be for consistency's sake
> only.)

It's not useless legacy, it's a simple API call that does what it says.

I have an array of table bodies, one of which I switch into the user's view by 
unhooking the present one from the table and appendChild-ing the one the user 
now wants to look at. It's irritating enough that to search one of these 
tBodies for an id I have to temporarily hook it to a DocumentFragment without 
then being forced to use an opaque API call to get the result I want.

Personally I'd vote for it being possible to search any object for an id, never 
mind it having to be part of the DOM or attached to a fragment. How about:

tbodyPtr.getElementById (id);

That might be too radical so I'd settle for getElementById and friends being 
available on fragments. Then we'd have consistency.

See, at the moment I've no idea whether getElementById is faster or slower than 
querySelector or whether it doesn't matter. But with 10,000 ids in some of my 
tBodies I'm thinking about it.



--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 29 Jun 2013 at 01:37, Tab Atkins Jr.  wrote: 

> On Fri, Jun 28, 2013 at 5:32 PM, Zirak A  wrote:
>> But that's a bit looking at it backwards. Selectors are supposed to be an
>> abstraction over these methods, not the other way around. The point here is
>> that
>> document fragments are documents - so they should have a consistent API.
>> Adding this isn't about "backwards compatibility" or anything of the sort.
>> It's
>> adding methods that people already use, because as said, not everyone uses
>> selectors (and not just because of browser-compat).
>
> No, they're not.  You're rewriting history.  Selectors were never
> meant as a layer over those methods; they were a completely separate
> and independently-invented way to target elements for CSS's purposes.

But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a 
particular row, by id, in order to modify the contents of cells in that row. I 
find it perverse to be using a style-related API call to do that.

--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 28 Jun 2013 at 22:28, Zirak A  wrote: 

> Because they may result in the same thing, but they have different semantic
> meanings. I want to get an element by its id, not run a CSS selector. I want
> to get elements by their tag names, not run a CSS selector.

Quite so.

> From: Tab Atkins Jr.

> Given that you have querySelector, why would you want the other
> functions? getElementById("foo") is just querySelector("#foo"),
> getElementsByTagName("foo") is just querySelectorAll("foo"), etc.

In addition it's hardly obvious that this is what you do.

--
Cheers  --  Tim

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Tim Streater]

On 28 Jun 2013 at 21:19, Zirak A  wrote: 

> Currently, a DocumentFragment only inherits from Node, and thus loses methods
> like getElementById. However, the Selector API
> (http://www.w3.org/TR/selectors-api/) defines querySelector and
> querySelectorAll on document fragments.
> My proposal is to add getElementById (which makes sense, as the document
> fragment is a root node), getElementsByTagName (and its namespace-sensitive
> version), getElementsByClassName and getElementsByName - in short, all of the
> general selection methods available on the Document.

I'd like to support this. I typically have an array of pointers to table 
bodies, and I want to search those looking for a particular row by id. Only one 
of the table bodies is in the DOM at any given time, and at present for a table 
body that is not in the DOM I have to hook it to a fragment and then do 
something like:

   rowPtr = fragPtr.querySelector ("#" + id);

I'd rather be able to use getElementById.

--
Cheers  --  Tim

[whatwg] Modifying iframe sandbox attributes

[Tim Streater]

I need to add/remove the allow-scripts attribute to/from an iframe sandbox, 
since I use one frame for two purposes (sometimes with untrusted content, other 
times with my own content that uses JavaScript). I've tried the following:

iframePtr.sandbox = "allow-popups allow-same-origin allow-scripts";

and:

iframePtr.sandbox = "allow-popups allow-same-origin";

This doesn't appear to work in Safari 6.0.4. Is this the right syntax? Is such 
a possibility even implemented yet.

--
Cheers  --  Tim

Re: [whatwg] Hide placeholder on input controls on focus

[Tim Streater]

On 22 Mar 2013 at 22:32, Glenn Maynard  wrote: 

> I start typing after I read the placeholder.  Hiding placeholder text just
> because I focused the input is wrong; I may not have read it yet.

You shouldn't start typing until you *have* read it. Simples.

--
Cheers  --  Tim

Re: [whatwg] Hide placeholder on input controls on focus

[Tim Streater]

On 18 Mar 2013 at 23:44, Glenn Maynard  wrote: 

> On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst  wrote:
>
>> A reason for the behaviour of Firefox and Chrome may be that some user may
>> not have read the placeholder text before focusing the control. Anyway, if
>> this behavior lets some users think they can't even fill in the form, there
>> must be something wrong about it.

> I've seen browsers (or maybe pages emulating placeholder in script) that
> hide the placeholder text while the input field is focused.  When the
> placeholders are labels for the inputs, it's incredibly annoying to have to
> focus something else in order to see the placeholder text.  If placeholders
> are meant to be useful and not just eyecandy, they need to remain visible
> until the user enters something.

But that's not what users do. You read the placeholder text, which may may hint 
at what is expected there, and the field should have a separate label. Then you 
focus there, and the placeholder text should vanish. Why? because I've lost 
count of the number of users I see trying to select the placeholder text so 
they can delete it, and then start typing.

--
Cheers  --  Tim

Re: [whatwg] Hide placeholder on input controls on focus

[Tim Streater]

On 18 Mar 2013 at 12:27, Boris Zbarsky  wrote: 

> On 3/18/13 5:31 AM, Markus Ernst wrote:
>> - Opera and Safari hide it when the field gets focus
>
> The behavior of Safari here is platform-dependent or possibly
> version-dependent.  Safari 6 on Mac doesn't hide the placeholder until
> you start typing.

I for one find this to be extremely irritating. Workaround I was given by some 
kind person:

[placeholder]:focus::-webkit-input-placeholder
 {

 color: transparent;

 }



--
Cheers  --  Tim

Re: [whatwg] Proposal for window.DocumentType.prototype.toString

[Tim Streater]

On 30 Oct 2012 at 10:20, Stewart Brodie  wrote: 

> Johan Sundström  wrote:

>> Serializing a complete HTML document DOM to a string is surprisingly
>> hard in javascript.
>
> Does XMLSerializer().serializeToString(document) not meet your requirement?

I was wondering that too. I use it to get the content of an iframe into a 
string, so I can send that off to a database. Seems to work without problems 
(Safari Mac 6.0.1). But I too had to ask how to do that; it wasn't particularly 
obvious that that was what I should have been using (to me at any rate).

--
Cheers  --  Tim

Re: [whatwg] suggestion limited context

[Tim Streater]

On 07 Jun 2012 at 23:18, Ian Hickson  wrote: 

> On Thu, 23 Feb 2012, Andri Sævar Sigríksson wrote:
>>
>> i would like to suggest a limited context
>> for embedding JavaScript/html  in a websites

>> i don't think this would be difficult to implement
>> web-browsers  simply  needs to ignore things that would not be allowed

>> i think its every reason to implement this
>> a lot of websites that allow embeding
>> only allow flash or very limit html like img or Link text
>> simply because allowing any more that would subject the website to unwanted
>> manipulation and hacks
>>
>> but with  this limited context would allow websites
>> allow embedding more freely for JavaScript/html without the risk
>
> Does the  feature recently added to HTML adequately 
> address your use cases?

I thought iframe sandbox would suit my particular use case (where I receive 
what purports to be html and have to do some sanitisation before loading it 
into an iframe) but I still want to be able to click a link in the iframe and 
have it behave as if the link had target="_blank". Unfortunately there is no 
attribute for that in sandbox="".

--
Cheers  --  Tim

Re: [whatwg] Declarative unload data

[Tim Streater]

On 07 May 2012 at 08:53, Tab Atkins Jr.  wrote: 

> Besides those annoying "Are you sure you want to leave this page?"
> dialogs, the primary use of the unload events is a final, desperate
> attempt to throw a message at the server, either to save some data or
> release some server-held resource.  However, this is tricky to do
> reliably, because browsers kill pending XHRs as they unload the page.
> Right now, I think the most reliable method is to create an  and
> set its @src, because of an old quirk in IE that other browsers have
> copied which means that pending image loads are carried to completion
> rather than being killed.  This is, obviously, stupid.  (Another,
> stupider, method is to prevent the handler from exiting by spinning a
> no-op loop for several seconds, as I think browsers won't unload the
> page until the handler exits?)

Personally I use onbeforeunload. In the handler for that I do a *synchronous* 
ajax request to have a tidy-up script run. The tidy-up script spins off a 
process that sleeps for 3 seconds before closing down apache. That allows the 
tidy-up script time to complete and send the ajax results back, so permitting 
the unbeforeunload handler to finish. Since the apache instance is running on 
the user's machine, the assumption here is that the three seconds is plenty of 
time.

--
Cheers  --  Tim

Re: [whatwg] Additional attribute value for iframe sandbox

[Tim Streater]

On 30 Apr 2012 at 21:17, Charles Pritchard  wrote: 

> They've got an allow-popup in IE and I think WebKit.
> It's just a little slow going in getting it firmly out there.

Yes, I saw that as I worked on through the archive. But they want to enforce 
the same restrictions on the newly-opened window as the iframe had. I'd prefer 
no restrictions, but also no connection back from the opened window to its 
parent. IOW, just as if one had opened a new browser window and typed the URI 
in manually.

--
Cheers  --  Tim

[whatwg] Additional attribute value for iframe sandbox

[Tim Streater]

I'd like to request that it be possible for links in sandboxed iframes, when 
clicked, to open in a new window. My reading of the documentation suggests that 
in a sandboxed iframe, links are disabled except that "allow-top-navigation" 
permits the equivalent of "target='_top'". In effect, I'd like a new value that 
permits "target='_blank'". Testing today tells me that in fact in Safari 5.1.5 
at least, a sandboxed iframe does not interfere in any way with links.

My use case is this. My application, a mail client, receives html emails and 
uses an iframe to display them. A good example of such a mail can be seen here:

  


(When I receive it, the recipient's email address is in the bottom part of the 
page rather than #emailaddr#.) This is an example of a trusted email which has 
links. At present, my application strips out scripts as a primitive security 
measure, but I'd rather use a sandboxed iframe if possible. However, a user 
will expect to be able to click on a link in such an email and have a new 
window opened, separate from the email client. Hence my request for a new value 
for the sandbox attribute.

--
Cheers  --  Tim

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

[Tim Streater]

On 16 Apr 2012 at 19:07, Darin Fisher  wrote: 

> Aren't we missing an opportunity here?  By giving web developers this easy
> migration path, you're also giving up the opportunity to encourage them to
> use a better API.  Asynchronous APIs are harder to use, and that's why we
> need to encourage their adoption.  If you just give people a synchronous
> version that accomplishes the same thing, then they will just use that,
> even if doing so causes their app to perform poorly.
>
> See synchronous XMLHttpRequest.  I'm sure every browser vendor wishes that
> didn't exist.  Note how we recently withdrew support for synchronous
> ArrayBuffer access on XHR?  We did this precisely to discourage use of
> synchronous mode XHR. Doing so actually broke some existing web pages.  The
> pain was deemed worth it.

In my app I have about 90 async XMLHttpRequest calls. I have one synchronous 
one that I'd really like to keep as it facilitates a clean tidy up if the user 
ignores my Exit button and quits by closing the window. When the app closes I 
need to run a script in order to shut down a local apache instance amongst 
other things. I hope I'm not going to find this to be a problem if synchronous 
mode XMLHttpRequest is removed from Safari at some future point. My code looks 
like this:


function quitbyClose ()
 {

 // User clicked window close button. Must make a synchronous ajax call to 
tidy up. We have to ensure
 // SESE with no "return" being executed due to the odd way that 
onbeforeunload operates, in two cases:
 // 1) Where Safari re-opens myapp after user quits Safari and user has 
already restarted myapp
 // 2) Where user might try to start this file by hand

 var  request, data;

 if  (portnum>0)
  {

  closeWindows ();  
// Close any popups

  data = "datarootpath=" + encodeURIComponent (datarootpath) + 
"&debugfl=" + debugfl;

  request = new XMLHttpRequest ();
  request.open ("POST", "http://localhost:"; + portnum + 
"/bin/myapp-terminate.php", false);
  request.setRequestHeader ("Content-Type", 
"application/x-www-form-urlencoded; charset=utf-8"); 
  request.onreadystatechange = function() { if  (request.readyState!=4) 
 return false; }
  request.send (data);

  }

 }


--
Cheers  --  Tim

Re: [whatwg] Tables, headers and bodies

[Tim Streater]

On 01 Apr 2012 at 21:15, Jose Fandos  wrote: 

> Can anyone point to any discussions about table headers and table bodies
> and how to deal with having a fixed header and a scrollable body?
>
> I've done a number of searches but might not be using the right terms to
> unearth any previous discussion in this regard.
>
> The idea is a quite common situation in software interfaces of all kinds
> where the headers will always be visible while the table rows (table body)
> will scroll.

The only way I found to do this is to have two tables, fixed cell widths, 
overflow hidden, and textOverflow ellipsis. There is additional CSS to get the 
two tables to look like one.

--
Cheers  --  Tim

Re: [whatwg] Client side value for language preference

[Tim Streater]

On 30 Mar 2012 at 16:05, Jukka K. Korpela  wrote: 

> 2012-03-30 17:22, Henri Sivonen wrote:
>
>> On Fri, Mar 30, 2012 at 5:08 PM, Matthew Nuzum  wrote:
>>> For example, maybe a site can't afford translation but a small library
>>> could be included that formats dates and numbers based on a user's
>>> language preference. No more wondering if 2/3/12 is in March or in
>>> February.
>>
>> The reader doesn't know that the site tries to be smart about dates
>> (but not smart enough to just use ISO dates),
>
> It’s not smart to use ISO dates, which are not what the majority of 
> mankind is used to. Sometimes ISO dates are the least if evils, but they 
> are not proper localisation.

+1

>> so scrambling the order
>> of date components not to match the convention of the language of the
>> page is probably worse than using the convention that's congruent with
>> the language of the page.
>
> But what might that be, and how does it relate to the formats that 
>  and relatives are supposed to deal with?
>
> There is absolutely no way in HTML, in HTML 4 or in HTML5, to say that 
> input of dates should be accepted according to a specific convention. 
> What users get is an US convention, or a local convention as per the 
> browser, quite independently of the (declared or implied) locale of the 
> page.

There's no way to ask the OS what the user prefers, I suppose?

--
Cheers  --  Tim