Re: [whatwg] iframe sandbox attribute
On 7/10/12 12:27 PM, Ian Hickson wrote: Since it doesn't for any other attributes that take a string but where empty string and absence are different, why is it suddenly an issue specifically with this attribute? Because this is a new attribute we're defining and I happened to notice? ;) I think the situation would be different if you were asking about changing the behaviour of all content attributes rather than one specific one. That's what Simon is arguing for here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 I'm not sure that makes sense either, but it's more plausible, IMHO, especially given that at least one UA apparently already does it. If Gecko also changed in this manner it would make the decision a lot easier. :-) Hmm. That might be doable, in fact. I'll shop it around. -Boris
Re: [whatwg] Can we make checkboxes readonly?
On Thu, 3 May 2012, Shaun Moss wrote: > > An obvious use case for readonly checkboxes came up a few weeks ago when > I made this page: http://marssociety.org.au/membership > > The checklist at the bottom I could have made more simply/cheaply with > readonly checkboxes. However I had to use images. Those aren't check boxes, so it seems entirely correct that you not use the element for them. It would be like using for the cells in the second column of that table, or for the cells in the first column. On Fri, 4 May 2012, Tab Atkins Jr. wrote: > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > > On Wed, 6 Apr 2011, Tab Atkins Jr. wrote: > >> An app may dynamically set inputs or groups of inputs to readonly > >> based on app state. When you submit, though, it's impossible to > >> tell (without hacks) whether a checkbox was checked-but-disabled or > >> just unchecked. Handling the form data is *much* easier if you just > >> get all the data, regardless of whether, as a UI convenience, your > >> app temporarily set some of the inputs to readonly. > > > > That's a use case for submitting disabled check boxes, not for > > read-only checkboxes, IMHO. (The same could be said for disabled text > > controls.) > > That's more-or-less what @readonly does - the input becomes "disabled" > but still submits. That's part of what it does, but not the main thing it does. It's mainly a UI affordance, which doesn't apply to check boxes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote:
> On Wed, May 2, 2012 at 7:17 PM, Ian Hickson wrote:
> > On Wed, 2 May 2012, Rick Waldron wrote:
> > >
> > > JS APIs like this should always return the object (constructed
> > > instance or not) and therefore chain implicitly.
>
> Let me rephrase, I simply expect modern DOM APIs to return something
> useful.
I don't think a function should return something just for the sake of
returning something. I agree that when there is something useful to return
(something that the caller doesn't already have at hand, in particular,
and might be able to make use of) that it makes sense to return it.
> > I understand that this is mostly a matter of taste in API design, but
> > IMHO that's an anti-pattern.
>
> If you're writing and designing specifications that will be implemented
> in JavaScript, then you should design them _for_ JavaScript. Section 15
> of EcmaScript specifies more then enough "prior art" that supports my
> statement above.
There's plenty of prior art in the Web platform to support pretty much any
pet design philosophy.
> > It encourages poor style;
>
> 60% of the JavaScript written on the web disagrees.
Disagrees with what? You really think that 60% of the Web is written in
good style?
> > it discourages functional programming patterns, instead favouring
> > state mutation patterns;
>
> JavaScript is a multi-paradigm language, leave your design hangups at
> the door.
...says the guy arguing for a particular paradigm. :-)
> > it makes APIs harder to extend;
>
> This is just outright false, considering JavaScript is probably the most
> extendable and historically extended language at the API level.
If you have a return value, you can't change it. If you don't, you at
least have the chance that you might be able to introduce one. So yes, it
makes APIs harder to extend.
> > it makes APIs that do have useful return values inconsistent with
> > other APIs;
>
> elem.classList.add("foo") returns "undefined". That's hardly what I
> would consider a "useful return value".
Right. But elem.classList.contains() returns a boolean, and
elem.classList.item() returns a string. So they can't be consistent with
the APIs that return self.
> Returning the element's classList instance makes an incredible amount of
> rational sense.
It's an aesthetic choice with some advantages and some disadvantages. I
don't think it's an obvious choice, by any means.
> > it is, in fact, a layering violation: it attempts to shoehorn what
> > should be a language design feature into the API layer.
>
> Much like the DOM and its weird C++ and Java influences.
We're trying to reduce them, not
> Is this group aiming to define APIs that developers will always paper
> over with abstractions, guaranteeing all app code needs a good 50k just
> to provide a decent API?
There are certainly design decisions where one might wonder whether I am
just actively trying to make the Web bad (localStorage comes to mind). But
when it comes to chaining vs not chaining, it's just not the same. I
understand that some people prefer:
a.foo().bar().baz();
...rather than:
a.foo();
a.bar();
a.baz();
...but if an author cares so much about the difference that they'll write
50,000 lines of code (!) to abstract out the difference (!) then I think
they might have their priorities set up wrong.
On Thu, 3 May 2012, Jake Verbaten wrote:
>
> Choosing some mechanism to add multiple classes at once is useful, whether
> that's making add have an arbitary arity, allow it to take an array, allow
> it to take a space seperated string or allowing add calls to be chained.
>
> My personal vote is for arity.
This API is now in the DOM Core specs, so I'll let the DOM Core editors
respond to this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for readyState behavior
On Mon, 23 Apr 2012, Henri Sivonen wrote:
>
> I propose we adopt the following rules:
> 1) Every document that's being built by a parser or being built by an
> XSLT engine has "loading" as its readyState.
> Rationale:
>* This is intuitive.
>* It makes sense to make the XSLT experience as similar as
> possible to the parser experience to avoid weirdness and also because
> in most browser the XSLT result going through the HTML parser.
>* This is already true in Chrome, Opera and Firefox 14. (It's
> not always true in older Firefox: document.open() forgets to change
> readyState to "loading" in Firefox < 14.)
> Note: This is not true for trivial non-script-created documents
> in IE 6 through 10 inclusive, but since all other engines get away
> with not cloning IE's weirdness, it seems we don't need to clone it.
> In all versions of IE 6 through 10 inclusive, it's possible for a
> document to be in mid-parse but have "interactive" as its readyState.
> It seems to me that complex cases (enough external resources not
> already in cache) may change the behavior to a direction more similar
> with other browsers, but now I fail to reproduce this.
> Delta from the spec: Make this explicit for XSLT.
Done.
> 2) Every document that's no longer being parsed reaches readyState
> "complete" as the event loop gets to spin.
> Rationale:
>* It's counter-intuitive for aborted documents to stay in the
> "loading" state forever.
>* This seems to be already true in Chrome, Opera and IE for
> documents that have been being parsed at some point. (Curiously,
> Firefox makes an effort to keep this false for Firefox!)
> Delta from the spec: Aborted documents reach "complete". Making
> this explicit for XSLT.
Done.
> 3) No document transitions from "loading" to "complete" without an
> intermediate "interactive" state.
> Rationale:
>* It's counter-intuitive and potentially bug-inducing for
> special cases to skip the "interactive" state when the "interactive"
> state occurs on the common path in Chrome, Opera and Firefox.
>* Cases where this currently isn't true are so inconsistent
> between browsers that I'm assuming they are bugs or intentional ad hoc
> hacks that haven't been informed by broader research.
> Delta from the spec: To the extent there's the above delta that
> aborted documents reach "complete", this is new. Making this explicit
> for XSLT.
Done.
> 5) window.stop() aborts the parser.
> Rationale:
>* Already true in Firefox and Chrome.
>* document.execCommand('Stop') is the closest equivalent in IE
> and it aborts the parser when loading from network (not in the
> document.open() case, though!)
> Delta from the spec: Currently, the spec cancels navigation
> instead of aborting the parser.
Done.
> 6) The "load" event doesn't fire for documents whose parser has been aborted.
> Rationale:
>* Already true in Firefox, Chrome and IE. (I don't know of a
> way to abort the parser in Opera from JS without side effects that'd
> interfere with testing.)
> Delta from the spec: If "the end" part of the parse starts running
> on abort, "load" can't fire as an unconditional part of "the end".
Agreed.
> 4) Whenever a transition to "interactive" is made, "DOMContentLoaded"
> must eventually get fired later if the document stays in a state where
> events can fire on it.
> Rationale:
>* This seems sensible for consistency with the common case.
> Currently, there are cases where Firefox fires DOMContentLoaded
> without a transition to "interactive" or transitions to "interactive"
> without ever firing DOMContentLoaded, but these cases are inconsistent
> with other browsers, so it's hard to believe they are well-considered
> compatibility features.
> Delta from the spec: Same as for point 3.
Disagreed. IMHO DOMContentLoaded is equivalent to 'load', just a bit
earlier (it's basically 'load' but before the scripts have run). In fact,
I'd specifically define DOMContentLoaded as meaning "the DOM content was
completely loaded", which clearly can't happen if the parser aborted.
> 7) The "load" event shouldn't fire synchronously.
> Rationale:
>* Events that sometimes fire synchronously and sometimes
> asynchronously are trouble.
>* Already true in Opera and Firefox. (But not in Chrome and IE9!)
> Delta from the spec: No delta.
Agreed.
> 8) When readyState changes, a "readystatechange" should be fired
> (synchronously immediately after readyState changed)
> Rationale:
>* Seems illogical not to.
>* Already true in Chrome and Firefox, so it seems browsers can
> get away with doing the logical thing.
> Delta from the spec: No delta.
Agreed.
> 9) Never fire "readystatechange" so that the old and new readyState
> are the same.
> Rationale:
>* Logic.
>* All deviations from this rule look like browser-spec
Re: [whatwg] iframe sandbox attribute
On Mon, 9 Jul 2012, Boris Zbarsky wrote: > On 7/9/12 8:39 PM, Ian Hickson wrote: > > Surely that's going to set the attribute regardless of whether the > > attribute is nullable or whatnot. > > Well, that depends on how reflecting "DOMString?" attributes are > defined. Making setting null call removeAttribute would work much like > boolean attributes work. That's an interesting idea, but it seems to me to be a bit late to be making such a fundamental change to the HTML DOM API. I mean, so far no attributes work that way (except in WebKit, apparently?); boolean attributes are the only ones where there's any way to remove the attribute by setting a value, more or less. It's not the first attribute where the empty string means something different than the attribute being omitted. > > > More importantly, > > > > > >myOtherFrame.sandbox = myFrame.sandbox; > > > > > > doesn't have weird surprising behavior if the attribute is something > > > whose value sanely distinguishes between the various possible > > > sandbox values. > > > > I'm not sure I follow. > > The point is that 'not set' and 'empty string' don't mean the same thing > for @sandbox, and ideally the DOM reflection would preserve the > distinction. Since it doesn't for any other attributes that take a string but where empty string and absence are different, why is it suddenly an issue specifically with this attribute? > > I think remaining consistent with other non-boolean attributes, and > > thus having the setter always set the attribute, is fine. > > And I think it's a footgun. No more so, I'd wager, than being inconsistent with the other attributes. I think the situation would be different if you were asking about changing the behaviour of all content attributes rather than one specific one. That's what Simon is arguing for here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 I'm not sure that makes sense either, but it's more plausible, IMHO, especially given that at least one UA apparently already does it. If Gecko also changed in this manner it would make the decision a lot easier. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
On Tue, 10 Jul 2012 02:39:45 +0200, Ian Hickson wrote: On Mon, 26 Mar 2012, Boris Zbarsky wrote: On 3/26/12 3:19 PM, Ian Hickson wrote: > Changing it to a string doesn't affect that, though, does it? Well, changing to a nullable string does affect it because doing something like this: myFrame.sandbox = myFrame.sandbox; is a no-op, as by all sane rights it should be Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. I mean, this always sets the attribute even if the attribute wasn't previously set: myElement.title = myElement.title https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 -- Simon Pieters Opera Software
