Re: [whatwg] Add input Switch Type
Brian M. Blakely, 2013-09-21 02:03 (Europe/Helsinki):
I was contemplating whether to propose a new input type, or an
attribute valid only for checkboxes. But it isn't a checkbox, so I
went with a new type value. You can choose to slide the switch or
click it in most OS implementations, so even the behavior is
different from a checkbox.
I agree that the look and feel is different from checkbox but all the
differences seem to be purely presentational. If you disagree, you need
to elaborate a bit more.
I'd suggest pursuing something along the lines
input[type=checkbox].switch
{
appearance: lightswitch;
}
instead. That way you could use CSS media queries and use lightswitch
appearance for narrow viewports and regular checkboxes for wider viewports.
However, if you're requesting for more featured switch seen in e.g.
newer Android applications where the switch has embedded text labels to
declare the switch positions, there might be need for a new markup.
An example of such UI in ASCII graphics:
++---+
| °C |== °F =| Temperature unit
++---+
(That is, a label Temperature unit with a switch with labels degree
Celcius and degree Fahrenheit. In the real UI the label is on the
left and switch is aligned to right margin but I put it this way to have
a slightly better change for ASCII graphics to work correctly.)
I personally hate this UI and would much prefer using two radio buttons
for this. Still, this is a native UI concept on this platform and I see
no reasonable way to convert a real HTML radio button group into this
using just CSS. The closest thing is allowing to allow rendering a
select element with just options with a lightswitch appearance.
--
Mikko
Re: [whatwg] Add input Switch Type
Realistically speaking, I don't think this will help much at all. Few
websites like using the default styling for form controls anyway and
so people would be just as unhappy with the default switch rendering
as they are with the default checkbox rendering.
The real fix is to allow styling formcontrols. It's one of the most
requested features from web developers, yet no one has taken the time
to research what it would take to do it.
I'm quite sure that if someone comes up with a comprehensive and well
researched proposal, that browsers would jump on it.
And the fact that we now have shadow DOM defined should help a whole lot.
/ Jonas
On Tue, Nov 19, 2013 at 1:04 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
Brian M. Blakely, 2013-09-21 02:03 (Europe/Helsinki):
I was contemplating whether to propose a new input type, or an
attribute valid only for checkboxes. But it isn't a checkbox, so I
went with a new type value. You can choose to slide the switch or
click it in most OS implementations, so even the behavior is
different from a checkbox.
I agree that the look and feel is different from checkbox but all the
differences seem to be purely presentational. If you disagree, you need to
elaborate a bit more.
I'd suggest pursuing something along the lines
input[type=checkbox].switch
{
appearance: lightswitch;
}
instead. That way you could use CSS media queries and use lightswitch
appearance for narrow viewports and regular checkboxes for wider viewports.
However, if you're requesting for more featured switch seen in e.g. newer
Android applications where the switch has embedded text labels to declare
the switch positions, there might be need for a new markup.
An example of such UI in ASCII graphics:
++---+
| 蚓 |== 蚌 =| Temperature unit
++---+
(That is, a label Temperature unit with a switch with labels degree
Celcius and degree Fahrenheit. In the real UI the label is on the left
and switch is aligned to right margin but I put it this way to have a
slightly better change for ASCII graphics to work correctly.)
I personally hate this UI and would much prefer using two radio buttons for
this. Still, this is a native UI concept on this platform and I see no
reasonable way to convert a real HTML radio button group into this using
just CSS. The closest thing is allowing to allow rendering a select
element with just options with a lightswitch appearance.
--
Mikko
Re: [whatwg] The src-N proposal
* Bruno Racineux wrote: Maybe Google should announce they'll start penalizing sites who do not gzip, to change that. Either a press release on April 1st, just as an educational scare tactic. Or a actual Webmaster Tools notification for more awareness of non-gzipped site, or both :) Google have already announced penalising unnecessarily slow sites. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Specify getSVGDocument
SVG 1.1 Second Edition deprecated .getSVGDocument(), and made it an alias for .contentDocument essentially yes. SVG2 has not yet seen any edits related to this method. But it's not unlikely that SVG2 will drop it given that SVG 1.1 states: This interface is deprecated and may be dropped from future versions of the SVG specification. It's possible that .getSVGDocument() is still in use due to embed elements not supporting .contentDocument, and people wanting to allow the use of plugins for svg content in case there was no native svg support in the browser. This may have changed due to the Adobe SVG plugin not being supported anymore. An example: http://xn--dahlstrm-t4a.net/svg/html/get-embedded-svg-document-script.html /ed On Tue, Nov 19, 2013 at 5:33 AM, Philip Jägenstedt phil...@opera.comwrote: On Mon, Nov 18, 2013 at 8:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/18/13 1:37 PM, Philip Jägenstedt wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643 In my testing, getSVGDocument is supported on embed, frame, iframe and object in Firefox Nightly, IE11 Preview, Safari 7.0 and Opera 12.16, the only exception being frame.getSVGDocument in Firefox. I don't know if this API is actually useful, but since it's already implemented everywhere it should probably be spec'd. SVG2 is trying to spec it, afaict, as basically an alias for .contentDocument. It _would_ make more sense to do that in HTML, I agree. Indeed, since it's actually on the HTML*Element interfaces. SVG2 can do partial interfaces, of course, but that makes it a bit harder to actually find. Philip
Re: [whatwg] Specify getSVGDocument
On Tue, Nov 19, 2013 at 10:31 AM, Erik Dahlström e...@opera.com wrote: SVG2 has not yet seen any edits related to this method. But it's not unlikely that SVG2 will drop it given that SVG 1.1 states: This interface is deprecated and may be dropped from future versions of the SVG specification. What do you expect implementations to do? Because if everyone implements it... -- http://annevankesteren.nl/
Re: [whatwg] canvas 2d's ellipse
Rik Cabanier, 2013-09-18 00:32 (Europe/Helsinki): You are speaking as a developer, not as a user of a web application. Browser could offer a 'debug' more where they break on bad calls or output messages to the console. Once it's 'released', the runtime should be permissive. I somewhat agree. However, user agents would need a big CHECK ENGINE light in the UI similar to cars after the limb home mode is activated (a.k.a. permissive mode). It is seriously important to signal the user that the application has become unstable and should not be trusted if at all possible. Most of the time the fix is to hit the refresh button so all that is needed is to allow the user to save what is possible to save. -- Mikko
Re: [whatwg] Mailing List Archive Link
On 12/11/2013 16:10 , Anselm Hannemann wrote: If you ask me I would like to have a link on bottom of every message to the archived version but at w3c they said it wouldn’t be possible because this needs massive changes in the software. More generally, IIRC the policy with W3C mailing lists is to modify the body of the message as little as possible. That said since all WHATWG messages are archived at the W3C, you can always grab the Message-ID from a message posted here and get to its archive using the MID resolver: http://www.w3.org/mid/the-message-id So for instance, your initial post can be found at: http://www.w3.org/mid/eaf52201-ecaf-4f7f-839e-0585c085c...@anselm-hannemann.com If your mail client can be somehow scripted to take advantage of this, you can have it grab the MID to generate a link. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] The src-N proposal
Am 19.11.2013 08:49 schrieb Yoav Weiss: If you'd like to further discuss that concern, can you please open up a new thread? This one discusses solutions to the responsive images problem use-cases (e.g. src-N, picture, srcset, etc) My personal conclusion of this part of the thread is: The (negative) bandwidth effect caused by the verbosity of the respImg syntax is minimal compared to the (positive) bandwith effect achieved by the actual use of respImgs. Thus, the final solution should be most understandable and easily applicable by average authors (as I am), because otherwise authors will either hesitate to use it, or (even worse) use it incorrectly. This would IMHO speak against both srcset and src-N approaches, and be in favor of some picture-like approach (again), because it is human-understandable and DOM-ready HTML. I am sorry I am not capable of fully understanding all related threads, but as far as I can get it, all technical issues of this approach seem to have been stated to be solveable so far.
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote: Realistically speaking, I don't think this will help much at all. Few websites like using the default styling for form controls anyway and so people would be just as unhappy with the default switch rendering as they are with the default checkbox rendering. The real fix is to allow styling formcontrols. It's one of the most requested features from web developers, yet no one has taken the time to research what it would take to do it. I'm quite sure that if someone comes up with a comprehensive and well researched proposal, that browsers would jump on it. And the fact that we now have shadow DOM defined should help a whole lot. +1, a switch is just a styled checkbox. We don't need more input types or attributes, we just need to standardize how to style type=checkbox. - E
Re: [whatwg] Mailing List Archive Link
* Anselm Hannemann wrote: In the mails from w3c there is a header tag with the reference to the archived version but I couldn’t find one here. Some http://wiki.list.org/display/DEV/Stable+URLs are trying to add such a feature to mailman, which this list uses, but so far there is nothing easily deployed (and I would hope the mailman community adopts a better solution than what the page above proposes). A simple solution is making sure a given mailing list is added to Gmane and then use something like http://mid.gmane.org/9lim89lho03c0psucrd6gjpovv9raot...@hive.bjoern.hoehrmann.de derived from the Message-Id to create a link yourself. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] The src-N proposal
On 19/11/13 01:55, Kornel Lesiński wrote: On Tue, 19 Nov 2013 01:12:12 -, Tab Atkins Jr. jackalm...@gmail.com wrote: AFAIK it makes it as easy to implement and as safe to use as src-N. Simon, who initially raised concerns about use of source in picture found that solution acceptable[2]. I'd love to hear feedback about simplified, atomic source from other vendors. The cost there is that picturesource is now treated substantially differently than videosource, despite sharing a name. The substantial difference is that it lacks JS API exposing network/buffering state, but IHMO that's not a big loss, as those concepts are not as needed for pictures. IMHO the important thing is that on the surface (syntactical level) they're the same - multiple source elements where the first one matches. So the remaining objections I am aware of to atomic-source are: * Something related to animations. I don't actually understand this, so it would be nice if someone who does would explain. Alternatively this might not actually be an issue. * Verbosity. This proposal is clearly verbose, but it is also the one that authors seem to prefer, largely because it uses the underlying markup syntax in a natural way. It seems that people will likely deal with the verbosity by copy and paste, templates or libraries to provide a convenient shorthand. If the latter occurs we can look at standardising it later. * More testing is needed. Specifically it seems that tests will be needed to use source elements (or picture elements?) where you can currently use img elements. This is a real concern of course, but seems lower on the priority of constituencies than authoring concerns, unless we think that poor interop will poison the feature. With an atomic proposal this seems much less likely, Hopefully implementations will be able to reuse the existing img code so that the actual amount of new *code* to test is less than you might think by looking at the extra API surface.
Re: [whatwg] Notifications: usage feedback
On Tue, Oct 29, 2013 at 3:43 PM, Jonas Sicking jo...@sicking.cc wrote: Strings certainly solves the use cases since anything can be encoded into a string. However it seems to me that using structured clones will make things a lot easier for pages in many cases. This was always *the* top complaint about localStorage from authors. Either way we probably need to put some limit on how much data you can store. I made this whole thing this issue: https://github.com/whatwg/notifications/issues/3 Unless I hear otherwise I will probably go with the structured clone thing. -- http://annevankesteren.nl/
Re: [whatwg] Notifications: usage feedback
On Tue, Oct 29, 2013 at 3:47 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Tue, Oct 29, 2013 at 11:26 AM, Anne van Kesteren ann...@annevk.nl wrote: We currently do not have a way to have events out-of-band for the web. What about providing a URL that the user-agent will open? If the originating tab of the notification is still open, navigate it to there, otherwise open it in a new tab? Could work, but I think we want to go with service workers here. They seem to be our best bet for telling a site about something happened. The site can then decide to request for an actual window or some such. Clients can use the HTML5 navigation APIs to detect this and take an appropriate action. How exactly? -- http://annevankesteren.nl/
Re: [whatwg] Notifications: usage feedback
On Tue, Oct 29, 2013 at 3:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Oct 29, 2013 at 8:26 AM, Anne van Kesteren ann...@annevk.nl wrote: That seems like an implementation detail. Activation could mean dismissal, but e.g. on Mac OS X activation does not mean dismissal. It's up to the site/app to dismiss after activation and sometimes they decide to keep the notification around for a bit. That sounds unlikely to work in practice. I.e. I would expect pages to break if some implementations fire onclose and others do not. Is there a reason not to forbid firing onclose if onclick has been fired. Keep in mind that the implementation can always hide the notification or not independently of if it has fired onclose or not. Unless we force all notification platforms to be identical, I don't think we can require any particular behavior here. It's like double click, some platforms have it, others don't. Some notification platforms will remove the notification once clicked (and be required to fire close in addition to click) and in others it'll remain open (and only click will be fired). This may be part of just further defining the steps for the click pathway in the spec, but at least in FirefoxOS right now, the notification onclick pathway does not bring the app to the visible front in all cases. The email app has to do some extra document.hidden checking and try to bring itself to the front. That seems like a UI detail we cannot really say anything about in the specification. Again, this seems unlikely to work in practice. I.e. I would expect that authors would expect one behavior (likely the behavior of whatever platform they are developing on) and that things would break when the website is used on platforms that has the other behavior. I suspect allowing the author to choose behavior here is going to work more reliably. What are you thinking of? We define some kind of UI hints a developer can register for when initiating a new notification? Might work I suppose. -- http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- I agree that the look and feel is different from checkbox but all the differences seem to be purely presentational. If you disagree, you need to elaborate a bit more. Interestingly, Microsoft's Windows Store apps guidelines disagree. I find their reasoning somewhat compelling, although novel: http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. These aren't exactly semantic differences, but I think they reveal different underlying semantics. Roughly, we have two controls which each have two states. But the meanings of those two states are completely different for switches vs. checkboxes; perhaps it could be boiled down to on vs. off for this thing and yes vs. no for this option.
Re: [whatwg] Implementation question about Notifications
On Mon, Nov 18, 2013 at 2:08 PM, Andrew Wilson atwil...@google.com wrote:
I think having them return the empty string would be fine (and would,
coincidentally, match our current implementation in Chrome).
Okay.
My one concern is that according to the current spec, is a valid |tag|
and so Notification(title, { tag: }) is different than
Notification(title) because the latter has no tag, while the former has an
empty tag (and so can be fetched via Notification.get())
In
https://github.com/whatwg/notifications/commit/0db93b134e71431c9c85787cf5332692778d11cb
I made it so that tag being the empty string is equivalent to a
notification not having a tag. That avoids us having to choose
undefined or null to deal with his manner and gives a string-only API
which seems somewhat convenient.
Well, invalid_icon_url is not an invalid URL, but if you had used
e.g. http://test:test/; it would have to return the same as n1.
n3.icon should return http://non-existent-icon.com/; per
http://notifications.spec.whatwg.org/#dom-notification-icon
Yes, makes sense, taking into account my inability to form an ill-formed URL
:)
Just to be clear, note that it serializes the URL, hence the trailing
slash. This is similar to how a.href and family behave.
--
http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 2:25 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. On the other hand, we have these two type of experiences on the web already and they are not limited to checkboxes. Introducing different controls for effectively the same action with the only difference being whether you need to hit submit seems somewhat contrived. -- http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
There is certainly a semantic difference between switches and checkboxes. As much of a difference as between buttons and links. A checkbox is part of a checklist, something you use to indicate or track the states of things. You put a series of checkmarks on a form, then bring it to the reception desk. A switch, like a button, is a mechanical control that actuates something. You flick a switch to turn the light on. Technically, a switch could be implemented as a styled checkbox with JavaScript attached. But as a website visitor, I would rather not deal with a dozen websites offering a dozen different switch appearances and behaviours attached to mousedown, mouseup, click, tap, drag, and swipe. MZ. -- Michael Zajac http://zajac.ca/ +1-204-943-6596 On 2013-11-19, at 8:39, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Nov 19, 2013 at 2:25 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. On the other hand, we have these two type of experiences on the web already and they are not limited to checkboxes. Introducing different controls for effectively the same action with the only difference being whether you need to hit submit seems somewhat contrived. -- http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
2013-11-19 16:25, Domenic Denicola wrote: From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- I agree that the look and feel is different from checkbox but all the differences seem to be purely presentational. If you disagree, you need to elaborate a bit more. Interestingly, Microsoft's Windows Store apps guidelines disagree. I find their reasoning somewhat compelling, although novel: http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. From the usability and accessibility point of view, this seems to address an important issue. Authors sometimes use checkboxes (or radio buttons) so that changing their state has an immediate effect, even submitting a form. This may violate normal user expectations and can be confusing. Normally, we enter some data, using various controls, and then click on a button (or do something equivalent) to request for an action. Checking a checkbox should not be a commitment, any more than typing text in a feedback form or selecting an item from a dropdown list in an order form should be a commitment. This means that things that have immediate effect should be buttons, or something else recognized as action-triggering control. So why not use a button? Maybe because a button does not normally have a visible state. A toggle switch would thus logically be a combination of a checkbox and a button: it has a direct effect, like a button, but it remains visible (or otherwise perceivable) in an on or off state, like a checkbox. And it should probably have a dual ARIA role: role=checkbox button. But maybe this means looking at things in a too narrow perspective, as if controls were only used in forms that submit data to a server. A purely application-like page may conceivably have checkboxes and radio buttons that have immediate effects (say, so that in an image processing application, checking a checkbox immediately turns the image to grayscale). Checkboxes probably wouldn’t confuse a user who knows at all what he is using. On the other hand, toggles could be used, too. Maybe even better than checkboxes. Yucca
Re: [whatwg] The src-N proposal
Am 19.11.2013 12:13 schrieb Markus Ernst: Am 19.11.2013 08:49 schrieb Yoav Weiss: If you'd like to further discuss that concern, can you please open up a new thread? This one discusses solutions to the responsive images problem use-cases (e.g. src-N, picture, srcset, etc) My personal conclusion of this part of the thread is: The (negative) bandwidth effect caused by the verbosity of the respImg syntax is minimal compared to the (positive) bandwith effect achieved by the actual use of respImgs. Thus, the final solution should be most understandable and easily applicable by average authors (as I am), because otherwise authors will either hesitate to use it, or (even worse) use it incorrectly. This would IMHO speak against both srcset and src-N approaches, and be in favor of some picture-like approach (again), because it is human-understandable and DOM-ready HTML. I am sorry I am not capable of fully understanding all related threads, but as far as I can get it, all technical issues of this approach seem to have been stated to be solveable so far. May I humbly point back to http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036173.html I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far.
Re: [whatwg] The src-N proposal
On Tue, 19 Nov 2013, Markus Ernst wrote: I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far. I responsed to proposals along those lines last year: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html Search for multi-element for the specific response to proposals that involve multiple elements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Add input Switch Type
On 19 November 2013 19.13.44, Jukka K. Korpela wrote: From the usability and accessibility point of view, this seems to address an important issue. Authors sometimes use checkboxes (or radio buttons) so that changing their state has an immediate effect, even submitting a form. This may violate normal user expectations and can be confusing. Normally, we enter some data, using various controls, and then click on a button (or do something equivalent) to request for an action. Checking a checkbox should not be a commitment, any more than typing text in a feedback form or selecting an item from a dropdown list in an order form should be a commitment. This means that things that have immediate effect should be buttons, or something else recognized as action-triggering control. So why not use a button? Maybe because a button does not normally have a visible state. A toggle switch would thus logically be a combination of a checkbox and a button: it has a direct effect, like a button, but it remains visible (or otherwise perceivable) in an on or off state, like a checkbox. And it should probably have a dual ARIA role: role=checkbox button. But maybe this means looking at things in a too narrow perspective, as if controls were only used in forms that submit data to a server. A purely application-like page may conceivably have checkboxes and radio buttons that have immediate effects (say, so that in an image processing application, checking a checkbox immediately turns the image to grayscale). Checkboxes probably wouldn’t confuse a user who knows at all what he is using. On the other hand, toggles could be used, too. Maybe even better than checkboxes. I think you're overthinking this. A checkbox represents an input with binary state. As I understand it, whether the input is immediate or takes effect only on some kind of submission is defined by context - specifically, whether the checkbox is associated with a form with a submit button. This does not affect the fact that the input is fundamentally binary. In contrast, a button represents a single action, atomic from the user's point of view. Pressing the button again should (it seems to me) logically perform the same action again; if the action performed every time the button is pressed can only be described as something like toggle the X, you've done something wrong in your design. You should be able to make a checkbox look like a button (albeit, one presumes, one that remains pushed in order to represent its state), and *could* even make a button look like a checkbox (although I can't imagine why you would want to), but they represent different things underneath. A toggle or switch is an input with binary state. Therefore, it is a checkbox, with a different shape from usual. Incidentally, in the case of text to the sides of a styled switch, as mentioned above, it seems clear to me that the actual switch part in the middle is the input, and the text parts are labels, all inside an outer frame block.
Re: [whatwg] Add input Switch Type
On Nov 19, 2013, at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote:
Realistically speaking, I don't think this will help much at all. Few
websites like using the default styling for form controls anyway and
so people would be just as unhappy with the default switch rendering
as they are with the default checkbox rendering.
Default-styled checkboxes seem to be somewhat more common than default-styled
buttons. We also get requests for an easy way to get a switch that uses the
native iOS look from time to time, from authors who don't want to replicate the
artwork and interactive behavior by hand.
In my opinion, figuring out general styling for all form controls is very
useful, but an appearance value to provide a standard switch look and behavior
would also be useful.
Regards,
Maciej
The real fix is to allow styling formcontrols. It's one of the most
requested features from web developers, yet no one has taken the time
to research what it would take to do it.
I'm quite sure that if someone comes up with a comprehensive and well
researched proposal, that browsers would jump on it.
And the fact that we now have shadow DOM defined should help a whole lot.
/ Jonas
On Tue, Nov 19, 2013 at 1:04 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
Brian M. Blakely, 2013-09-21 02:03 (Europe/Helsinki):
I was contemplating whether to propose a new input type, or an
attribute valid only for checkboxes. But it isn't a checkbox, so I
went with a new type value. You can choose to slide the switch or
click it in most OS implementations, so even the behavior is
different from a checkbox.
I agree that the look and feel is different from checkbox but all the
differences seem to be purely presentational. If you disagree, you need to
elaborate a bit more.
I'd suggest pursuing something along the lines
input[type=checkbox].switch
{
appearance: lightswitch;
}
instead. That way you could use CSS media queries and use lightswitch
appearance for narrow viewports and regular checkboxes for wider viewports.
However, if you're requesting for more featured switch seen in e.g. newer
Android applications where the switch has embedded text labels to declare
the switch positions, there might be need for a new markup.
An example of such UI in ASCII graphics:
++---+
| 蚓 |== 蚌 =| Temperature unit
++---+
(That is, a label Temperature unit with a switch with labels degree
Celcius and degree Fahrenheit. In the real UI the label is on the left
and switch is aligned to right margin but I put it this way to have a
slightly better change for ASCII graphics to work correctly.)
I personally hate this UI and would much prefer using two radio buttons for
this. Still, this is a native UI concept on this platform and I see no
reasonable way to convert a real HTML radio button group into this using
just CSS. The closest thing is allowing to allow rendering a select
element with just options with a lightswitch appearance.
--
Mikko
Re: [whatwg] The src-N proposal
On Tue, Nov 19, 2013 at 2:28 AM, Bruno Racineux br...@hexanet.net wrote:
If I can give two top of my head analogies. With that pattern of thinking,
something like the rather complex to understand CSS flexbox wouldn't
exist. Or inline javacript would be allowed for fear of a dumb mistake by
an amateur.
I think, this kind of false misdirected fears, are actually overemphasized
concerns by some here. If we worry about 'stupid' so much that it hinders
progress. It could set priorities backwards.
I think there's a qualitative difference between this particular
thing is more complex than necessary in a way that virtually
guarantees it will be misused and no even slightly complicated
things should ever be allowed anywhere ever. *Not* worrying too much
about stupid doesn't mean that we have to do everything the hard
way, either.
Perhaps, a reason I come to this conclusion, is that: An advantage with
the Worpdress img-name-{width}x{height}.jpg syntax is that you don't need
any tokens at all. As long as the With and Height are declared inline,
you can figure out the ratio, and match that with the list of available
widths to get the right image.
Sure, but, like I said, that only works as far as you stick to the
rigid pattern for image names. As soon as you want to break the
pattern, or - heaven forfend! - *extend* it, it becomes a serious
liability, to say the least.
Which makes src-N or srcset ever more so unnecessary for that particular
naming convention, that I'd rather almost have a few lines of inline
javascript do it in the head, for the Wordpress platform.
That's great, for the Wordpress platform. Everyone else might still
want responsive images that don't require them to emulate Wordpress.
Re: [whatwg] Add input Switch Type
2013-11-19 22:27, Qebui Nehebkau wrote: A checkbox represents an input with binary state. As I understand it, whether the input is immediate or takes effect only on some kind of submission is defined by context - specifically, whether the checkbox is associated with a form with a submit button. This more or less summarizes the alternative look at the issue that I mentioned. But I’m still inclined into thinking that distinguishing between checkboxes and switches, or giving authors the possibility of making the distinction at the level of control elements, is a useful thing to do. It’s not too late to introduce it. Most pages still use checkboxes just as selections, selecting options for some action to be requested shortly. (The select element may be a lost cause: as a user, you can’t know whether a dropdown just sets an option or actually “runs” it.) In contrast, a button represents a single action, atomic from the user's point of view. Pressing the button again should (it seems to me) logically perform the same action again; It would be too restrictive to require that, and an reality, things don’t work that way. For example, if the action consists of deleting something, you just can’t repeat it next. Yucca
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 9:28 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: It would be too restrictive to require that, and an reality, things don’t work that way. For example, if the action consists of deleting something, you just can’t repeat it next. Well, you can. Deletion is idempotent - deleting something that has already been deleted does nothing. However, if the action a button represents is not currently applicable, the button should be disabled; pressing the button again doesn't need to be possible. In any case, I don't mean to suggest that that should be 'required', just that it is part of the concept of a button and following it where possible is likely a good idea if you want users to form correct conclusions about what things will do.
Re: [whatwg] The src-N proposal
On Tue, Nov 19, 2013 at 2:07 PM, Simon Pieters sim...@opera.com wrote: So: picture source ... source ... img src=fallback alt=... /picture The selection algorithm would only consider source elements that are previous siblings of the img if the parent is a picture element, and would be called in place of the current 'process the image candidates' in the spec (called from 'update the image data'). 'Update the image data' gets run when an img element is created, has its src or crossorigin (or srcset if we still want that on img) attributes changed/set/removed, is inserted or removed from its parent, when source is inserted to a picture as a previous sibling, or a source that is a previous sibling is removed from picture, or when a source that is a previous sibling and is in picture has its src or srcset (or whatever attributes we want to use on source) attributes changed/set/removed. 'Update the image data' aborts if the parser-created flag is set. When img is inserted to the document, if the parser-created flag is set, the flag is first unset and then 'update the image data' is run but without the await a stable state step. +1. I'm totally fine with this, if the people who disliked multiple attrs are okay with multiple elements. We can still handle all the things that src-N did, without the need for such compact microsyntaxes, too: 1. Art direction is handled by source media. 2. Multiple densities is handled by a list of url/density pairs in source src. 3. Variable-size images can be handled with a picture sizes attribute, and a list of url/size pairs in source src. For the last, since we're not trying to squeeze everything into a single attributes, we can let the sizes='' attribute breath a bit, and just take a list of MQ/size pairs. Using a url/size pair in src='' would be invalid if sizes='' wasn't specified. ~TJ
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Hi
I was at the Paris RICG meetup in Paris, I understand the complexity of the
responsive requirements.
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
img src= class=artdirection/
What do you think ?
laurent
On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a
real element to have the existing WK/Blink behavior without saying
replaced. It is not obvious why ignoring the element size is a useful
default behavior. But I suppose that discussion is out of scope here and
would better be discussed in a CSS-relevant forum.
Yeah, feel free to raise it in www-style if you're interested.
Otherwise, fantasai and/or I will take care of it in due time, when we
have time for it.
For the sake of curiosity: is there any reasonably accurate current
draft that describes what 'content' is supposed to do on a non-pseudo
element?
Nope.
The most recent reference I could find is
http://www.w3.org/TR/css3-content/ but that hasn't been updated in a
while. It says If the computed value of the part of the 'content' property
that ends up being used is a single URI, then the element or pseudo-element
is a replaced element. The box model defines different rules for the layout
of replaced elements than normal elements. Replaced elements do not have
'::before' and '::after' pseudo-elements; the 'content' property in the
case of replaced content replaces the entire contents of the element's
box. But I can't tell if that matches what you say or is the opposite.
Right, Content is out-of-date and hasn't been sanity checked. Don't
let the recent-ish date fool you; it's just a stripped-down version of
the older 2003 draft, and the remaining parts haven't been seriously
gone over yet.
~TJ
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] Notifications: usage feedback
On Tue, Nov 19, 2013 at 5:37 AM, Anne van Kesteren ann...@annevk.nl wrote: This may be part of just further defining the steps for the click pathway in the spec, but at least in FirefoxOS right now, the notification onclick pathway does not bring the app to the visible front in all cases. The email app has to do some extra document.hidden checking and try to bring itself to the front. That seems like a UI detail we cannot really say anything about in the specification. Again, this seems unlikely to work in practice. I.e. I would expect that authors would expect one behavior (likely the behavior of whatever platform they are developing on) and that things would break when the website is used on platforms that has the other behavior. I suspect allowing the author to choose behavior here is going to work more reliably. What are you thinking of? We define some kind of UI hints a developer can register for when initiating a new notification? Might work I suppose. I think we should have a defined way for an author to bring forward a page when the notification is clicked. This could be either a property on the notification openCreatingWindowWhenNotificationIsClickedPlease: true. Or define that a service worker is notified about a click, and then enable the service worker to find a particular window (which may or may not be connected to the service worker) and be able to bring that window to the foreground. Or a way for a window to be notified when the notification is clicked such that it can bring itself forward using window.focus(). Or something else. The goal is to be able to answer the question If I'm a web developer and want to bring forward the window connected to a notification when the notification is clicked, what code should I write? / Jonas
Re: [whatwg] The src-N proposal
On Tue, Nov 19, 2013 at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Using a url/size pair in src='' would be invalid if sizes='' wasn't specified. On second thought, this isn't necessary. You can always set img width, or just let it take the default intrinsic width of 300px. picture sizes would just override the intrinsic width of the img. After all, even if your image isn't variable-sized, using the url/size syntax might still be easier than url/density, because you don't have to do any math, or change the densities around when you change the image size. ~TJ
Re: [whatwg] The src-N proposal
[sorry for the repeated emails] On Tue, Nov 19, 2013 at 5:47 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Nov 19, 2013 at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Using a url/size pair in src='' would be invalid if sizes='' wasn't specified. On second thought, this isn't necessary. You can always set img width, or just let it take the default intrinsic width of 300px. picture sizes would just override the intrinsic width of the img. After all, even if your image isn't variable-sized, using the url/size syntax might still be easier than url/density, because you don't have to do any math, or change the densities around when you change the image size. This means, then, that it's actually legitimate to mix url/density and url/size pairs, so we don't even need separate grammar clauses. The url/size pairs just get turned into url/[effective density] pairs, calculated from the intrinsic size (possibly modified by img width or picture sizes). This also means that you can use picture sizes and url/density together. None of these are particularly good ideas, mind you; I'm just saying that there's no real reason to disallow them, or prevent them from working with each other. The concepts are actually fairly independent in terms of operation. ~TJ
Re: [whatwg] The src-N proposal
On 11/19/13 12:12 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 19 Nov 2013, Markus Ernst wrote: I can't recall the reasons why Florian's proposal of combining picture and @srcset fell out of the discussion. To me it still looks like the most useable draft so far. I responsed to proposals along those lines last year: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.htm l Search for multi-element for the specific response to proposals that involve multiple elements. There are other concerns against any non-centralized approaches like picture. If your sources and breakpoints are hard-coded in your articles (stored DB), and you suddenly have to change your site's theme, or add a new image at the platform level or a new resolution? What if one breakpoint is no longer relevant? Or what if you change designs with a complete new responsive approach? How does an inline syntax help me with that case? You can be stuck. That forces you to regenerate all the img src(s) of your articles with your new layout and new inline breakpoints. If the HTML is generated by a WYSIWYG editor. How do you deal with it? Have to write a new plugin at the platform level to replace the img or picture element with the new variations on all your articles and pages? Either that, or the author has to predetermine traditional css classes for both MQs and img src list(s), and translate them along into a RespIMG syntax while generating every page. But then what about the WYSIWYG editor? That seems hardly workable together. Which brings the questions for that particular context: Is the solution supposed to be always generated on the fly? Or by a WYSIWYG editor? And how does an author is supposed to make changes across their whole content for lack of css approach? Any author used to the flexibility of css shouldn't have the burden to deal with hard-coded unalterable stuff like that. It's as bad as an inline css-style to deal with. And could also result in broken links, or unexpected results if the image sizes are changed along the way, loosing sync with the previously embedded srcsets or MQs in each page or article. A centralized css-subset approach do not have such difficult problems. Verbose aside, to me this all screams: RespIMGs has to be a CSS related feature with centralization of custom MQs and srcset(s) at the head.
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On Nov 19, 2013, at 4:17 PM, Laurent Perez l.lauren...@gmail.com wrote:
Hi
I was at the Paris RICG meetup in Paris, I understand the complexity of the
responsive requirements.
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
img src= class=artdirection/
What do you think ?
We've been discussing these kinds of CSS-based proposals. Is there a reason you
picked 'background-image' instead of 'content'? As discussed earlier in the
thread 'content is likely to work better in a variety of ways.
Also, what do you think about the attr(src-medium url) trick, which would let
the image URLs be in the markup but the media queries in un-repeated CSS?
Regards,
Maciej
laurent
On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a
real element to have the existing WK/Blink behavior without saying
replaced. It is not obvious why ignoring the element size is a useful
default behavior. But I suppose that discussion is out of scope here and
would better be discussed in a CSS-relevant forum.
Yeah, feel free to raise it in www-style if you're interested.
Otherwise, fantasai and/or I will take care of it in due time, when we
have time for it.
For the sake of curiosity: is there any reasonably accurate current
draft that describes what 'content' is supposed to do on a non-pseudo
element?
Nope.
The most recent reference I could find is
http://www.w3.org/TR/css3-content/ but that hasn't been updated in a
while. It says If the computed value of the part of the 'content' property
that ends up being used is a single URI, then the element or pseudo-element
is a replaced element. The box model defines different rules for the layout
of replaced elements than normal elements. Replaced elements do not have
'::before' and '::after' pseudo-elements; the 'content' property in the
case of replaced content replaces the entire contents of the element's
box. But I can't tell if that matches what you say or is the opposite.
Right, Content is out-of-date and hasn't been sanity checked. Don't
let the recent-ish date fool you; it's just a stripped-down version of
the older 2003 draft, and the remaining parts haven't been seriously
gone over yet.
~TJ
--
http://laurentperez.fr
J2EE tips and best practices
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 11/19/13 4:17 PM, Laurent Perez l.lauren...@gmail.com wrote:
I'd like to propose the following pseudocode, building upon CSS4 range
media queries.
@media (3dppx resolution = 2dppx), (min-width: 320px) {
.artdirection {
background-image:url(high.png);
background-position: center;
background-repeat: no-repeat;
min-width: 100%;
}
}
There are talks on and syntax at the www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/
Also combined with calc() notation.
Search for:
[mediaqueries] Add and syntax?
for the thread
You may also join that list to discuss such CSS related features directly.
