[whatwg] pagehide vs pagevis

[Ian Hickson]

On Tue, 28 May 2013, Brady Eidson wrote:
> 
> The “unload a document” steps apparently don’t allow for the pagehide 
> event to have “persisted” set to false.

Hm, yeah, it should only be set to true if /salvageable/ is true. Fixed.


> In the original design of these events and in WebKit’s implementation, 
> pagehide with persisted “true” means the page is being suspended into 
> the page cache, and it might be restored later.  In these cases, the 
> page does not receive a traditional unload event, as it’s being 
> suspended, not unloaded.

I don't understand how you can know if you are going to fire the 'unload' 
event. I think the way the spec describes it makes more sense, which is 
that you always fire pagehide and you always fire unload, but if any 
unload handlers were triggered, then you don't suspend.


> pagehide with persisted “false” means the page is is being traditionally 
> torn down.

Right (salvageable is false).


> The spec’s description of PageTransitionEvent.persisted says "Returns 
> false if the page is newly being loaded (and the load event will fire). 
> Otherwise, returns true.”
> 
> That text is geared towards pageshow and completely neglects pagehide.

Yeah, that description was kinda lame. Fixed.


By the way, when the spec doesn't match implementations, it's usually a 
far better bet that it's just unintentionally wrong, than that there is a 
nefarious plot to ruin everything. :-)


On Tue, 28 May 2013, Brady Eidson wrote:
> 
> I'm sorry, who's page cache are you talking about?  Page caches are 
> (AFAIK) not really fleshed out in any spec

Actually the HTML spec defines the page cache as thoroughly (I think) as 
any spec can. (Really everything but the eviction mechanism, but that is 
intentionally a UA-specific thing.)


> and the WebKit page cache *intends* to represent a 100% inert page.  
> This includes the inability to receive events.  Any exceptions in 
> practice are a bug for us that we would strive to patch.

A DOM node can always receive an event.

The event handlers of DOM nodes in inactive documents might not be able to 
run, though. I don't think the HTML spec is very clear about this right 
now. (It blocks tasks, but I don't think it blocks event handlers.) I 
guess this would have to be in DOM, really.

I filed this so we make sure to track this:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23095


On Wed, 29 May 2013, Brady Eidson wrote:
> 
> Got it.  Then it sounds like Gecko’s page cache and WebKit’s page cache 
> are divergent in this regard.  Which is perfectly fine, as such a 
> browser feature isn’t spec’d anyways.

It is. :-)


> I’ve provided our rationale for changing this, and I’m formally asking 
> the WHATWG community if there’s any rationale for *not* changing this

I don't think you can formally ask anything here. You can ask, but there 
cannot be anything more or less formal about it. :-)


On Wed, 29 May 2013, Brady Eidson wrote:
> 
> I see in the HTML spec that the step *before* firing pagehide is “set 
> the Document’s page showing flag to false,” but I can’t find language 
> that says pagehide fires *before* the page is actually hidden, and 
> unload fires *after* the page is actually hidden.

Since they fire synchronously, and rendering happens between tasks, they 
both fire when the page is in the same on-screen rendered state. I don't 
think there's a black-box way of telling whether there remains pixels of 
the page on the screen or not when either fires.


> pageshow is a history traversal event, and not a visibility event.  I 
> don’t see a guarantee in any spec that “pageshow” comes after the 
> document is actually visible.

Indeed. In fact in some UAs, e.g. those that use audio instead of video to 
display the page, the page will never be "visible".

I don't really see why it matters whether the Page Visibility spec fires 
its event before or after pagehide, though.


> First, since pagehide currently always has persisted set to true (in the 
> spec and in Gecko), it doesn’t actually describe whether or not the page 
> is going in to the page cache.

It can be false (now, in the spec) when you are definitely not going into 
the cache, but it can also be true when you're not (e.g. if WebSockets get 
killed after pagehide and unload), and it can also be true when you go 
into the cache and are immediately evicted without notice, which is much 
the same as not going into the cache.

So "true" is no guarantee of anything.


> Second, imagining a world where pagehide allows persisted to differ 
> between true or false, to know that a “hidden” corresponds with a “page 
> going in to the page cache”, you still have to listen to both events to 
> know the whole situation. Third, is the difference between 4 states and 
> 5 states really appreciable?

I don't really understand these questions.


On Thu, 30 May 2013, Brady Eidson wrote:
> 
> Bucket 1 - “Pages not going in to the page cache”
> 
> Let me ask you this - Are there any (reas

Re: [whatwg] Script preloading

[Garrett Smith]

On 8/29/13, Nicholas Zakas  wrote:
> When Kyle and I originally started pushing for a way to preload JavaScript
> many moons ago, the intent was very simple: to allow the downloading of
> JavaScript and execution of JavaScript to be separate. The idea being that
> you should be able to preload scripts that you'll need later without
> incurring the cost of parsing and execution at that point in time. There
> are many examples of people doing this, the most famous being the Gmail
> mobile approach of loading JavaScript in comments and then pulling that
> code out and eval()ing it.
>

Ian mentioned the idea of exporting a module, and that idea requires
only a function expression to return an object. This requires the
parsing of one function -- the outermost function -- which can be
evaluated later.

Some examples of this include the "Russian Doll Pattern" (Cornford)
"Module Pattern" (Crockford), IIFE (?), and function rewriting (me).

For more on this, see Kangax' article:
http://kangax.github.io/nfe/

(Kangax seems to have gotten bored at conquering javascript these days).

> I still feel very strongly that this pattern is a necessary evolution of
> how we should be able to load scripts into web pages. I just want a flag
> that says "don't execute this now" and a method to say "okay, execute this
> now". Allowing that flag to be set both in HTML and JavaScript is ideal.
>
> The question of dependency management is, in my mind, a separate issue and
> one that doesn't belong in this layer of the web platform. HTML isn't the
> right spot for a dependency tree to be defined for scripts (or anything
> else). To me, that is a problem to be solved within the ECMAScript world
> much the way CSS has @import available from within CSS code.
>
Dependency issues include problems from having to block for scripts,
document.write, fouc.

Problems arising with dependency stem give rise to the need of
deferring and executing scripts. The problem is that the program needs
to run a script during a certain condition. And if that condition is
not met, then the script resource isn't needed at all.

This could useful for a situation where there are a few different
components on a page, say each component requires 100k of script and
10k of CSS. But the user will probably only use one of those three
components and might very well use none at all. I have worked on pages
like that, with sidebars, pickers, and panels, and I wanted something
like this.

As Ryosuke pointed out, the idea is to declare the script in the page
and then use script to determine when it should load.

My previous post on building a dependency tree delves into the idea
that CSS and JS can be declared to depend on stuff being loaded.  That
feature makes it obvious as to why they're in the source code, to the
human reader.

Regards,
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

Re: [whatwg] Script preloading

[Glenn Maynard]

On Tue, Aug 27, 2013 at 4:55 PM, Ian Hickson  wrote:

> IMHO, if you have to write a script to solve use cases like these, you
> haven't really solved the use cases. It seems that the opportunity we have
> here is to provide a feature or set of features that addresses these use
> cases directly, so that anyone can use them without much work.
>

This is especially true for a module loader, which will be used to deal
with interactions between scripts written by different parties.  If the
platform doesn't provide a standard, universal way to do this, then people
will keep rolling their own incompatible solutions.  That's bearable for
self-contained code used by a module, but it doesn't make sense for the
piece that handles the cross-vendor interactions.

Anyway, the idea of only providing basic building blocks and making people
roll their own solutions isn't the web's design philosophy at all, so I
don't think it's a valid objection.


>  

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Aug 29, 2013, at 8:37 AM, Nicholas Zakas  wrote:

> When Kyle and I originally started pushing for a way to preload JavaScript 
> many moons ago, the intent was very simple: to allow the downloading of 
> JavaScript and execution of JavaScript to be separate. The idea being that 
> you should be able to preload scripts that you'll need later without 
> incurring the cost of parsing and execution at that point in time. There are 
> many examples of people doing this, the most famous being the Gmail mobile 
> approach of loading JavaScript in comments and then pulling that code out and 
> eval()ing it.
> 
> I still feel very strongly that this pattern is a necessary evolution of how 
> we should be able to load scripts into web pages. I just want a flag that 
> says "don't execute this now" and a method to say "okay, execute this now". 
> Allowing that flag to be set both in HTML and JavaScript is ideal.
> 
> The question of dependency management is, in my mind, a separate issue and 
> one that doesn't belong in this layer of the web platform. HTML isn't the 
> right spot for a dependency tree to be defined for scripts (or anything 
> else). To me, that is a problem to be solved within the ECMAScript world much 
> the way CSS has @import available from within CSS code. 

But why do you want an ability to say "don't execute this now" if there were no 
dependencies?  Loading an extra script file that's not needed immediately can 
add few hundred of milliseconds to the total page load time over a slow network 
connection.

To put it another way, I don't see why anyone wants to load a script and not 
execute it other than for the purpose of avoiding the network request at a 
later time.  However, if that were the main purpose of providing such a 
functionality, then we also need to address the issue of this load request 
needing to have a lower priority than other load requests that are vital for 
the page.  In fact, we might want to avoid sending the request of a script file 
altogether if the user isn't going to interact the parts of the page that needs 
such a script.

- R. Niwa

Re: [whatwg] Handling of invalid UTF-8

[Ian Hickson]

On Fri, 30 Aug 2013, Cameron Zemek wrote:
>
> In the spec preview it had a section about UTF-8 decoding and the 
> handling of invalid byte sequences, 
> http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 

You really don't want to be using that as a reference. It's a very out of 
date copy of a fork of the spec.

On Thu, 29 Aug 2013, Glenn Maynard wrote:
> 
> http://www.whatwg.org/specs/web-apps/current-work/#dependencies has a 
> reference to the Encoding spec, which is where the UTF-8 decoding logic 
> lives now: http://encoding.spec.whatwg.org/#utf-8

Right, the HTML standard (http://whatwg.org/html) now uses the Encoding 
standard (http://encoding.spec.whatwg.org/) to define UTF-8 processing.

Let us know if you see anything wrong with either of these specs!

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Handling of invalid UTF-8

[Glenn Maynard]

On Thu, Aug 29, 2013 at 5:29 PM, Cameron Zemek  wrote:

> In the spec preview it had a section about UTF-8 decoding and the handling
> of invalid byte sequences,
> http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 . But I
> have
> noticed this section has been removed from the current version. So what
> algorithm is used for handling of invalid UTF-8 byte sequences? Or this no
> longer part of the HTML 5 specification?
>

http://www.whatwg.org/specs/web-apps/current-work/#dependencies has a
reference to the Encoding spec, which is where the UTF-8 decoding logic
lives now: http://encoding.spec.whatwg.org/#utf-8

-- 
Glenn Maynard

Re: [whatwg] Forms: and directory tree picking

[Glenn Maynard]

On Thu, Aug 29, 2013 at 5:06 PM, Jonas Sicking  wrote:

> >> We don't have to do any enumeration synchronously. It can all happen off
> >> the main thread. The .click() "API" is asynchronous.
> >
> > It's asynchronous to the JS, sure, but at the end of the day the user
> > can't get any work done until it's complete. It's synchronous as far as
> > the user is concerned.
>
> Sure. The alternative is that the user attaches each file separately.
> Which, while means smaller "synchronous" actions, is not really a
> better UX. In other words, synchronousness is not the only design
> constraint here.
>

The alternative is to provide an interface that explores the supplied
directory on-demand, as the page needs it, rather than greedily scanning
the entire directory before giving it to script.  Scanning a large
directory tree in advance is almost never what applications or users want.

A static file list isn't a sensible API for recursively exposing directory
trees.

-- 
Glenn Maynard

[whatwg] Handling of invalid UTF-8

[Cameron Zemek]

In the spec preview it had a section about UTF-8 decoding and the handling
of invalid byte sequences,
http://dev.w3.org/html5/spec-preview/infrastructure.html#utf-8 . But I have
noticed this section has been removed from the current version. So what
algorithm is used for handling of invalid UTF-8 byte sequences? Or this no
longer part of the HTML 5 specification?

My testing on firefox and chrome seems to indicate that they follow the
algorithm of replacing the first byte of an invalid sequence with the
replacement
character  "�" (U+FFFD)
and then continue with the parsing of the next byte.

Re: [whatwg] Subsequent access to empty string URLs (Was: Base URL’s effect on an empty @src element)

[Ian Hickson]

On Wed, 1 May 2013, Leif Halvard Silli wrote:
> 
>   If @src is empty (and there is no base url) a 'subsequent access' via 
> a contextual menu, such as 'Show/Open image' or 'Save/Download image' 
> has no effect in Firefox20, Opera12, IE10. Whereas Safari/Chrome do 
> provide a contextual menu item for those features. (And the UA results 
> are the same - except with regard to Firefox, also if there *is* a base 
> URL.)

If the src="" attribute is empty, then there's no image, so all these UI 
options are kinda pointless no?


>   A special detail is the last paragraph of section '2.5.3 Dynamic 
> changes to base URLS'[1] which implies that a change to the base URL 
> should (even when @src is empty, one must assume, not?) affect the @src 
> URL so that a 'subsequent access' via context menu could be used to 
> e.g. open the image resource set by the base URL. Is it meaningful? 

If the  is empty, the base URL has no effect, per spec.


>What if @cite or @longdesc are empty? Personally, I think it would be 
> simplest to handle at least @longesc - but probably @cite too - the same 
> way that @src is handled. The relevance to subsequent access to empty 
> @src is that @longdesc and @cite tend, from users’ point of view, to be 
> subsequently accessed (e.g. via context menu).

Per spec, longdesc="" has no effect.

The cite="" is explictly called out in the "Dynamic changes to base URLs" 
section and the logic that involves the cite="" attribute doesn't look to 
see if it's empty, so I don't see any particular complication there.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Forms: and directory tree picking

[Jonas Sicking]

On Thu, Aug 29, 2013 at 2:45 PM, Ian Hickson  wrote:
> On Thu, 29 Aug 2013, Jonas Sicking wrote:
>> On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson  wrote:
>> > On Fri, 2 Aug 2013, Jonathan Watt wrote:
>> >>
>> >> I'm working on Mozilla's implementation of  to allow
>> >> the user to pick a directory. The idea would be that the files in
>> >> that directory and its subdirectories would be added to the
>> >> HTMLInputElement.files FileList.
>> >
>> > This seems to be dangerous in that it makes it really easy for the
>> > user to select a single item that expands into tens of thousands if
>> > not millions of files on a remote disk, which then all have to be
>> > synchronously enumerated to get the count so that code can then itself
>> > enumerate through the entire list.
>>
>> We don't have to do any enumeration synchronously. It can all happen off
>> the main thread. The .click() "API" is asynchronous.
>
> It's asynchronous to the JS, sure, but at the end of the day the user
> can't get any work done until it's complete. It's synchronous as far as
> the user is concerned.

Sure. The alternative is that the user attaches each file separately.
Which, while means smaller "synchronous" actions, is not really a
better UX. In other words, synchronousness is not the only design
constraint here.

>> > So you wouldn't be able to pick a file and a directory as in the
>> > example above? That seems unfortunate...
>>
>> Unfortunately most OSs doesn't have support for filepickers that can
>> select either a file or a directory.
>
> True. From a UI perspective it's kind of weird that the user has to decide
> which he wants, though. Similarly, from an authoring perspective, I don't
> understand how I would decide whether to show a multiple file picker or a
> directory picker.

You display two buttons in the website UI, one for "pick file" and one
for "pick directory". We don't really have a choice as long as we live
under the two constraints of:

* Websites wants to do their own "pick" UI
* OSs can't display pickers which allow picking either a file or a directory.

/ Jonas

Re: [whatwg] Forms: and directory tree picking

[Ian Hickson]

On Thu, 29 Aug 2013, Jonas Sicking wrote:
> On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson  wrote:
> > On Fri, 2 Aug 2013, Jonathan Watt wrote:
> >>
> >> I'm working on Mozilla's implementation of  to allow 
> >> the user to pick a directory. The idea would be that the files in 
> >> that directory and its subdirectories would be added to the 
> >> HTMLInputElement.files FileList.
> >
> > This seems to be dangerous in that it makes it really easy for the 
> > user to select a single item that expands into tens of thousands if 
> > not millions of files on a remote disk, which then all have to be 
> > synchronously enumerated to get the count so that code can then itself 
> > enumerate through the entire list.
> 
> We don't have to do any enumeration synchronously. It can all happen off 
> the main thread. The .click() "API" is asynchronous.

It's asynchronous to the JS, sure, but at the end of the day the user 
can't get any work done until it's complete. It's synchronous as far as 
the user is concerned.


> > So you wouldn't be able to pick a file and a directory as in the 
> > example above? That seems unfortunate...
> 
> Unfortunately most OSs doesn't have support for filepickers that can 
> select either a file or a directory.

True. From a UI perspective it's kind of weird that the user has to decide 
which he wants, though. Similarly, from an authoring perspective, I don't 
understand how I would decide whether to show a multiple file picker or a 
directory picker.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Forms: and directory tree picking

[Jonas Sicking]

On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson  wrote:
> On Fri, 2 Aug 2013, Jonathan Watt wrote:
>>
>> I'm working on Mozilla's implementation of  to allow
>> the user to pick a directory. The idea would be that the files in that
>> directory and its subdirectories would be added to the
>> HTMLInputElement.files FileList.
>
> This seems to be dangerous in that it makes it really easy for the user to
> select a single item that expands into tens of thousands if not millions
> of files on a remote disk, which then all have to be synchronously
> enumerated to get the count so that code can then itself enumerate through
> the entire list.

We don't have to do any enumeration synchronously. It can all happen
off the main thread. The .click() "API" is asynchronous.

>> The advantage of avoiding the need for the 'directory' attribute would
>> be that directory picking would work for existing content with > type=file multiple> without needing to be changed. One disadvantage
>> would be that existing content may depend on the file names in the
>> FileList being unique.
>
> I would have liked the file names to still be unique, by prefixing the
> names with the relevant parts of the subpaths (that is, if I select
> foo.txt and bar/ which contains another foo.txt, .files would contain
> "foo.txt" and "bar/foo.txt"), but I think that ship sailed (and now the
> spec explicitly requires otherwise).

We discussed this. However many people has expressed that they expect
the .name property to only contain the leaf name. Trying to tell
people that the name is unique and may or may not include pieces of
path has lead to lots of confusion.

Instead we'll ensure that path+name is unique. At least unique within
a single selection. We're planning on eventually letting users bring
up filepickers multiple times and select additional files each time.

>> Currently authors can use HTMLInputElement.click() to open a system file
>> picker. To give content the ability to open a system directory picker
>> we'd add a corresponding .openDirectoryPicker() function.
>
> So you wouldn't be able to pick a file and a directory as in the example
> above? That seems unfortunate...

Unfortunately most OSs doesn't have support for filepickers that can
select either a file or a directory.

/ Jonas

Re: [whatwg] Forms: and directory tree picking

[Ian Hickson]

On Fri, 2 Aug 2013, Jonathan Watt wrote:
>
> I'm working on Mozilla's implementation of  to allow 
> the user to pick a directory. The idea would be that the files in that 
> directory and its subdirectories would be added to the 
> HTMLInputElement.files FileList.

This seems to be dangerous in that it makes it really easy for the user to 
select a single item that expands into tens of thousands if not millions 
of files on a remote disk, which then all have to be synchronously 
enumerated to get the count so that code can then itself enumerate through 
the entire list.


> The advantage of avoiding the need for the 'directory' attribute would 
> be that directory picking would work for existing content with  type=file multiple> without needing to be changed. One disadvantage 
> would be that existing content may depend on the file names in the 
> FileList being unique.

I would have liked the file names to still be unique, by prefixing the 
names with the relevant parts of the subpaths (that is, if I select 
foo.txt and bar/ which contains another foo.txt, .files would contain 
"foo.txt" and "bar/foo.txt"), but I think that ship sailed (and now the 
spec explicitly requires otherwise).


> We would change the File interface to add a 'path' property, which would 
> be the path (without the file name) of the file relative to the 
> directory that was picked.

That might work.


> Currently authors can use HTMLInputElement.click() to open a system file 
> picker. To give content the ability to open a system directory picker 
> we'd add a corresponding .openDirectoryPicker() function.

So you wouldn't be able to pick a file and a directory as in the example 
above? That seems unfortunate...


> In my prototype implementation it took around 30 seconds to build the 
> FileList for a directory of 200,000 files with a top end SSD

Wow. That's... not great in a UI.


> so depending on what the page is doing, directory picking could take 
> some time. To allow content authors with styled  to provide 
> feedback to users during scans of large directory trees we plan to have 
> openDirectoryPicker return a ProgressPromise:
>
> https://github.com/slightlyoff/Promises/blob/master/ProgressFuture.idl
> 
> We'd then fire progress events at the promise specifying how many files 
> had been processed so far.

I feel very uncomfortable with the idea that we'd intentionally have an 
expensive API like this. But I guess I don't really know what the use 
cases are, so it's hard to evaluate.



Anyway, I don't have a better suggestion right now. What has the 
implementation experience been like so far?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] datalist element example and option element content model

[Ian Hickson]

On Thu, 18 Jul 2013, Kurosawa Takeshi wrote:
> 
> I noticed inconsistency between datalist element example and option 
> element content model.
> 
> In a datalist element's code example, there are option elements which 
> don't specify label attribute and are empty. 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element
> 
> > 
> >  Sex:
> >  
> >  
> >   
> >   
> >  
> > >
> 
> However option element section prohibits such condition.
> 
> > The label content attribute, if specified, must not be empty. If the 
> > attribute is not specified, then the element itself must not be empty.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element
> 
> My question is which one is correct: the code example or the option
> element section.

I corrected the spec on this in response to the bug you filed:

On Sat, 17 Aug 2013, Kurosawa Takeshi wrote:
> 
> Bug 22994 - Clarify option element's label must be a non empty string.
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22994

If you could respond to comment 3 on that bug, that'd be great.


Note that if you post to this list, there's no point also filing a bug. 
I'll get to the feedback either way eventually.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] maxlength="" feedback

[Ian Hickson]

On Fri, 28 Jun 2013, Steve Hoeksema wrote:
> 
> The current whatwg standard [1] states that maxlength is not a valid 
> attribute for input[type=number].
> 
> I built a form and tested it in Firefox, which honours the maxlength 
> attribute, and then found that Chrome did not.
> 
> I thought this was a bug, so I reported it to Chromium [2], who 
> determined it was not a bug and referred me to whatwg.
> 
> I'm wondering if there is a rationale for not supporting maxlength on a 
> number field, and if not, how I can go about having the standard 
> changed?

Just set the max="" attribute instead.


On Fri, 28 Jun 2013, Steve Hoeksema wrote:
>
> In my specific case, a numeric code with a maximum length.
> 
> Say it's 4 digits, and I'm using Chrome. I can put max=, but the 
> browser still allows me to type 12345. It won't allow me to submit the 
> form, and it highlights it as an error, but I can still enter it. Using 
> a maxlength means I can't even enter 12345, and it's obvious that it 
> will only accept 4 digits.

If you have a numeric code (i.e. "" is different than "0") then 
type=number is the wrong type; you should instead use:

   


> Using input[type=text] is not desirable because (e.g.) it pops up a 
> alphabetical keyboard on iOS instead of a numeric keyboard.

That's fixed by inputmode=numeric.


On Fri, 28 Jun 2013, Jukka K. Korpela wrote:
> 
> People want to [specify maxlength on type=number] to cover old browsers 
> that do not support type=number. Such browsers ignore both the type 
> attribute and the max attribute, so to impose *some* limits, people 
> would use maxlength.

That will work, yes. It's not conforming, because that way validators will 
warn you that what you're doing isn't going to work going forward.

Generally speaking, though, even with legacy browsers, if you're asking 
for a _number_ then maxlength="" isn't useful. Supposed you want a number 
between 0 and . Well, "0" and "0.00" are the same number, 
even though one is longer than 4 digits.


On Mon, 19 Aug 2013, Ryosuke Niwa wrote:
> 
> Why is the maxlength attribute of the input element specified to 
> restrict the length of the value by the code-unit length?

That's either what most browsers seemed to do when I tested it, or it was 
the most consistent thing to specify based on other things that were 
consistently implemented (e.g. the ".textLength" attribute's behaviour).


> This is counter intuitive for users and authors who typically intend to 
> restrict the length by the number of composed character sequences.

There's actually a number of possible things people might intuitively 
expect it to do -- count graphemes, count Unicode code points, count 
composed characters, count monospace width, count bytes, etc. It's not 
clear to me that there's one answer, nor that, in fact, most authors have 
any idea that there are so many answers to the question "how long is my 
string".


On Mon, 19 Aug 2013, Ryosuke Niwa wrote:
> 
> Also, 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute
>  
> says "if the input element has a maximum allowed value length, then the 
> code-unit length of the value of the element's value attribute must be 
> equal to or less than the element's maximum allowed value length."
> 
> This doesn't seem to match the behaviors of existing Web browsers

That's authoring conformance criteria, not implementation conformance 
criteria.


On Tue, 20 Aug 2013, Jukka K. Korpela wrote:
> 
> Apparently because in the DOM, "character" effectively means "code 
> unit". In particular, the .value.length property gives the length in 
> code units.

Specifically, UTF-16 code units.


> > > In fact, this is the current shipping behavior of Safari and Chrome.
> 
> And IE, but not Firefox. Here's a simple test:
> 
> 
> 
> On Firefox, you cannot add a character to the value, since the length is 
> already 2. On Chrome and IE, you can add even a second non-BMP 
> character, even though the length then becomes 4. I don't see this as 
> particularly logical, though I'm looking this from the programming point 
> of view, not end user view.

Which version of IE? I wonder if this changed at some point.


> Interestingly, an attempt like  to limit the 
> amount of *characters* to at most 42 seems to fail. (Browsers won't 
> prevent from typing more, but the control starts matching the :invalid 
> selector if you enter characters that correspond to more than 42 code 
> units.) The reason is apparently that "." means "any character" in the 
> sense "any code point", counting a non-BMP character as two.

This is inherited from JavaScript.


On Thu, 22 Aug 2013, Charles McCathie Nevile wrote:
> > 
> > The basic question is whether a validator should flag  > maxlength="2" value="abc"> as a conformance error or not.  It seems to 
> > me like it should.
> 
> Why? It seems that it generally works in browsers, and has for a long 
> time.

Re: [whatwg] Proposal: API to ask the user for a file

[Ian Hickson]

On Mon, 29 Apr 2013, Jonas Sicking wrote:
> 
> I think all modern browsers intentionally let webpages create custom UIs 
> for  by completely hiding the  and then 
> rendering a custom UI using various  and  tags. When the 
> custom UI is clicked the page calls myInputElement.click() in order to 
> bring up the file picker UI.
> 
> Gecko contains some anti-annoyance protections as to prevent the page 
> from spawning file picker dialogs indefinitely. This is done by hooking 
> up .click() to popup blocking infrastructure.

Turns out .click() wasn't specced yet. I've now specced 
it, along with hooking it up to the popup-blocking logic.


> So the API being requested here is actually available. But in a really 
> ugly way through the HTMLInputElement interface.
> 
> But I don't really buy the argument that we should supply a new one 
> because the existing API isn't "reliably available". If the current API 
> is problematic because there is no way to check if it works, then I'd 
> prefer to add a way to check if it works, rather than adding a whole new 
> API.

Yeah.


On Wed, 1 May 2013, JC wrote:
> 
> I guess I should have mention too that the existing API is not only 
> unreliable but also very inconvenient. Since the trick depends on the 
> "changed" event

Yeah, it's weird that the dialog doesn't block script (since the dialog is 
modal). But I would imagine that any new API we added for this would 
actually be "worse" in this regard; we'd probably end up with a 
Promise-based entirely async, non-modal UI.


> and there's no official way to clear the list of files selected the last 
> time, in order to ensure that the event is fired if the same file is 
> selected again the element has to be removed and replaced by a new one 
> every time the user selects a file

That will be resolved once this is fixed:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=22682

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Script preloading

[Jake Archibald]

On 27 August 2013 22:55, Ian Hickson  wrote:

> On Tue, 9 Jul 2013, Bruno Racineux wrote:
> >
> > Why not simply load all such scripts early in the  with 'defer',
> > which preserves the dependency order as determined by your app. Using
> > 'defer' in head scripts is actually a very good way to preserve script
> > order with non-blocking scripts. And by loading the scripts very early
> > in the , the possibility of a incurred significant delay of
> > DOMContentLoaded, for an eventual large script not yet downloaded, is
> > minimal to none.
>
> This doesn't seem like it handles all the use cases (e.g. T and U).
>

Worth noting that defer is busted in IE9 and below, to the point where it's
unusable https://github.com/h5bp/lazyweb-requests/issues/42


> > I would also strongly favor restoring the previous spec portion of
> > 'defer' which allow to have defer on inline script blocks (i.e. if the
> > src attribute is not present). I don't know why this html4 functionality
> > was removed from html5?
>
> Well, primarily because basically nobody implemented it, but also, because
> it's not clear what the point is. Why would you need it?
>

I like my scripts to be inert, as in have no impact on the page (like
jquery). I use a small inline script to start the work needed for that
page, meaning I know the starting point for all JS interacting with the
page is somewhere in an inline script. This is much easier to maintain than
scripts that trigger themselves ondomready depending on what they see in
the DOM.

I'd have liked defer (to work in IE and) to work on scripts without src. In
your proposal, does this work?…


...

   activateTheAlmightyWebsockets();



> On Mon, 15 Jul 2013, Kornel Lesiński wrote:
> > ES6 modules however do not solve the performance problem. In fact they
> > would benefit from UA having a list of all dependencies up front
> > (otherwise file's dependencies can only be discovered after that file is
> > loaded, which costs as many RTTs as the height of the dependency tree).
> >
> > So I think that eventually ES6 modules + link[rel=subresource] could be
> > the answer. The  would expose URLs to (pre)load for performance,
> > but modules would handle actual loading/execution for flexibility and
> > reliability.
>
> The ES6 module doesn't address some of the use cases above, as far as I
> can tell (e.g. Q, U) and require a lot of work to handle some of the
> others. But it seems important that anything we add to HTML be designed to
> work with ES6 modules on the long run.
>

There seems to be a lack of data on how modules would work in the browser.
Eg, when/if they block further rendering. Or is that in the doc & I'm just
not getting my head around it?

It'd be great if modules can solve these but also give the UA all the
requirements up front (or maybe that's the job of HTTP2).


> On Wed, 10 Jul 2013, Jake Archibald wrote:
> >
> > If "dependencies" took a CSS selector it could be:
> >
> > 
> >
> > Now the number of scripts with class "cms-core" can change between
> > versions of the CMS but the plugin still waits for them all. No ID
> > generation needed.
>
> Using a selector is an interesting idea.
>
> It makes it harder to detect and prevent loops, but not fatally so.
>

I'm not sure it's possible to get into loops with this. I imagined
dependency resolution to happen once, on element creation or adding to
document (whichever happens latest). So with:




…the first script would have zero dependencies, because the selector
matches zero elements. The second would depend on the first, so the
execution order is a.js, b.js. The thing I like about the selector thing is
you can very easily get (almost) async=false behaviour:






>elements get a new whenneeded="" attribute, which delays the
>   execution of the script until the