Re: [whatwg] Comments on

[Scott González]

jQuery UI uses open(), close().



On Tue, Dec 17, 2013 at 1:15 AM, Matt Falkenhagen wrote:

> On Fri, Sep 27, 2013 at 7:15 AM, Ian Hickson  wrote:
> >
> > On Mon, 26 Aug 2013, Ojan Vafai wrote:
> > >
> > > IMO, showModalDialog is the legacy broken API we're stuck with. Better
> > > to name the new thing in a way that's self-consistent and consistent
> > > with everything else (i.e. openModal).
> >
> > I started doing this, since several people have asked about this and it
> > seems the consistency between showModalDialog()/close() seems less
> > interesting to people than the consistency with "open" everywhere else.
> > However, it turns out this would make the show() method clash with the
> > "open" IDL attribute on , which we want since it matches the name
> > of the open="" content attribute which matches .
> >
> > Note that window.open() and document.open() don't really do the same as
> > this method does, either. window.open() creates a new Window, or
> navigates
> > and existing one; document.open() resets the document. dialog.show() just
> > changes the dialog to be visible.
> >
> > Also, there's an interesting mix in other APIs. (Disclaimer: I don't know
> > many of these APIs personally, so I may be misinterpreting their
> > documentation wildly. I basically looked for terms like "open" and
> "close"
> > in the docs and tried to see what the right methods were in each case. I
> > only included methods for modal dialogs if there was a trivial method;
> > many APIs have to be configured to make dialogs modals separately.)
> >
> >  Android uses show() and dismiss()
> >  Closure uses setVisible()
> >  Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:.
> >  Delphi uses Show(), ShowModal(), Hide(), and Close().
> >  Ext JS uses show(), hide(), and close().
> >  jQuery uses "open" and "close".
> >  Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close().
>
> Gtk also has gtk_widget_hide(), see [0]
>
> >  .NET uses Show(), ShowDialog(), Hide(), and Close().
> >  Win32 uses ShowWindow() and CloseWindow().
> >  X11 uses XMapWindow() and XUnmapWindow()
> >
> > Most of the APIs I looked at use "close". Most use "show". So I think
> > we're in ok company here.
>
> Sorry to add feedback so late. Whenever there's a post/tweet about
> Chrome's , the most common complaint from devs seems to be this
> show/close naming.
>
> I think with any naming choice there will be an inconsistency somewhere
> in the whole platform API. For example, show/hide is a little weird since
> dialog.hide() is different from dialog.hidden = true. But show/close are
> immediately inconsistent with themselves which gives people an adverse
> reaction.
>
> I think I'd prefer, in order:
> 1) open()/openModal()/close() and "opened" attribute
> 2) show()/showModal()/hide() and "open"
> 3) show()/showModal()/close() and "open"
>
> 1) is nice because it's internally consistent. The downside is that
> dialog.opened is inconsistent with details.open.
>
> In the list of existing APIs above, only Win32 has only show/close. Of APIs
> that have all of show/hide/close, it looks like close does something like
> dispose of the object/free its memory so it can't be shown again (e.g., see
> [1][2][3]) So show/hide for  seems more consistent than
> show/close with these APIs.
>
> Some additional data points:
> - QT uses show(), hide(), close(), done() (close/done delete the dialog)
> [4]
> - Dojo uses show(), hide() [5]
> - Java AWT uses setVisible() (show() and hide() are deprecated, also
> there is a dispose()) [6]
> - Blackberry uses show(), close() [7]
> - Xt uses XtPopup(), XtPopdown() [8]
> - wxWindows uses Show(bool), ShowModal(), EndModal(), Close() [9]
> - YUI uses show(), hide() [10]
> - Bootstrap uses show(), hide() [11]
> - GWT uses show(), hide() [12]
>
> It seems existing JS frameworks mostly use show/hide, maybe because they
> predate element.hidden.
>
> [0] https://developer.gnome.org/gtk3/stable/GtkWidget.html
> [1]
> http://www.objis.com/formationextjs/lib/extjs-4.0.0/docs/api/Ext.window.MessageBox.html
> [2]
> http://stackoverflow.com/questions/2075405/how-to-close-non-modal-form-in-delphi
> [3]
> http://www.dummies.com/how-to/content/opening-closing-and-hiding-forms-with-visual-basic.html
> [4] http://qt-project.org/doc/qt-4.8/qwidget.html#close
> [5] http://dojotoolkit.org/api/?qs=1.9/dijit/Dialog
> [6] http://docs.oracle.com/javase/6/docs/api/java/awt/Dialog.html
> [7]
> http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/ui/component/Dialog.html
> [8] http://www.unix.com/man-page/all/3x/XtPopup/
> [9] http://docs.wxwidgets.org/stable/classwx_dialog.html
> [10] http://yuilibrary.com/yui/docs/api/classes/Panel.html
> [11] http://getbootstrap.com/javascript/#modals
> [12]
> http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/ui/DialogBox.html
>

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

[Scott González]

On Fri, Sep 6, 2013 at 8:47 AM, Scott González wrote:

> On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. wrote:
>
>> On Fri, Jun 28, 2013 at 2:28 PM, Zirak A  wrote:
>>  > Besides my personal aversion towards selectors being in the DOM API,
>> there's
>> > also the simple fact that it makes sense for document fragments to have
>> these
>> > methods.
>>
>> That's far from obvious, given that I don't think it makes sense to
>> spread those obsolete methods around any further.
>>
>
> They were already spread to ShadowRoot. Does anyone have a reference to
> that discussion that led to that decision? It seems like if they're being
> added to ShadowRoot, which inherits from DocumentFragment, we might as well
> just add them to DocumentFragment and be done with it. At least from a
> non-implementor's view that seems to make sense.
>

I don't think there was any response to this. What is the reason for
keeping these methods off of DocumentFragment if new APIs which inherit
from DocumentFragment are going to have the methods anyway?

Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll

[Scott González]

So you're suggesting new globals that are bound to the document? That
sounds really bad. Also, there's no reason to suggest an alias to
querySelector() when it's much more likely that query() will be used by the
majority of developers.


On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov wrote:

> *The problem:*
> document.querySelector and document.querySelectorAll
> are long and used a lot.
>
> Lines in the code are long.
>
> *Proposal:*
> q('.my-div')
> will be equal to:
> document.querySelector('.my-div)
>
> qq('.my-div')
> will be equal to:
> document.querySelectorAll('.my-div')
>
>
> --Leon Gilyadov.
>

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

[Scott González]

On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. wrote:

> On Fri, Jun 28, 2013 at 2:28 PM, Zirak A  wrote:
> > Besides my personal aversion towards selectors being in the DOM API,
> there's
> > also the simple fact that it makes sense for document fragments to have
> these
> > methods.
>
> That's far from obvious, given that I don't think it makes sense to
> spread those obsolete methods around any further.


They were already spread to ShadowRoot. Does anyone have a reference to
that discussion that led to that decision? It seems like if they're being
added to ShadowRoot, which inherits from DocumentFragment, we might as well
just add them to DocumentFragment and be done with it. At least from a
non-implementor's view that seems to make sense.

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

[Scott González]

On Fri, Sep 6, 2013 at 8:40 AM, Simon Pieters  wrote:

> On Fri, 06 Sep 2013 14:21:24 +0200, Scott González <
> scott.gonza...@gmail.com> wrote:
>
>> Yes. Take the example of finding the input associated with a label:
>>
>> foo
>> 
>>
>> If you have a reference to the label and you want to find the input, you
>> need to escape the value of the for attribute before querying.
>>
>
> In this example, are the elements in the document?


For jQuery, the answer tends to be "it doesn't matter." There are very few
places where we treat in-document and out-of-document situations
differently.

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

[Scott González]

On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters  wrote:

> So the use case is getting an element by id with an "untrusted" id as
> input, in an element or document fragment as opposed to the document?
>

Yes. Take the example of finding the input associated with a label:

foo


If you have a reference to the label and you want to find the input, you
need to escape the value of the for attribute before querying.

Re: [whatwg] Ignore min and max if min > max

[Scott González]

It's been a while since I read the spec, but I can say that the behavior in
jQuery UI is in line with Hixie's response. We do nothing to adjust the
user-specified min/max/step, but never allow changing to a value that
doesn't fit in the specified range. If you specify a max lower than the
min, any value you try to set will be converted to the max. I was actually
expecting to see us return the min in this case, just because the
sanitization process starts at the min.


On Tue, Jul 30, 2013 at 7:13 PM, Ian Hickson  wrote:

> On Wed, 17 Apr 2013, Mounir Lamouri wrote:
> >
> > Currently, the specification seems to take care of min > max by simply
> > making the element suffering from a value underflow such as a value
> > overflow. Also,  has a special behaviour in that
> > situation. However, if you try different implementations, the behaviours
> > when min > max a widely different and generally speaking, such context
> > can create pretty broken UI: a slider that can't move, a number spinner
> > that doesn't allow changing the number's value, etc.
> >
> > I believe that having a special behaviour when min > max would be
> > appropriate here. Basically, the min and max attributes should be
> > ignored in that situation. That means that the element's 'minimum' and
> > 'maximum' should be ignored in that situation unless there is a 'default
> > minimum' or a 'default maximum' (which would be used).
> >
> > Adding this to the specification would help having a decent fallback
> > when the attributes are broken instead of broken form controls.
> >
> > FWIW, Chrome's implementation of  seems to simply
> > ignore min and max when min > max. Opera doesn't show any UI in that
> > case.
>
> Generally speaking, we define the behaviour when the markup is bogus, but
> we don't go out of our way to make it useful, for two main reasons: first,
> it's hard to tell what is useful when the information we have is known to
> be wrong (did they get them backwards? Did they omit a digit in the "max"
> value? Did they put the decimal in the wrong place on the "min" value?),
> and two, by having useful behaviour we make it much less likely that
> errors will be caught (it's easier to catch a bug if users can't enter any
> valid data at all, than it is if the error checking is just disabled).
>
> Are we sure we really want to go down this path?
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Maxlength attribute on input[type=number]

[Scott González]

Why would you want to set maxlength as opposed to setting max?


On Thu, Jun 27, 2013 at 5:42 PM, Steve Hoeksema  wrote:

> Hi,
>
> 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?
>
>
> Cheers,
>
> Steve
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary
> [2] https://code.google.com/p/chromium/issues/detail?id=253798
>

Re: [whatwg] Allowing authors to obtain a vertical

[Scott González]

On Fri, Mar 29, 2013 at 1:28 PM, Ian Hickson  wrote:

> On Tue, 26 Mar 2013, Scott González wrote:
> > No, auto is not useful in practice. We had this in jQuery UI and removed
> > it four years ago because it was a bad idea.
>
> Why is it a bad idea?


Because it's one of those features that sneaks up on you when you least
expect it. We had several complaints from users about this behavior.

If auto orientation is added, we'd also need to define whether the
orientation is calculated just on insertion or if it updates with layout
changes.

Re: [whatwg] Allowing authors to obtain a vertical

[Scott González]

On Tue, Mar 26, 2013 at 11:19 AM, Simon Pieters  wrote:
>
> Is 'auto' useful in practice? Is it a behavior that authors or users
> expect? I don't know, but my hunch is "no", and it would be more
> straightforward to just use horizontal and let the author opt-in to
> vertical with the attribute.


No, auto is not useful in practice. We had this in jQuery UI and removed it
four years ago because it was a bad idea.

Re: [whatwg] More stepUp() and stepDown() comments (was: Re: Forms-related feedback)

[Scott González]

On Wed, Jan 30, 2013 at 2:21 PM, Ian Hickson  wrote:

> Does anyone have any examples of UIs that give "page up" and "page down"
> controls to change values that can also be set to out-of-range values so
> we can study how existing UIs handle this?


In Chrome Dev Tools, setting z-index: 1.1 and then pressing SHIFT+UP moves
the value to 11.1. I don't believe the dev tools ever correct for step
mismatches or guard against out of range errors. I don't think that's the
result we want though, since we should end up on a valid value.

Re: [whatwg] Controlling the UI on

[Scott González]

The only thing I've seen in a spec was CSS3 System Appearance, but it had
poor support and was ultimately removed.

2 years ago, I contacted people from Mozilla, Google, Microsoft, and Opera
about this, but I haven't seen any real progress. A few weeks ago, support
for  landed in Chrome Canary and this fiddle was
provided to show how to prevent the calendar from showing up:
http://jsfiddle.net/PPpUu/ This is clunky and doesn't even fully solve the
problem.

Here's one of the emails I sent after getting a response about device
vendors wanting to provide consistent UI/UX throughout the device (tying
their native calendar into controls like ):

The problem is that no matter how consistent the UI/UX is, I want to
> opt-out because it will never be good enough. I want to customize the UI to
> look like my app, layer on additional functionality, etc. All of this is
> possible today without the new input types. However, once the new input
> types are used, this becomes more difficult. For example, enhancing a text
> field into a datepicker is really common, but you can't do this with a date
> field because of the new UI. I really don't think that JS implementations
> of these input types are ever going to die, no matter how good the native
> implementations work. There's just too much functionality that users will
> want that won't be possible because the APIs would be too large to spec.
> Falling all the way back to text fields works, but then we lose all the
> other benefits, such as the new attributes/methods, built-in validation,
> type-specific virtual keyboards, etc.
> So the end goal is still to have consistent UI/UX cross-browser, but not
> necessarily cross-site.


We get a lot of requests for jQuery UI widgets to work on the new input
types. However, as things are right now, all we can do is say no.


On Thu, Dec 6, 2012 at 3:46 PM, brenton strine  wrote:

> It is currently difficult to control the visibility of the UI (e.g. little
> arrows, spinners, etc) on new input types like datetime, number, range,
> color, etc.
>
> It seems that many developers want to use the semantic attributes, but need
> to be able to hide the little arrows for various reasons, and so they are
> sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897
>
> ).
>
> Reasons developers might want to control the visibility of the UI:
> - developer has built their own datepicker/numberfinder/colorpicker/etc
> - developer wants to display just the values (as if it were type=text) upon
> printing, or when readonly, or when not active
>
> As browsers add support, there will likely be ways to control this using
> vendor-specific CSS, but not only will this vary from browser to browser,
> it will vary among the different input types. For example, in Chrome it is
> currently possible to hide the slider arrows on the number input:
>
> input[type="number"]::-webkit-inner-spin-button{
> -webkit-appearance: none;
> }
>
> This kind of code is clearly going to be very difficult to maintain and
> keep up to date. I don't think a CSS solution is going to work. Has there
> been discussion here on an input attribute that controls the UI? Perhaps
> something like this:
>
> 
>

Re: [whatwg] Make stepUp() and stepDown() more developer-friendly

[Scott González]

On Tue, Nov 20, 2012 at 5:55 PM, Ian Hickson  wrote:

> > I can list out the steps we take for all conditions, but I'd like to
> > hear everyone's thoughts on the various cases where you're suggesting
> > that the methods do nothing.
>
> Mostly I agree with Mounir here, but I'm curious about what you think
> should happen for the case where there's no value, and the case where the
> control isn't a numeric/date/time type. I could see an argument for
> stepping from the default in the former case (Mounir, what do you think
> about doing that?) but for the latter case I don't really see any point
> doing anything but throw an exception, as Mounir suggested.


For any non-parsable value (including no value), we start at 0, take the
step, then confine to a valid step within min/max.

I think it makes sense to throw if the control doesn't support stepping.

Re: [whatwg] Make stepUp() and stepDown() more developer-friendly

[Scott González]

Can you explain why these methods should be no-ops if the value is above
the max or below the min? In jQuery UI, we decided that using these methods
should always result in a valid value.

I can list out the steps we take for all conditions, but I'd like to hear
everyone's thoughts on the various cases where you're suggesting that the
methods do nothing.


On Tue, Nov 20, 2012 at 6:49 AM, Mounir Lamouri  wrote:

> Hi,
>
> Currently stepUp(n) and stepDown(n) are very basic methods. They more or
> less do value += n * allowedValueStep; with n = -n; if stepDown() was
> called. In addition of being pretty dumb, there are a lot of reasons why
> they can throw.
>
> At Mozilla, we think that the main use case for stepUp() and stepDown()
> is to create a UI with spin buttons: clicking on the up arrow would call
> stepUp() and clicking on the down arrow would call stepDown(). Such a
> use case needs methods that do better than just adding n *
> allowedValueStep.
> In addition, we think that throwing is very often a bad idea and that
> should happen when the developer clearly did something wrong.
>
> So, we would like to change the stepUp()/stepDown() algorithm to match
> the following behaviour:
> - we only throw if the input type doesn't allow those methods or if
> there is no allowed value step;
> - if the value isn't a number (aka empty string), we should just exit
> the steps;
> - if the value is below the minimal allowed value and n is negative, we
> should exit the steps;
> - if the value is above the maximal allowed value and n is positive, we
> should exit the steps;
> - if the element is suffering from a step mismatch, and n is negative,
> the value should be changed to the next valid value. Otherwise, it
> should be changed to the previous allowed value;
> - newValue = value + n * allodValueStep;
> - if the newValue is below the minimal allowed value, the newValue
> should be equal the minimal allowed value;
> - if the newValue is higher than the minimal allowed value, the newValue
> should be equal the minimal allowed value.
>
> Such a behaviour creates a real added value in stepUp() and stepDown()
> that make those methods useful compared to simply do value += n *
> allowedValueStep; and prevent throwing when there is no need to.
>
> It is interesting to see that  spin buttons in Chrome
> have that behaviour [1] but stepUp() and stepDown() do not.
>
> Opera has the same kind of UI behaviour than Chrome and
> stepUp()/stepDown() tries to be more clever than what the specifications
> say (it is clamping to the nearest allowed value). However, it is still
> throwing too much.
>
> You can try the implementation of stepUp() and stepDown() in Firefox
> desktop by enablinig the pref "dom.experimental_forms" or by using
> Firefox Android (no need to toggle any pref).
>
> You can use this page to test:
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918
>
> [1] The only difference between Chrome's spin buttons behaviour and our
> proposal is that when value is the empty string, it is setting value to
> 0 and continue to the next steps (unless the 0 is below the minimal
> allowed value and n < 0, in that case value=min). It might be
> interesting to specify something better than "do nothing" if value="".
>
> Cheers,
> --
> Mounir
>

[whatwg] Modal Dialog Focus

[Scott González]

The dialog.showModal() function defines steps for setting focus [1].
However, if the dialog does not contain any elements with the autofocus
attribute, then step 9 says to abort the steps and not set focus. It seems
problematic if the dialog is modal and does not have focus. How would a
keyboard user interact with the dialog? How would a screen reader know that
the dialog has been shown?

I would expect the control element to fall back to the first tab focusable
element if no element with autofocus exists. If there is still no control
element, I would expect the dialog itself to receive focus.

ARIA requires the element to contain at least one tab focusable element [2].

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#dom-dialog-showmodal
[2] http://www.w3.org/WAI/PF/aria-practices/#modal_dialog

Re: [whatwg] Problem in the Section "4 Elements of HTML => 4.4 Sections => 4.4.2 The Section element

[Scott González]

I personally find that having such an uncommon syntax is actually
distracting.

On Thu, Sep 13, 2012 at 2:28 PM, Jukka K. Korpela wrote:

> 2012-09-13 21:15, Tab Atkins Jr. wrote:
>
>  Hixie purposely varied his style across
>> examples, to show that certain variances in the syntax were allowed
>> and perfectly fine.
>>
>
> Oh, I see. It's somewhat questionable if you ask me. Varying the syntax
> _within a document_ is something different from the liberty of choosing
> one's style. But I guess the reader is assumed to treat the examples as
> quotations that reflect different styles (and style is consistent within
> each example).
>
> Still, I wouldn't do that. I don't think authors really need to be
> reminded of the possibility of writing  instead of the most common
> way, , and the next common one, . People who have some
> special reason for writing, say,
>
> 
> claSs
>
> =  foo
>
> >
>
> should probably check the syntax definition details if in doubt, and just
> go ahead (maybe using a validator) if not.
>
> Yucca
>
>
>

Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)

[Scott González]

Has there been any more discussion outside of this thread?


On Fri, May 11, 2012 at 1:53 PM, James Greene wrote:

> Alright... so what's next?  I'm assuming this needs further discussion with
> other WHATWG members chiming in.  If I can help, please let me know. I'd
> like to see this request through.
>
> Sincerely,
> James Greene
>
>
>
>
> On Fri, May 11, 2012 at 12:26 PM, Simon Pieters  wrote:
>
> > On Fri, 11 May 2012 17:14:00 +0200, James Greene <
> james.m.gre...@gmail.com>
> > wrote:
> >
> >  Simon:
> >> Yeah, I misunderstood your previous mention of having it as a [fifth]
> >> string argument.  I somehow associated that automatically with the
> >> "message" parameter (the only string argument, I suppose) but I also
> >> noticed my mistake after I sent the email.
> >>
> >
> > OK.
> >
> >
> >  I personally am interested in adding the stack trace, yes,
> >>
> >
> > OK, thanks.
> >
> >
> >  but ideally I
> >> would just have access to the full "Error" object so I can always have
> an
> >> up-to-date model if the "Error" object continues to change (as it
> probably
> >> will).
> >>
> >
> > That's fair enough. Though not all exceptions are Errors -- DOMException
> > currently isn't, though I think some people want it to somehow inherit
> from
> > Error.
> >
> >
> >  For example, some devs may be interested in the "Error" object's
> >> "name" property, which is already a part of the object today but is not
> >> provided to "window.onerror" callbacks.  And again, if additional
> >> properties are added in the future, it's just more and more properties
> >> that
> >> may need to get incrementally added to the "window.onerror" invocation
> >> arguments list.  For example, I proposed the addition of an "innerError"
> >> property (or some would call it "cause") for chaining errors and masking
> >> internal errors that consumers shouldn't see, instead providing a
> >> customer-facing message.
> >>
> >
> > Yeah.
> >
> >
> >  You keep mentioning compile errors and how they don't have associated
> >> "Error" objects but it sounds like they still reach the "window.onerror"
> >> callbacks.  Can you add a little commentary on that?
> >>
> >
> > Here are some examples:
> >
> >  onerror = function(a,b,c) { alert(a+b+c) }; 
> >  foo();  
> >  for (;)  
> >  setTimeout('for (;)', 0);  
> >  
> >
> >
> >
> >  I thought they
> >> utilized the "SyntaxError" class but perhaps that's only for "eval()"
> >> calls...?
> >>
> >
> > Yes. Since the script doesn't compile, the same script can't catch any
> > exception in a try/catch block. onerror is just invoked with the
> > appropriate arguments, and currently doesn't expose any object. Hence,
> > compile errors currently do not expose any exception that Web pages can
> > observe. However, if we change onerror and expose the exception object
> for
> > uncaught exceptions, it would certainly make sense to specify that
> compile
> > errors be exposed using SyntaxError exceptions.
> >
> > If we expose the exception object in onerror (which I actually think
> makes
> > sense), what do we want to happen for cross-origin script errors? null?
> The
> > current arguments are masked as ("Script error.", "", 0, 0).
> >
> >
> >  I may also be thinking of this differently as a JS engineer
> >> versus a browser vendor, so please help clue me in.  I'm interested to
> >> learn more on this, and it may help me better appreciate why the
> >> "window.onerror" callback mechanism *didn't* just pass an "Error" object
> >> from the beginning.
> >>
> >
> > I think onerror is an old feature dating back from old Netscape or IE
> > (don't know which). Then other browsers just copied it.
> >
> >
> >  I appreciate your continued feedback. Thanks!
> >>
> >
> > cheers
> >
> > --
> > Simon Pieters
> > Opera Software
> >
>

Re: [whatwg] / not needed

[Scott González]

On Thu, May 17, 2012 at 12:45 PM, Aldrik Dunbar  wrote:

> In that case it sounds like we need somthing like the -ms-high-contrast
> [1] media feature needs to become a standard.
>
> [1] http://msdn.microsoft.com/en-us/library/ie/hh771830(v=vs.85).aspx
>

I hadn't seen that before, I was actually going to propose this at some
point in the future (whenever we get around to high contrast support in
jQuery UI). I think standardizing this would be really useful, I'll start a
separate thread for this; hopefully we can get some input from Apple.

Re: [whatwg] / not needed

[Scott González]

On Thu, May 17, 2012 at 10:24 AM, Aldrik Dunbar  wrote:

> On 2012/05/17 09:17, Scott González wrote:
> > I don't think this should just be about device capability. Users with
> > vision problems may opt-in to high contract mode and you may need to load
> > different resources based on this.
>
> I think assertive technology's can handled high contrast and colour
> blindness filters (additional images aren't really needed). Also
> monochrome can already be catered for with SVG/CSS.
>

Assistive technology can't magically detect that your image has low
contrast and provide a better image. I don't think that AT even comes into
play as high contrast mode is handled by the OS. High contrast mode is not
the same as choosing a monochrome display. On Windows, the default high
contrast display is mostly white on black, but there are still colors, and
text is larger. On OS X, high contrast mode is just extremely contrasty
with lots of detail getting washed out; you can separately choose to use
grayscale and/or invert colors.

Authors may want to provide images with lots of detail, but fall back to
images with less detail and/or larger objects/text in the case of high
contrast mode.

Re: [whatwg] / not needed

[Scott González]

On Thu, May 17, 2012 at 7:30 AM, Bjartur Thorlacius wrote:

> How common will it be for modern UAs to render pages to monochrome
> displays using future HTML5 graphics features? How many of the monochrome
> displays that are left will be attached to systems with modern heavy-weight
> software? In fact, the only systems I know of that come close to being
> monochrome are handhelds whose software isn't ever updated, and terminals
> that aren't even used to display bitmaps. So I have to ask, for how long
> will color-depth negotiation be a strong enough use case to warrant this
> feature?
>

I don't think this should just be about device capability. Users with
vision problems may opt-in to high contract mode and you may need to load
different resources based on this.

Re: [whatwg] for responsive bitmapped content images

[Scott González]

You should look into the previous discussions at
http://www.w3.org/community/respimg/

There's also a prototype using media queries at
https://github.com/scottjehl/picturefill. I realize you specifically said
you think media queries don't solve all of the problems, but it seems worth
looking at.


On Thu, May 10, 2012 at 3:58 AM, 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 than it is in CSS (and it can be a
> pain in CSS). I think we can best address this problem for bitmap[1]
> content image by the addition of a srcset="" attribute to the existing
>  element.
>
> The srcset="" attribute takes as its argument a simplified variant of
> the image-set() microsyntax[2]. It would look something like this:
>
>  srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
> alt="decent alt text for foo.">
>
>  takes one or more comma separated image specifiers. An
> image specifier consists of a URL to an image asset and an associated
> scale factor, expressed as a number followed by the literal character
> 'x'. (The value of  is treated as if it had a 1x scale
> specified, so you can avoid duplicate references to the base asset.)
>
> User Agents may make their asset selection before fetching any of the
> assets, thus avoiding multiple asset loads & the associated performance
> problems in constrained bandwidth environments.
>
> The intrinsic size of the  can be computed by dividing the
> intrinsic size of the actual image asset chosen with that asset's
> associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
> foo-highres.jpg is 200x200 in the above example. If the UA chooses
> foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
> 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
> size as (200/2)x(200/2) = 100x100.
>
> A nice thing about this proposal is its backwards compatibility story.
> Browsers which don't yet support  will simply use the asset
> referenced by . A polyfill could easily be written to check for
>  & swap out a different asset into , much like
> existing libraries which check for data-fullsrc="" or the like.
>
> Why provide a scale factor and not a media query? Well, media queries
> are claims about UA state, whereas here we're asserting something about
> the relationship between the image assets. Also, User Agents should be
> free to use whichever asset they deem best suited to their current
> situation, taking into account not just "media-queriable things" like
> device resolution but also any scaling applied to the  with CSS,
> its width="" and height="" attributes, or even things like the current
> page zoom level.
>
> Of course there are other things like bandwidth availability, data plan
> usage, etc. that web developers might want to take into account when
> choosing which image assets to load. This is definitely something worth
> exploring. In the future we could extend the asset descriptors to cover
> such cases. Something like this, maybe:
>
>  
>
> I'm purposefully not making a proposal for how to describe bandwidth,
> data plan usage, or such things here. Ultimately I don't think
> addressing the multiple-resolution case needs to wait for a solution to
> these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.
>
> One downside to this proposal is that the srcset="" attribute takes a
> microsyntax, and as a rule we try to avoid novel microsyntaxes in
> attribute values. I think this particular microsyntax is pretty
> straightforward and shouldn't cause all that much confusion for authors.
>
> I think this is preferable to adding a suite of attributes with complex
> inter-relationships, such as in Anselm Hannemann's proposal from last
> August[3]. In such a proposal, we would either need to have a pre-
> approved list of image scales (like Anselm's xs, s, m, l, xl), which
> over-constrains designers' ability to create, or we would be introducing
> user data into attribute names which—with the one exception of the
> data-*="" attributes—is something I really don't think we should do.
>
> Some have argued that we should "just use conneg" to serve the best
> image. This isn't an acceptable solution for at least three reasons:
>
> * The server doesn't have all of the relevant information needed to
>  pick the best image, and sending that information with every image
>  asset request is bandwidth-intensive and enables increased user
>  fingerprinting.
>
> * HTML is used in a lot of contexts, such as in EPUB, in which there's
>  no server to negotiate with in the first place.[4]
>
> * The UA should be able to "swap out" one asset for another
>  transparently after the page has loaded. For instance, the UA might
>  want to swap things out when the user zooms in.
>
> I also think thi

Re: [whatwg] Device proximity and light events

[Scott González]

The original question was "How do you detect if the UA supports each of
these sensor?"

I don't think we're asking whether you'd get events, but whether you can
detect that the UA actually supports the event. I would think the UA should
expose support (via onxxx attributes) if the UA and device actually have
support, even if the sensor is turned off. There may be a separate API for
determining if the sensor is turned on, but I don't think that's what was
being asked.


On Wed, May 9, 2012 at 10:48 AM, Doug Turner  wrote:

> That is different -- Hixie can chime in.
>
> I think the idea is that if you have and dom event handler, you should
> also have an on event handler attribute.  Its meaning is less defined.
>  I do not think it means that if ondevicemotion exists, that means you will
> always see device motion events.
>
> Doug
>
>
> On May 9, 2012, at 7:45 AM, Scott González wrote:
>
> > There was a related discussion on the mailing list:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029252.html
> >
> > I also found a message from Hixie to me, related to that thread: "I
> agree entirely that if an event has a use case, it makes sense for it to
> have an event handler attribute."
> >
> >
> > On Wed, May 9, 2012 at 10:31 AM, Doug Turner  wrote:
> >
> > On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:
> >
> > > On Wed, May 9, 2012 at 5:59 AM, Doug Turner  wrote:
> > >> Where was that discussion?
> > >
> > > This came up at the WebApps F2F and there was general agreement that
> > > if we added new events adding new event handler attributes would make
> > > sense.
> >
> > Was there any notes taken?
> >
> >
> > > Feature detection of some kind is useful as forcing people to
> > > do UA sniffing leads to badness.
> >
> > I am not arguing that it shouldn't be done.   I just don't think it as
> important as most people.  For example, even if the device is present, it
> may be off or not responding.  In that case, you'll have a feature that
> tests positive and never receive any events.
> >
>
>

Re: [whatwg] Device proximity and light events

[Scott González]

There was a related discussion on the mailing list:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029252.html

I also found a message from Hixie to me, related to that thread: "I agree
entirely that if an event has a use case, it makes sense for it to have an
event handler attribute."


On Wed, May 9, 2012 at 10:31 AM, Doug Turner  wrote:

>
> On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote:
>
> > On Wed, May 9, 2012 at 5:59 AM, Doug Turner  wrote:
> >> Where was that discussion?
> >
> > This came up at the WebApps F2F and there was general agreement that
> > if we added new events adding new event handler attributes would make
> > sense.
>
> Was there any notes taken?
>
>
> > Feature detection of some kind is useful as forcing people to
> > do UA sniffing leads to badness.
>
> I am not arguing that it shouldn't be done.   I just don't think it as
> important as most people.  For example, even if the device is present, it
> may be off or not responding.  In that case, you'll have a feature that
> tests positive and never receive any events.

Re: [whatwg] Device proximity and light events

[Scott González]

On Tuesday, May 8, 2012, Doug Turner wrote:

> You don't.  This API doesn't have device detection.  Don't assume that
> onXXX means that the UA supports an event.
>

I thought this was the preferred way to check. I seem to recall a
discussion about this and agreement that this was the best way to detect
events.

Re: [whatwg] Fullscreen changes to support

[Scott González]

On Thu, Apr 5, 2012 at 3:58 AM, Anne van Kesteren  wrote:

> I can see how it makes sense in the abstract. Browsers moved away from
> application-global modal dialogs to tab modal dialogs. I could see Twitter
> still wanting to you let you switch to @Connect or #Discover or search,
> while a modal dialog with user information is open. However, we could do
> that in a future version by allowing the size of ::backdrop to be adjusted
> by setting the top/left/bottom/right properties. Does that make sense?
>

I think in general, users will want to constrain to a specific element's
dimensions. In the vast majority of cases where I see anything constrained,
the dimensions are calculated based on the position and/or dimensions of
another element. However, there are definitely cases where users want to
constrain based on specific locations which may not be related to an
element.

I would also say that a large percentage of users struggle with
position/offset math, so defining top/left/bottom/right properties may be
tough for the average user. This is complicated by the fact that the
content on a page is likely dynamic and therefore so is the size of what
needs to be covered. I expect this would be further complicated by
responsive designs where the dimensions may change at any point, are are
likely not defined in pixel values in the first place. Perhaps the partial
page covering scenarios are uncommon enough that users who want this
functionality will have the knowledge required to implement it properly.

Re: [whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."

[Scott González]

It's my understanding that authors should only apply ARIA via script. The
redundancy cases seem to be the most reasonable use cases I've heard of for
wanting ARIA in the initial markup, but even that seems wrong. What happens
when you have type=range and role=slider, the UA doesn't understand the new
types, and the script either never loads or has an error? The AT will pick
up the role, but none of the functionality will be there. I don't see how
that's better than not having the role applied.


On Tue, Mar 13, 2012 at 3:11 AM, Charles Pritchard  wrote:

> On 3/12/12 11:42 PM, Simon Pieters wrote:
>
>> On Tue, 13 Mar 2012 02:16:29 +0100, Charles Pritchard 
>> wrote:
>>
>>  Warnings are generally not useful. Either something is fine and we should
 support it, or it's wrong and we should alert the author. I think "must"
 is very much the appropriate requirement level here.

>>>
>>>  From the implementation-side, the spec is wrong, it ranks native HTML
>>> semantics above ARIA DOM semantics.
>>>
>>
>> You're confusing author conformance requirements with UA conformance
>> requirements.
>>
>
> The section did confuse me. It lays out some author requirements then goes
> into what looks like appropriate UA mapping.
> I don't see this working well for ARIA conformance testing, but I do like
> the mapping.
>
> This document tries to set strict requirements on authors for ARIA usage
> which doesn't exist in practice.
> It's intended to help, but I don't think it's needed; I believe it adds
> confusion.
>
> The Restrictions seem fine for telling vendors that they ought to be
> making their ARIA maps from native HTML to ARIA a certain way.
> But, as you said, I'm getting confused reading this doc.
>
>
>
>  As a "best practices" note, it seems overly optimistic. There are
>>> situations with AT navigation where role conflicts do occur and/or
>>> redundancy in tagging is helpful.
>>>
>>
>> Do you have concrete examples?
>>
>
> Concrete? No. I don't have an active JAWS/NVDA/WindowEyes + HTML4 project
> in front of me.
> If I did, I'm sure I'd have some concrete examples of how ARIA and HTML4
> work together with roles.
>
> Some wild guesses:
> Treating a link as a button or a button as a link.
> @disabled and aria-disabled may be used via reference with aria-controls.
> type="range" and role=slider for redundancy.
> various styling tricks with css selectors.
>
> Steve Faulkner posted that sometimes explicit ARIA roles signal to ATs to
> look for more ARIA attributes.
>
> I've used role and/or redundant ARIA within the scripting environment to
> minimize calls in applications checking for roles. Redundancy doesn't harm
> anything, I actively promote it, as it does help, sometimes. Conflicts can
> be a bad thing, they can lead to non-nonsensical or non-interactive
> reporting by ATs. I realize that, but I'd err on the side of allowing
> authors to make those decisions. They can use various tools that spit out
> warnings.
>
> Ian has stated that warnings aren't very useful, he's looking for error or
> bust. That's confusing when it comes to ARIA testing, as it's more about
> the pragmatic effects of applying semantics and using a variety of ATs to
> test them.
>
>
>  I don't believe it is appropriate for HTML to place restrictions on ARIA
>>> DOM. It's does not reflect implementations.
>>>
>>
>> It does not affect implementations at all.
>>
>
> Then I'm less concerned. My understanding was that this part of the
> specification is intended to affect implementations such that an authors
> use of @role in a tag would be overridden by the browser if that tag is on
> the conflict list.
>
>
>  The HTML spec should only specify what the default mappings are for HTML
>>> elements to ARIA.
>>> Authors may be advised to test AT software with their product.
>>>
>>> This statement is more in line with practice: "Authors must test
>>> accessibility tree as part of development and usage of ARIA semantics.".
>>>
>>
>> That's not machine checkable so less likely to have an effect at all.
>>
> So the "authors must" is for conformance tools? Again, it seems to be
> adding confusion. I'm not the only one.
>
> It looks like a good section explaining mapping to implementers that has
> been turned into a wiffle bat for bopping weary authors on the head.
>
> ARIA is a tool for supporting secondary UAs, not an extension to HTML
> Forms and groups. An aria role does absolutely nothing to alter the
> behavior of the primary UA.
>
> -Charles
>

Re: [whatwg] Caching of identical files from different URLs using checksums

[Scott González]

On Fri, Feb 17, 2012 at 1:39 PM, Ashley Sheridan
wrote:

> But wouldn't this all break one of the key reasons why shared libraries
> are useful? If I'm using a shared Javascript library hosted on Google
> Code, for example, and there's an urgent security update, I'd want it to
> be applied and not left out. Also, plenty of the hosted libraries are at
> URLs that will grab the latest stable release of something. I don't want
> my site to break overnight just because the latest stable release for a
> library came out whilst I was asleep.
>

So don't opt-in? Also, these cases imply that you're utilizing CDNs that
don't provide a good caching benefit.

Re: [whatwg] input element list attribute and filtering suggestions

[Scott González]

On Fri, Jan 20, 2012 at 6:41 PM, Ian Hickson  wrote:

> On Mon, 1 Aug 2011, Aryeh Gregor wrote:
> > On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson  wrote:
> > > My overarching point, however, is that this is a UI issue, and not an
> > > authoring issue.
> >
> > The overarching counterpoint is that in-page UI *is* an authoring issue,
> > because authors want to control exactly how their page looks and
> > behaves.  Browser/chrome UI issues shouldn't be standardized, but page
> > UI issues absolutely should (at least in many cases).
>
> I disagree with this, at least in terms of a general guiding principle.
>

I agree with Ian. I'm not sure how/why something like autocomplete should
be treated different than select elements or alert dialogs. If you need a
lot of control over the appearance or functionality, don't rely solely on
native controls; enhance them with custom JS and CSS. I don't think it's
reasonable for standards to try to address all appearance and functionality
issues. The native implementations should work for everyone and be "good
enough" for the majority. The rest is up to page, library, and framework
authors.

Re: [whatwg] input type=date

[Scott González]

I don't believe so. I also don't think there's any way to do the equivalent
in JavaScript, e.g., asking for a Date object to generate a string
representation in some other locale (aside from UTC).

>From personal experience, I've found that when users need to enter times
for timezones other than their own, the chance of error is high.


2012/1/12 Schalk Neethling 

> yep, that answers my question but, is there any work done to perhaps add
> an attribute where the author can specify the date format they require/want?
>
> Thanks, Scott
>
> ----- Original Message -
> From: "Scott González" 
> To: "Schalk Neethling" 
> Cc: whatwg@lists.whatwg.org
> Sent: Thursday, January 12, 2012 8:39:21 PM
> Subject: Re: [whatwg] input type=date
>
> I think the following note answers your question:
>
> "Note: The format shown to the user is independent of the format used for
> form submission. Browsers are encouraged to use user interfaces that
> present dates according to the conventions of the user's preferred locale."
> -
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date)
>
>
>
> On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling < sneethl...@mozilla.com> 
> wrote:
>
>
> Hey all,
>
> Asked this on IRC and got no response so here goes:
>
> Is there a way to specify the locale input type=daye should use or does it
> simply use the current locale? If so, does it choose the server locale or
> the user locale?
>
> Kind Regards,
> Schalk
> Web Developer @ Mozilla
>
>

Re: [whatwg] input type=date

[Scott González]

I think the following note answers your question:

"Note: The format shown to the user is independent of the format used for
form submission. Browsers are encouraged to use user interfaces that
present dates according to the conventions of the user's preferred locale."
-
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date)


On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling wrote:

> Hey all,
>
> Asked this on IRC and got no response so here goes:
>
> Is there a way to specify the locale input type=daye should use or does it
> simply use the current locale? If so, does it choose the server locale or
> the user locale?
>
> Kind Regards,
> Schalk
> Web Developer @ Mozilla
>

Re: [whatwg] Form element invalid message

[Scott González]

2011/7/28 Scott González 

> There are essentially three choices (this applies to most new markup-driven
> features):
> 1) Provide the information in the appropriate attributes and let the
> browser do its thing.
> 2) Provide the information in a script and do everything via scripting.
> 3) Provide the information in the appropriate attributes, but handle them
> via scripting.
>
> #1 will never be as flexible as #3. #2 is a decent compromise and can be
> made more flexible by allowing additional configuration via scripts. I think
> the spec needs to make #1 as good as it can, but also do what it can to
> encourage #2 over #3 where possible/reasonable.
>

I just noticed that I transposed #2 and #3 everywhere. We want to encourage
#3 is a decent compromise that we want to encourage over #2.

Re: [whatwg] Form element invalid message

[Scott González]

2011/7/28 Jukka K. Korpela 

> 28.07.2011 12:16, Scott González wrote:
>
>  I agree that it's extremely important to be able to define error
>> messages per error condition, but it's not necessary to code all data
>> checking in JavaScript to achieve that today.
>>
>
> It's not, but if you cannot set the error messages in HTML, what's the
> point? Doing everything in JavaScript is simpler, especially because you
> should anyway duplicate the checks - for example, using JavaScript to get
> the pattern attribute value and run the check in it, to deal with the many
> situations where the user has JavaScript enabled and the browser does not
> support the pattern attribute (but still includes its value into the DOM).


Doing everything in JavaScript is easier for developers, but an easily
configurable JavaScript plugin is easier for a very large percentage of web
content authors. A first pass might look something like:

$( "#age" ).validation({
required: "You must enter an email address.",
min: "You must be at least 13 to post nonsense on the web."
});

As for duplicating the checks anyway, I completely agree and I personally
just use JavaScript anyway. As one of the development leads for jQuery UI, I
can tell you that I have mixed feelings about all of the new features. As a
developer, I want to leverage as much of the semantics and information as I
can, but I also want complete control over the results of providing those
semantics and information. This generally means we want the attributes
without any of their actual functionality, which is a shame.


>  You can simply code the
>> error message by letting the browser do the validation, then using the
>> validity flags to set your own message with setCustomValidity.
>>
>
> Pardon? You would let the browser run the checks specified in HTML, then
> check the flags and turn an error to a custom error for which you can set
> the error message. This sounds like more complicated than doing it all in
> JavaScript, where you can directly do whatever error processing needs to be
> done. To make the HTML way a feasible option, the spec should define an easy
> way to set the error message(s) directly.


This is purely a suggestion of how to implement what I've described above.

There are essentially three choices (this applies to most new markup-driven
features):
1) Provide the information in the appropriate attributes and let the browser
do its thing.
2) Provide the information in a script and do everything via scripting.
3) Provide the information in the appropriate attributes, but handle them
via scripting.

#1 will never be as flexible as #3. #2 is a decent compromise and can be
made more flexible by allowing additional configuration via scripts. I think
the spec needs to make #1 as good as it can, but also do what it can to
encourage #2 over #3 where possible/reasonable.


>   I have a feeling you'll still end up with a few
>> shortcomings because you won't have control over the order in which the
>> checks are done, so you won't be able to specify which error message to
>> show when there are multiple errors.
>>
>
> Yes that would be a problem too, but a tolerable one. Besides, I guess the
> spec could say that the checks are carried out in the order in which the
> attributes are specified (though this admittedly deviates from the
> DOM-centric approach), and it could have yet another Boolean attribute that
> specifies whether all checks are carried out or the first failure aborts the
> processing. But more realistically, and more logically DOM-wise, the spec
> could simply define the order (e.g., required, maxlength, pattern) and
> specify that when a check fails, an error message is issued and further
> processing is suppressed.
>
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>

Re: [whatwg] Form element invalid message

[Scott González]

On Wed, Jul 27, 2011 at 11:37 PM, Jukka K. Korpela wrote:

> 28.07.2011 03:21, Ian Hickson wrote:
>
>  A text input field could have a number of error conditions:
>>
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone. If this is not possible, it is easier to authors to code all
> data checking in JavaScript. Setting the error messages is important both
> for context dependency and for localization (using the language of the
> browser's UI would be odd when it differs from the language of the page - if
> the page is in Greek and the instructions there are in Greek, I would expect
> the messages of the data error to be Greek, even when my browser speaks
> Hebrew).


I agree that it's extremely important to be able to define error messages
per error condition, but it's not necessary to code all data checking in
JavaScript to achieve that today. You can simply code the error message by
letting the browser do the validation, then using the validity flags to set
your own message with setCustomValidity. Since this is possible today, it's
probably worth building a prototype that reads the custom error messages out
of data- attributes, e.g., data-patternerror. I have a feeling you'll still
end up with a few shortcomings because you won't have control over the order
in which the checks are done, so you won't be able to specify which error
message to show when there are multiple errors. Perhaps the best you could
do is provide another option which allows multiple errors to be displayed at
once.


>  I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>>
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.
>

I'd prefer not using the title attribute as well. In many cases where a
title attribute is already specified it won't make sense as an error
message. In cases where it will get specified specifically for pattern error
messages, authors will almost definitely use wording that doesn't make sense
for the title.

A dedicated attribute is much better. In particular, it does not interfere
> with the existing use of existing attributes.
>
>
>  If it's present, user
>> agents could use it to replace or augment their message, and authors could
>> make the message more specific by dynamically changing the attribute when
>> during the 'invalid' event handler.
>>
>>  Offer code:
>> >oninput="setCustomValidity(**input.match(/0/) ?
>> 'Codes contain no zeroes, only Os.' : '')"
>>validitymessage="Enter the code without spaces.">
>>
>>
>
> It would be more logical and descriptive to call it errormessage rather
> than validitymessage.
>
> But the main problem is that attributes like maxlength, pattern, and
> required are supposed to provide some data validation in a simple manner
> that does not need to involve JavaScript and works even when it is disabled.
> To make them useful, it should be possible to set the error message for each
> of them separately in HTML.
>
> I have no better solution than to use separate attributes, like
> maxlengtherror, patternerror, requirederror. This doesn't sound cool, but it
> would work and would be useful.
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/
>

Re: [whatwg] HTML6 Doctype

[Scott González]

What percentage of all versions of all browsers do you think fully
support any version of any spec? Saying that browser X supports some
part of CSS2 is no more or less useful than saying browser X supports
some part of CSS as it is defined today (which is backward compatible
with how it was defined on any previous day). Browsers are constantly
adding new features and fixing bugs. We're also seeing much more
frequent releases of browsers (and hopefully more frequent updates to
"stable" HTML). Trying to map a version of HTML to a browser version
isn't very practical. I'm not sure what kind of long, painful support
issues you think would arise from not having a version number.


On Saturday, August 28, 2010, 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!
>
> But, I share some of the same concerns (and more) as David Bruant, and would 
> like to understand why this non-versioned HTML is a good thing.  I keep 
> imagining long, painful support issues.
>
> What will this doctype be since it cannot be ?

 It can be that. HTML is backwards-compatible, meaning that an
 implementation of the spec in 2020 will handle content written to the
 spec in 2010 correctly.
>>>
>>> Even if I agree on this goal, I think that this is a very ambitious
>>> statement. From a formal point of view, how can you prove that a change
>>> that you make on a spec is backward-compatible with *any* content
>>> written following the 2010 spec?
>>
>> We can't prove it, but we've never needed versioning for previous versions
>> of HTML, and there's massive pressure to ensure we continue to not use
>> versioning (the few experiments with versioning -- quirks mode and XHTML
>> -- have been found to be rather disappointing, to put it mildly).
>
>> A number of other languages don't have versioning, for example CSS, C++.
>
>
> I agree that they don't have access to versioning info from within the 
> languages.
>
> But, CSS has some sense of versions (CSS, CSS2, and CSS3).  This gives me 
> some ability to say "ah, SurfBrowser 1.0 and 2.0 supported CSS1, but with 3.0 
> they supported some of CSS2 etc etc.
>
> That is, as long as I'm using the current browser, I know I've got support 
> for whatever is latest.  But, when I'm providing support for folks using 
> non-current browsers, there's some value in being able to estimate what will 
> and won't work there. Saying "well, I have no idea if our app will work in 
> the browser you have, because no one knows what form of the HTML spec it 
> supported" doesn't go over very well with someone paying you money :-).
>
> Maybe it would make more sense to version the test suite in some fashion?  
> Then one could say: "SurfBrowser 7.8 passes the HTML test suite of March 
> 15th, 2012" and so as long as folks know what that test suite is validating, 
> then this might address support issues just fine.
>
> david
>
>

Re: [whatwg] prompts, alerts and showModalDialog during beforeunload/unload events

[Scott González]

2010/2/11 Jonas Sicking 

> 2010/2/11 Scott González :
> > I use dialogs in this fashion as well. Users get very frustrated when
> they
> > accidentally leave a page with unsaved content and this is the easiest
> > improvement for most developers to make.
>
> However you can accomplish this using the onbeforeunload return value.
> No need to open modal dialogs using showModalDialog/input()/alert()
> etc.
>

You're correct and that's actually what I do. I didn't realize Ojan wasn't
talking about this, even though the subject makes that pretty clear.

Re: [whatwg] prompts, alerts and showModalDialog during beforeunload/unload events

[Scott González]

On Thu, Feb 11, 2010 at 9:55 PM, Tab Atkins Jr. wrote:

> I commonly see them put to *good* use by editting applications,
> warning you if you attempt to leave the page without saving.  It has
> saved me from accidentally lost effort just in the past few days in
> both my email and one of my wikis.
>

I use dialogs in this fashion as well. Users get very frustrated when they
accidentally leave a page with unsaved content and this is the easiest
improvement for most developers to make.

Re: [whatwg] Making cross-domain overlays more user-friendly

[Scott González]

The big disadvantage to this proposal is that it won't work until browsers
implement the functionality, which would discourage anyone from using it
since the fallback is that no overlay/infobar is presented. Rowan's
implementation will allow the overlay/infobar to be displayed, but would
keep the target page contained in an iframe. I would imagine that almost
everybody that wants an overlay/infobar would opt to use a method that
forces the overlay/infobar to be displayed, even if that means continuing
with their current implementations.


On Wed, Feb 10, 2010 at 2:00 AM, Martin Atkins wrote:

> Rowan Nairn wrote:
>
>> Hi,
>>
>> In the spirit of paving some cow paths I'd like to put forward a
>> proposal for a future version of HTML.  The behavior I'm addressing is
>> sites that replace links to external content with a framed version of
>> that content, along with their own overlay of information and links.
>> I think with some small tweaks it's possible to create a better
>> experience for the user in these situations.  I wasn't able to find
>> any discussion of this use case in the archives.  Please excuse me if
>> this has already been discussed.
>>
>>  [snip details of proposal]
>
> Alternate proposal:
>
>  * Add a new attribute on all hyperlink elements which accepts a URL as its
> value. Let's call this new attribute "infobar" for want of a better name for
> it.
>  * When the user follows that link, create a view where the main browser
> window contains the page which was the href of the link, but where there is
> also a smaller docked view, perhaps along the top of the browser window,
> containing the page which at the URL given in the infobar attribute.
>  * Include a mandatory close button on the infobar panel.
>  * Have this extra bar disappear if the user navigates away from the page
> or chooses the close button.
>  * Have this extra bar disappear if the infobar document calls
> window.close.
>  * Any links in the infobar document get loaded in the main browser window,
> which implicitly closes the infobar since this is a navigation in the main
> window.
>  * If the infobar document causes navigation by a means other than a link,
> such as setting document.location, it is just closed.
>  * The infobar document *may* use window.open to open other windows --
> subject to normal popup blocker restrictions -- if it needs to display some
> UI that does not fit into the infobar form factor.
>
> This proposal compromises the flexibility of UI in what you called the
> overlay document and what I called the infobar document. The most notable
> omission is that it does not allow the overlay site to choose how the
> infobar is displayed, since the main page is given precedence. It may be
> desirable to provide some means by which the infobar document can request a
> particular size, though the user-agent must impose restrictions on the size
> to prevent a situation where the information bar appears more prominent than
> the main document.
>
> This proposal, much like the "ping" attribute proposed previously, allows a
> user-agent to offer a feature whereby the infobar can be skipped altogether.
> It also causes the Referer header of the request to the main page to be the
> original linking page and not the infobar page.
>
> It still has the challenge that the UA must find a way to make it
> unambiguous that the infobar is *not* part of the main page, to prevent
> attacks such as including an infobar containing a login form which looks
> like it belongs to the main page when in fact it does not. One idea, which
> may be too draconian, is to prevent the infobar frame from accepting
> keyboard input altogether, and not allow any form elements within it to
> receive focus. The infobar document may open a new window using window.open
> if it needs to capture some information; that window will display the URL of
> the document in its location bar, allowing the user to see what site it's
> loaded from.
>
> However, it is likely that these restrictions will cause site implementers
> to continue with current practice in order to retain the flexibility they
> currently enjoy.
>
>
>

Re: [whatwg] validationMessage

[Scott González]

2009/11/20 Peter Kasting 

> 2009/11/19 Scott González 
>
>> However, following that same logic wouldn't you come to the conclusion
>> that date inputs should not display calendars because they need to be
>> localized?
>>
>
> * I am confused, what needs to be localized about the calendar?  Are you
> referring to non-Gregorian calendars, e.g. the Mayan calendar?
>

Month names, day names, whether the year comes before or after the month,
etc.


> * I'm making an argument about validationMessage, not a generalized
> argument.  Don't extrapolate to create strawmen.
>

This was a serious question, not an attempt to dismiss your original
comment.

Re: [whatwg] validationMessage

[Scott González]

On Thu, Nov 19, 2009 at 7:05 PM, Peter Kasting  wrote:

> * Directing the UA to step into this process and show the user messages
> about the validation failures, which don't take into account context the web
> page has -- bad
>

I agree with this specific case because I would personally always customize
the validation handling. However, following that same logic wouldn't you
come to the conclusion that date inputs should not display calendars because
they need to be localized? I would certainly not expect the average user to
enter a valid date format of -MM-DD, so not having a calendar would make
validation of dates almost worthless without a calendar. On the other hand,
this is another case where I would most likely use a library like jQuery to
display a calendar anyway to give me more control over the calendar. A bit
off-topic, but they seem to be pretty closely related.

Re: [whatwg] validationMessage

[Scott González]

Wouldn't the UA be written for a specific language that would be independent
of the language the page's content is written in? For example, a user in
Spain would be using a UA with a Spanish locale (the UA's menus, dialogs,
button labels, etc. would all be in Spanish). If that user were to visit a
page written in French wouldn't the content generated by the UA still be in
Spanish? So an alert would contain a message in French, but a button in
Spanish. I would expect the same thing to happen with validation messages.

As for the suggestion of the validation message just being a constant, you
can just check the validity state if you want to provide custom messages.


On Tue, Nov 10, 2009 at 4:23 PM, Michelangelo De Simone
wrote:

> Hi,
>
> I've been dealing with the validationMessage implementation in WebKit. As
> some of WebKit member pointed out it's quite unusual for an attribute to
> "return a suitably *localized message* that the user agent would show the
> user".
>
> Couldn't such behavior be potentially heterogeneous among UAs and
> localizations?
>
> What is the rationale about this choice? A simpler behavior with a
> predetermined list of return values (eg: i.validationMessage ==
> VALUEMISSING) could be much more efficient for authors and implementors to
> deal with, IMHO.
>
> Thank you for your feedbacks.
> --
> Bye, Michelangelo
>
>
>
>

Re: [whatwg] focus change inside keypress event handler

[Scott González]

On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II wrote:

> Safari and Firefox will allow focus() inside the handler to decide where
> the character gets inserted, but only with "keydown". With "keypress" (and
> textInput in webkit) in Firefox and Safari, it appears that the char was
> already inserted right after keydown, so a focus() change is already too
> late. Despite that though, preventDefault() still works in Firefox and
> Safari inside a "keypress" handler to prevent the char from being inserted.
> So, I'm not exactly sure what's they're doing behind the scenes.
>

DOM Level 3 Events says "The default action of the keypress event depends
upon the key and the context: if the key is associated with a character, and
if there currently focused element in the document can receive text (such as
a form input or an editable text block), the default action is to dispatch a
textInput event with the character as the value of the TextEvent.data
attribute"

The default action of a keypress is not to insert a character in the element
that has focus, but to insert a character on the element that represents the
context of the keypress. In the given example, the keypress's context is the
first field, not the second. I agree though that the documentation could be
clearer about this as it's not explicitly stated.

Re: [whatwg]

[Scott González]

On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. wrote:

> Well, the point is that this should generally act as just an
> optimization of normal navigation.  Clicking on  onlyreplace=bar> should give you the same result as clicking on  href=foo>, just without the overall page getting flushed.  So the
> address should update to "http://example.com/foo";, etc.
>

I've only been partially following this thread, so this may have been
answered previously. Is this an accurate summary of what you're thinking of?

Clicking  and  would send the
exact same headers to the server with the exception of a single extra header
for the @onlyreplace version?

In the case of @onlyreplace, would the #bar element end up being replaced,
or just its content? Would the server be expected to reply with ... or just what would would become bar.innerHTML?

Re: [whatwg] Transparent Content

[Scott González]

On Tue, Oct 13, 2009 at 8:53 AM, Yuvalik Webdesign
wrote:

> Would this do:
>
> If a transparent element were to be replaced by an element equal to its
> parent while retaining its content, this content should remain conformant.
>

That would imply that another element would be inserted in the place of the
transparent element. Perhaps something like "If a transparent element were
to be replaced by its children, the content should remain conformant."

Interestingly, for a sentence that seems to be causing confusion, the
equivalent code is very straight-forward and easy to understand. I don't
think this section will remain confusing, but if it does going into the
technical steps of how you would remove an element without removing its
children would certainly clear that up.

Re: [whatwg] Charset sniffing from XML prolog

[Scott González]

fakexml.html and fakexml2.html both work as UTF-8 for me in Safari 4 and
Firefox 3 on Mac.fakexml_iso.html shows up as UTF-8 in Safari 4, but
ISO-8859-1 in Firefox.
fakexml2_iso.html has a broken degree in both Safari and Firefox.

So for me, you can get the XML prolog to override the encoding, but Safari
gets confused with a non-UTF-8 encoding in the prolog (reports that it's
using UTF-8 but it isn't).

[whatwg] default values stepDown() and stepUp() methods

[Scott González]

The stepDown() and stepUp() methods both take a single parameter to define
how many steps should be taken. There is currently no default value for this
parameter which means calling element.stepUp() takes zero steps, which
essentially means that it performs no action at all. I think the parameter
should default to 1 as that will probably be a very common use. Everyone I
have talked to agrees that defaulting to zero steps is not the behavior they
expect.

Re: [whatwg] Text areas with pattern attributes?

[Scott González]

On Tue, Sep 29, 2009 at 11:43 PM, Ian Hickson  wrote:
>
> > So add 'multiple' on all of those and you'll have a good reason you'd
> > want them all to be able to wrap over multiple lines. I.e. ability to
> > enter multiple bank numbers, multiple social security numbers or
> > multiple usernames.
>
> I could see an argument for . That's
> probably best left for a future version though.
>
> But I don't think that's the same as multiline input.
>

If you could specify that a pattern could match multiple times you would
also need to specify the delimiter. Support for multiple should also be very
easy by just modifying your pattern without support for a multiple
attribute.

> All of these seem like a bad idea to keep separate for multiline inputs
> > vs. single line inputs. Except for the default value which for historic
> > reasons make sense to use separate mechanisms, and cols/size which are
> > both mostly rendering differences.
>
> It's not clear how list="" would work with , and I'm not aware
> of any UA that does  autocomplete.
>

The closest example of this that I can think of is Facebook's autocomplete
for messages, but even adding autocomplete to a textarea wouldn't make it
possible to implement what they have.

I could see pattern being supported for textarea, but in the same way as a
text input. I think it's okay to require JavaScript and use the custom
validation system for more complex validation, especially for this version.